HTML UI with Emerj.js: A 60-line Answer to React
blog.brush.co.nz
blog.brush.co.nz
In positioning something as an "answer to React", I think it's important to note what React's goals are. The React site (https://reactjs.org) describes itself as a declarative, component-based library for building UI that you can "learn once and write everywhere". The crucial thing to note here is that efficient updates to the DOM are explicitly not a core justification for React.
In fact, React's virtual DOM is often described by React developers as an implementation detail, not as a reason for React's existence and adoption. The appeal of React is in its declarative composition model for building UI, which frees developers from tedious data-bound state management on the DOM and beyond (react-dom, react-native, react-vr, etc.).
I believe this lib is better positioned as an alternative to so-called 'virtual DOM' implementations, rather than as an answer to React, since it provides no answer to core React features (declarative, composable components that can target all kinds of platforms).
I think this looks neat. However, last time I implemented something like this, I ran across a few elements/attributes that didn't behave in the simple way I expected.
I can't remember the full list (and can't find my old code), but some things like the "class" attribute, and the "type" attribute of <input> don't like being dynamically changed, at least in all browsers. I think something strange happened with tables as well, and maybe <title>.
So, I ended up needing some special handling for these attributes/elements, in some cases creating a new node with the right attributes and swapping it in.
I don't see anything like this in the Emerj code, so I wonder if it has the same awkward corner-cases. I might go digging to see how DiffDom or DOMDiff or whatever it's called handles it...
Part of the purpose of Emerj is to actually avoid overwriting the current .value of inputs -- the idea is to preserve current element state that isn't represented explicitly in the DOM, so you don't delete something the user has just typed in (or <select>ed or whatever).
I haven't run into issues with classes or types or tables, though. I could imagine the implicit tbody potentially causing problems if you generate a DOM structure yourself without one, but in my case this doesn't matter because I use the browser to parse my HTML into a DOM, and it'll add a tbody.
Nanomorph has code to update live input values from the `value=` attribute, but that's actually something I've deliberately avoided for the above reason.