Some hyperHTML advice

[WebReflection]

First off: pretty awesome stuff !!!

One thing hard to grasp about hyperHTML though, is the convention to distinguish between HTML and sanitized/raw text content.

For instance, in your test you wrote:

render`<h1>${this.foo}</h1><input value="${this.bar()}" />`;

indicating you want to enable html, nodes, fragments, or arrays, within that h1 tag.

However, the test checks for textContent, so that I am assuming that you really want to be sure no HTML goes into that tag.

render`<h1> ${this.foo} </h1><input value="${this.bar()}" />`;

Can you spot the difference?

While famous templates have the {{maybe-text}} vs {{{maybe-HTML}}} convention, hyperHTML, and same goes for viperHTML, consider special everything between > and < .

Put just one extra char around that, and it's ensured to be threated as textContent, boosting performance even more, simplifying parsing and also sanitizing automatically through the native DOM.

Recap

• This is handled as text <h1> ${this.foo} </h1>
• This is handled as html <h1>${this.foo}</h1> or even as an array of nodes, or just a node, everything but "just text"

---

About the rest of the test component, I love the idea of "starting fresh" but I don't see real-world value, rather a duplicated template.

This, of course, gives you the ability to produce completely different layouts for a single component, but is that actually a good, desired, design goal?

In these cases I would probably do something smarter like creating two wires and swap them instead of trashing the previous layout, but it also covers different needs/scenarios so ... I'd like to udnerstand more about this trashing case, thanks.

---

About the render method, it looks good but this specific line is not optimal:

template.call(this, hyperHTML.bind(this));

We all know that compared to any DOM operation, creating a new bound function is 100x cheaper, but maybe you could store that bound function once and forget about it forever instead of recreating it N render calls times?

template.call(
  this,
  this._hyperRender || (this._hyperRender = hyperHTML.bind(this))
);

Or any alternative that better satisfies your coding taste 😄

[csuwildcat]

I wasn't aware of the significant difference caused by surrounding tag content with whitespace. Is there a way to support a more explicit syntax for this? I ask because managing/reviewing whitespace presence is a rather tedious task, imo.

The reasoning for multiple template support was that some components may have very different UI representations - consider a <x-clock> component with two template options, digital and analog, which both use the same data, but have a very different content structures for displaying it. While I suppose one can argue you could make that decision with embedded dynamic eval inside one template, I feel it is much cleaner to offer the ability to separate the two. Thoughts?

[WebReflection]

There's no way I can understand if you want to inject HTML or plain text, it's explained in the deep dive too.

Moreover, 'Hello ${name}' results into a targeted text mode , it wouldn't make sense to have HTML, nodes, or something else there.

Truth is, hyperHTML has only 3 rules.

Other template engines have {{{this}}} instead of {{this}} and I never know if that's HTML or not.

In hyperHTML it's very simple: is that HTML? No spaces or other chars around. Otherwise its text content

[csuwildcat]

I'm not saying I can't live with whitespace being the delineation between the two, just that it seems the code review, maintenance, and debugging ergonomics may be negatively impacted.

Either way, I am happy to have a diffing, fast, lightweight option for templating available. I will add a section on hyperHTML when we update the site for 2.0

[WebReflection]

If you have suggestions on how to instrument template literal son a way as simple and as short as adding one space I'm listening. Spaces means mostly nothing in HTML so ...I think people just need to get used to hyperHTML only thing to remember

[WebReflection]

FYI latest hyperHTML has no spaces anymore and attributes can be written without quotes. There are also various changes since this issue was opened, so I'll close this as not relevant anymore.