This is great! A few comments/questions if you have time to respond:

1) I thought that React already worked this way until I learned it, and was horrified. Similar disillusionment with Ruby on Rails, Objective-C on iOS and Java on Android. Why someone would want to mix code and markup, rather than define components via code to be used within markup, blows my mind. Said as someone who uses PHP daily and sees JSX as its frontend analog.

2) I appreciate that async/await and promises were deliberately left out of the spec. I view their use as an anti-pattern, since I've programmed both async/nonblocking and sync/blocking sockets logic, and view sync as far superior if deterministic behavior is the goal. I know this is a contentious subject, but IMHO async will someday be considered the goto of the web and be deprecated across most languages. Better approaches such as scatter/gather arrays, coroutines and channels (like in Go) exist to remove the temporal/imperative aspect of logic and make it declarative without requiring red/blue functions.

3) The main problem I've encountered with React is that it's nearly untraceable in web inspector. It's impossible to tell which component object instance is associated with an HTML element. It's hard to tell where attribute values came from, unlike function arguments: are they props that aren't declared in a function prototype? are they magically mapped from redux state? are they derived neither in the constructor nor componentDidMount() or affected by an affect they weren't supposed to be? etc etc etc. Component methods are buried in dozens of anonymous functions and boilerplate. Promise values can't be inspected until their then() method without using tricks like Promise.resolve(), which don't always match intuition. Redux state can't be conveniently inspected without adding debug lines to the source code and/or installing a browser extension. Code gets mutated by the build pipeline so it's hard to find code snippets to set breakpoints. I could go on. Have you found ZjsComponent easier to debug, and if so, how?

4) I applaud your use of caching for client-side includes. IMHO much of the complexity of React is around its deliberate rejection of HTTP idioms and metaphors. We already solved these problems declaratively in the mid 1990s, why are we manually managing initialization and state, even if through Redux? That was a rhetorical question, but really, React doesn't seem nearly as reactive as something like a spreadsheet that just re-renders cells that reference cells that changed. Basically all of its component methods could be replaced by the render() method containing a JSX template, with the state boilerplate handled by the framework internally via declarative and data-driven techniques like observing variables for changes. Instead, they put the onus on developers, which wastes all of our time and sanity.

5) Do advanced use cases such as components built with other components, subresource integrity (SRI) and observing variables similarly to Vue.js watchers "just work"? I'd be curious to hear your vision for the future.

6) (Special mention) after driving myself crazy manually managing recycler views in iOS, Android and React, I wanted to highlight https://github.com/splinesoft/SSDataSources and https://github.com/SDWebImage/SDWebImage (no affiliation with either). The idea is to populate callbacks to handle the lifecycle of table view cells. That way, an array or generator in memory can be mapped to a table and automagically handle all scrolling and resizing edge cases. Including dynamically loading images and other async data with caching via SDWebImage, without crashing when navigating between view controllers that get disposed, while running as fast as possible. With these metaphors, all other GUI elements can be derived. These are the only frameworks that I've ever used that do all of this correctly. Which let me do declarative web-style programming natively by treating tables as already fully populated, rather than building rows and columns programmatically. Perhaps something in this could inspire a ZjsComponent that "just works" like an ordinary web table, but fast, without the memory hogging of the browser DOM or React's virtual DOM.