
HTML UI with Emerj.js: A 60-line Answer to React - bryhoyt
http://blog.brush.co.nz/2017/11/emerj-js-efficient-html-ui-in-60-lines/
======
lettertwo
This is a clever lib, nicely done! I'm writing in to say that I think your
presentation of it could benefit from some focused revision.

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](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).

------
signalsmith
I've submitted a comment on the site but I'll post it here as well:

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...

~~~
bryhoyt
That's cool. I'd be interested to see your code if you ever run across it
again.

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.

