For two recent projects, I've used a software modding technique that I'll call afterburner rendering. This technique feels mischievous, and also powerful, like I'm getting away with something. At one point, when I was building one of these projects, I was laughing with so much glee that Lauren came in to ask if I was alright.

What is afterburner rendering?

Afterburner rendering lets the end user replace a rendered piece of an app with whatever they want. For example, the user could replace an inconspicuous but useful button that their colleagues often don’t notice with a more eye-catching design.

The basic mechanism is that a DOM node in the "real" app is chosen and is replaced with some custom HTML after the real app has rendered.

Two examples:

Rendering a temporary UI on top of an existing UI

I was making Use a GUI to edit a React app , my tool that lets you use a GUI to edit the code of a React app. When using Scapula, the user chooses which part of which component they want to edit. To do this, they select a DOM node in the browser. This node is mapped to the corresponding part of the corresponding component.

In later versions, after coming to my senses, I just let the user select a DOM node with the browser dev tools selector. Duh. But, before I had that idea, I wrote a little selection tool where the user could enable the tool and click a DOM element to select it. When an element was selected, it was highlighted with a blue border.

A design goal was that the user of Scapula (the app developer) would be able to write their React components completely normally. This was enabled by the afterburner rendering. I achieved it by binding mouse event handlers to the window. These ran methods on the DOM node to set the highlight styling. In this sense, the rendering happened "after" the normal React rendering cycle and "burned" the React rendered output.

This meant the highlights were almost like annotations on top of the app. And this meant the React app could be written normally, with no knowledge that the highlighting would happen.

Replacing an existing UI

We had a hack day at Airtable last Friday. I made something I called Hack Airtable's UI. The goal was to let the end user customize the main UI of Airtable.

The user creates a Customizations table in their base with a Selector column and Output column. The user creates a row that contains a DOM selector (like #fullscreenButton) that targets a specific page element, and some HTML that should replace that element. On every page load or base data change, the Output from each Customizations row is rendered to the corresponding DOM element.

In this way, the user could replace a button in the Airtable UI with their own more noticeable version. Or, because an Output cell can contain a JavaScript function that, when run, has access to the base data, could show their company's core metrics in the area where the name of their base is normally shown.

This works in the same way as above. Some HTML gets rendered by the main app, and then the afterburner output renderer can run methods on the DOM. Again, to make this work, I didn't need to make any changes to the Airtable React code.

[Disclaimer: We're not going to ship this! This work was a personal experiment to test out afterburner effectiveness in a complex frontend app.]

The render cycle

To achieve this effect, the render cycle of a React app becomes:

• On load
  • Normal React render cycle
    • React outputs HTML.
    • The browser creates a DOM tree from the HTML.
    • The browser renders the DOM tree.
  • Afterburner render cycle
    • For each DOM node to be modified
      • Run a function that modifies the DOM node. (Could be a wholesale replacement of innerHTML, or could run DOM functions like setAttribute.)