A proof of concept of an idea. A tool where you create software by defining behavior either with code, or with a UI. In the example below, you can define a layout and interactivity by writing React code in the usual way. Or you can define the layout by clicking on things in a UI. Code and UI stay in sync automatically.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/a43872e5-e985-42ce-abd1-10dce18fbd3c/react-direct.mp4

This approach is really practical. When using the tool, you can always meet the project goals by just resorting to writing code. And the ordinary development and deployment tooling stays the same.

But, this approach also hints at a way to accommodate layering in UIs that are better for certain tasks. For example, you can just select an element in the UI and change its padding. It's easier to find the right thing to manipulate. And the feedback loop is faster.

This approach can be easily expanded to include:

• All the other types of styling (margin, flex, color, font etc etc).
• Select an element to jump to it in code.
• Editing the attributes of arbitrary HTML tags. Currently you have to add an attribute to a tag to identify it as editable. But I think it would be possible to avoid this.

Edit data to change behavior

The core edit in the UI → code direction is changing a CSS class on an HTML tag. This is just editing data and is relatively simple to systematize - find the data in the code, make it editable.

Editing this data is powerful because it changes the behavior of the software. Even though it’s just data. But when you’re changing code to change a CSS class, you’re kind of hitting a nut with a sledgehammer. So the class editing UI is a little ball peen hammer that is easier and quicker and more expressive.

The problem comes when you want to invent a UI to edit behavior. This is much harder.

It even becomes necessary in some cases when you want to edit classes. For example, imagine you have code that colors a status message red if it’s an error, or black if it’s not.

The implementation might keep things simple and direct by just adding a red text class to the HTML element if the state indicates the status was an error message. But now there’s a problem. The CSS class is no longer pure data. It’s much harder to write a class name editing UI for this now dynamic code.

UIs that let you edit pockets of data inside behavioral systems can be better. But the bigger task is inventing the behavioral editors.

Pushing on the idea of manipulating different pieces of a React app

We can think more broadly about what parts of an app can be manipulated.

• Code
  • Pure data (CSS classes, tag attributes, literal values passed into props). Even the most inert of changes affects behavior.
  • Algorithm.
    • Layout logic. E.g. Adding components to the tree, adding HTML elements that define the output on the page. Things could be taken further by allowing the GUI to define data-driven layout, like mapping over an array to output components.
    • Other types of logic. There are fewer obvious ideas here. Editing predicates? Defining trigger events and their handlers is something that UI prototype builders make a lot of hay out of. Defining data manipulations (e.g. add a new object to this array)?
• State
  • Editing the data contained in component state.