My FE/DOM Libraries

• hyperHTML: early 2017, first of a kind, early design, battle tested
• lighterhtml: late 2018, much better DX and easier to integrate than hyperHTML
• µhtml: early 2020, it's an essential subset of lighterhtml

hyperHTML Pros and Cons

• shipped to millions since 2018, enterprise grade
• today is best used via its HyperHTMLElement helper
• it included too many features that are rarely used
• it's features complete, mostly maintenance only
• it has a viperHTML SSR counter part, but it's been deprecated

lighterhtml Pros and Cons

• smaller than hyperHTML but even if it shares most of its core, it's faster in most cases
• it has a superior DX compared to hyperHTML
• almost every internal behavior can be customized
• it plays better with hooks and ref=${...} pattern

µhtml Pros and Cons

• it's an essential lighterhtml subset, for half of the size
• you can start small, and switch to lighterhtml without touching code
• the only cons is that is a subset with its own constrains and/or limited features

Pretty much all my libraries share the same code behind the scene. The difference is in the user-facing API and the pattern provided by such API (hooks vs Custom Elements vs just render, etc).

If you find a bug in heresy, as example, and it comes from augmentor, everything else hooks based will be patched automatically.

Same goes for lighterhtml and hyperHTML, sharing domdiff module and much more: if I fix something there it'll propagates everywhere else.

uhtml is a little exception to the latter case but ... well, it's tiny indeed, so it's the easiest to patch/maintain, specially 'cause it's code is mostly a copy/paste from lighterhtml, so that if I fix one, the other would pseudo-automatically follow.

All render engines avoid DOM trashes as much as they can. There are basically two ways to do this: use an index, automatically recycling the same node with such index, or use an explicit reference, manually coupling a specific part of the stack to such reference.

µhtml and lighterhtml support both approaches: in the former case, each node keeps being updated with new info, if found at the same position it was before, and only if the the new info changed, keeping data and UI strictly decoupled.

On the other hand, all rendering engines allows explicit references: same reference gets same node/stack each time, and DOM nodes are moved around whenever the reference is found in another position (i.e. list of items).

In the µhtml and lighterhtml case, the index, auto-keyed, approach, is the default, but you can always use html.for(...) or svg.for(...) to switch to the keyed pattern, following an example:

// auto-keyed lists example
render(viewNode, html`
  <ul>
    ${items.map(item => html`<li>${item.text}</li>`)}
  </ul>
`);

// manually keyed lists example
render(viewNode, html`
  <ul>
    ${items.map(
      item => html.for(item)`<li>${item.text}</li>`
    )}
  </ul>
`);

However, if the list of items have a unique id, you can always use <li data-id=${item-id}> in case you need to retrieve the associated data later on.