The Elements of UI Engineering

Your approach seems to create an abstraction on top of react where the next step could only be a DSL. This is a first indicator for me that the developer will loose those programming capabilities that react carefully tries to retain and I'm not sure if this is a good approach. I think this doesn't solve the problems of entropy that Dan mentioned in his post and please let me explain a bit further...

I think of JSX as a declarative way to redefine HTML and to make it fit to the desired design. Sometimes it's quite possible to find a common behavior of a component and it can become part of a library, but that's not always the case. I like to use react components as a slim layer and prefer to do the work (side-effects, data processing etc.) somewhere else (purely functional modules, redux-saga etc.). My goto-rule to create components became the following: "if I start naming my component with something else than with layout-related terms, then I'm using react as the wrong tool for the job". React is just the view layer, a data processor that puts the view-data into the DOM. And as such a view layer it's sole responsibility is to render conditionally, the responsibility that your linked library tries to extract. I personally prefer to read through early returns in the render method of a component as opposed to following the order of an array.

There are behavioral UI problems in an SPA that are not related to the DOM itself. React can't do much about that and I think the problem of entropy stems from there: In the app at work one of the biggest struggles was to keep a global lock for a modal. This modal can pop-up to the user and show a notification, confirmation, form etc. Modals should never overlap with each other, give the user all the time she needs, but should also follow priorities (i.e. a push-notification to cancel the session being one of the highest). The difficulty in managing this lock was that actions from everywhere can pop-up that modal, be it a push notification over websockets, functions called from the native side, failed/succeeded API calls or behavioral inputs that should work differently all over the app (i.e. barcode scanning a product will search for a product in one view, will add it to the cart in another, or will prompt for a follow-up action if no product could be found). Thanks to redux-saga, we can make use of actions not solely to update the store state, but can additionally (if ignored by the reducers) use them like a message bus in a concurrent system. So with redux-saga (and inspired by elixir) I could make use of the actor-pattern and build a supervisor saga that keeps this behavior maintainable, but there is way to much complexity in this.

Point being, react and redux do a great job at managing entropy as long as it's used in the correct way. I think each component that doesn't take props can in fact be the starting point into it's own (micro-)application. But I think the biggest difficulties are external influences for an SPA - those interconnected influences that make the web so attractive for an application.

EDIT: typo

> What's a route?

A route is the thing that I send to another person or save myself so that the specific piece of information I am looking at can be found again. There is a decision that has to be made, though. My selected text is never part of a route, but that might be the information I want to share. Conversely, when I open a hamburger menu to click the share button, the hamburger menu's open state is never the information I want to share.

Another consideration: does the route encompass the concept of the information being displayed, or the actual information? We typically solve this with a "permalink", where one route represents the concept (feed, newest, etc) and the permalink represents the specific information.

What you want is gopher[1]. Instead of AMP I think sites could honor requests with an text/plain header, the issue is monetization. But AMP is for content based sites, SPA capture a completely different use cases.

[1] https://en.m.wikipedia.org/wiki/Gopher_(protocol)

This is why I always liked Cocoa (macOS native UI toolkit) and still prefer it over web UI when writing native apps. It separates out the concepts of layout, appearance, and behavior, and lets you customize any one of them without needing to readjust the others. I just released an app this morning here that uses a non-trivial amount of Cocoa, and it would be full Cocoa if there was a Cocoa-version of the excellent Monaco editor. I feel like there should be a web version of this sort of "old-fashioned" toolkit that has a timeless ease of use once you get over the learning curve.