Switch to muhtml

[marcoscaceres]

Successor of hyper, lighter, html...

https://github.com/WebReflection/uhtml#readme

@WebReflection suggested it might be good for us to migrate. Good reasons:

https://gist.github.com/WebReflection/761052d6dae7c8207d2fcba7cdede295#dom-engines-features-comparison

Looks like it should be super painless to do so.

[WebReflection]

So ... beside suggesting some of my latest/greatest creations, I wanted to understand the respec use cases, hence I did some quick analysis of the current src folder.

Current Status

It looks like here and there you are using most hyperHTML features, including:

• partial attributes (only one single instance found in constrib.js
• wires with reference, and wires with both reference and a :>li ID
• HTML opt-in via [personName] and [companyName]
• bind here and there, including in Custom Elements (which is great, but you could bind just once in there or use right away HyperHTMLElement)

But what surprised me, is that 90% of the time you're simply using the library to create one-off DOM elements, fragment, whatsoever, except in those cases where you have dynamic lists.

There are also 2, admittedly great, workarounds, 1 about passing a fragment instead of a node, which seems like something I could improve in the TypeScript definition file instead of forcing you to ignore that case, and one regarding 404 errors when images are created.

What µhtml could solve

If it's some "one-off" that you need to create most of the time, html.node is there to do exactly that (or svg.node), but IMHO you can as well just use html and render(where, htmlThings) to keep the usage of html simple.

This will also automatically key once all things that don't change, so you can really update the whole UI in a single operation, passing data down.

You can also use references and IDs via html.for(ref[, id]) so even those cases would be covered.

However, with µhtml you won't be able to use sparse attributes values, and you cannot pass any HTML whatsoever, 'cause there's no way anything is injected as HTML.

That being said, with µhtml you won't ever see errors with images, because the template parsing and DOM creation is done in a completely different way, so that nothing ever land as real attribute until all specialized attributes are parsed while crawling the template fragment.

As example, <img src=${value}> would be parsed as <img uhtml-hole-0="src"> instead, and then patched once and once only without ever passing along undesired attributes data, only what you have there as value.

Needless to say that those attributes disappear right away, and every successful clone of the same template literal, as fragment, will be already mapped/optimized for this case.

The workaround needed for html is instead to have a div reference, div.innerHTML = personName and then pass along a document fragment with the div nodes in it.

A bit cumbersome, but at least an option.

What lightrehtml could solve

Differently from µhtml, lightrerhtml shares exact same template parsing technique hyperHTML uses, meaning the <img src=${...}> gotcha would still be there.

However, all rendering simplifications and benefits previously described in µhtml would be there, with also the ability to explicitly pass HTML via {html: personName}, whenever it's needed, which would require pretty much close to zero refactoring for those special, and sporadic, cases.

lighterhtml supports also sparse attributes, even if I've found only one case that's easy to patch, so that current or future code could benefit from it.

Also worth saying, once you have lighterhtml in, switching to uhtml would be a no brainer, as these two have exact same API and utilities.

The most important question though ...

Beside those two gotchas with TS ignore and the image src attribute, it really looks like hyperHTML served you well so far, so I wonder what would you expect from switching to other libraries, beside the obvious perf advantage in size, in the uhtml case, or rendering.

We've been using hyperHTML in production for more than a year and a half, and it really worked well for all our cases, which is the reason the library is still maintained for obvious bugs, but just not something I would personally use for my next thing, as both lighterhtml and uhtml are today a better alternative, but I also wouldn't change library just for the sake of it, specially because for your current use case, unless you trash the whole layout per each update, I don't see any concrete benefit that would make it worth it.

In few words, can anyone please confirm your most common use case is to create persistent one-off nodes, as opposite of needing references for all the things 'cause there is a lot of DOM trashing?

Thank you.

[WebReflection]

P.S. something I've forgotten to mention, latest hyperHTML supports attribute setters, as in .src=${value} for images, as example, and in that case there won't be ever a 404, because the template parses that exactly as .src attribute, not as src, hence no triggering with temporary interpolated data ever happens.

This is true for all the 3 libraries I've mentioned already, they all support .setter=${...} for this and other reasons.

[saschanaz]

can anyone please confirm your most common use case is to create persistent one-off nodes

Yes, true.

[WebReflection]

@saschanaz if that's the case, as I've seen new files using import hyperHTML as html which is exactly what I'd do in your most common use case too, what are the main pain-points that you encountered, in using html... to create one-off dom nodes, beside those two cases I've mentioned?

my only concern is that you'd be after a big refactoring, for no real-world gain, and dare I say it'd be the same with any other framework out there.

thanks for expanding, and helping me out understanding how can I eventually help

[saschanaz]

what are the main pain-points that you encountered, in using html... to create one-off dom nodes, beside those two cases I've mentioned?

Can't recall everything but one thing is that we had to insert ${" "} like hyperHTML`<a href="#${link.id}">${link.title}</a>${" "}` to insert a space, because otherwise it will be trimmed.

[WebReflection]

that's an interesting case, as everyone else, apparently, expects templates to always be trimmed ... can you please remember in which case it was needed?

const link = () => hyperHTML`<a href="#${link.id}">${link.title}</a>`
const bound = element => bind(element)`This is ${link()}`;

bind(conteinare)`This is ${bound($('#element'))} !`;

all of that should work, meaning the case for a space seems very specific to a CSS gotcha, otherwise as nested interpolation you can always put spaces around, unless I am missing some use-case here, thanks!

[WebReflection]

P.S. however irrelevant this is, when you have a space around a node, and that node is the only one in the template, the derived fragment content would contain one node, and one text node, resulting into a persistent fragment operation, that is usually bad for performance (not "that" bad, but worse).

For this reason, my libraries trim templates so that you can write:

html`
  <the>thing</the>
`;

without worrying about ending up in the slower, persistent fragment, based path, so instead you get a node to handle that is nothing different than such <the> element.

This, of course, is a compromise between developers expectations in terms of perfs, and usage of the library out of the box.

However, your very (imho) exceptional case, seems to need the extra space at the end, as you were doing:

fragment.appendChild(declaredNode);
fragment.appendChild(document.createTextNode(' '));

which is a hard to reason about practice, as the latter node shouldn't be needed, right?

[WebReflection]

P.S.2 to be clear with terms, wires in hyperHTML are "maybe fragments", while bind are "containers" ... the "maybe fragments" bit means that, if you have holes out of the box, as in hyperHTML`this is ${hole1} and ${hole2}` , those 4 nodes are inevitably handled as persistent fragment, but if you have hyperHTML`<div>this is ${hole1} and ${hole2}</div>` you have a single div node instead, which is the "fast path" in general.

[saschanaz]

can you please remember in which case it was needed?

It's from:

https://github.com/w3c/respec/blob/a7d64f4e8805ce4c0154f8b27a67347431995794/src/core/dfn-panel.js#L114-L124

This code wants to insert a space after each anchor.

[WebReflection]

Wouldn't an   solve that case? (haven't tried though) ... but the thing is, unless I explicit export an utility a part for this edge case, none of the alternatives would solve that, for the previously mentioned reasons.

[saschanaz]

  will literally not break so no, but   may work.

[WebReflection]

@saschanaz I have found another solution that's proven to work well. The chosen name is <sep/> but it could as well be a valid custom element name such as <a-space/>.

It's more like a workaround, but I believe it's a very semantic one:

import {bind, wire} from '//unpkg.com/hyperhtml?module';

bind(document.body)`
  <ul>
    <li>
      ${[1,2,3,4,5].map(n => wire()`<span>${n}</span><sep/>`)}
    </li>
  </ul>
`;

The <sep> tag has its own CSS definition:

sep::after { content: ' '; }

As there are more than a work around for this very edge case, I think exposing a non trimming functionality would be unnecessary at this point.

What do you think?