Template literals

I like the basic ideas and line of thinking behind this library, but I’d like to suggest you consider using template literals.

The approach of internally serializing all values to HTML strings, and then parsing them and turning them back into HTML elements, isn’t very efficient.

Not having access to the original data within the template isn’t very practical - for example, if you have a Markdown string you want to render, you first need to unescape the HTML value, which didn’t need to be escaped in the first place.

Having a single option allowHTML to disable the encoding of all of the data isn’t very helpful either, since a single component could contain a mix of data types: raw strings, HTML, Markdown, numbers, booleans, objects, etc.

(It looks like you’ve gone back and forth on the idea of pre-escaping data between major releases of the library, so I guess you’re aware of some of the problems with this approach.)

Also, the strings approach is limited to updating HTML serialized string-attributes, as opposed to updating properties of HTML element objects, e.g.:

template: ({disabled}) => '<input ' + (enabled ? "" : "disabled") + '>'

As opposed to e.g.:

template: ({disabled}) => html`<input disabled=${ !enabled }>`

In practical terms, you might consider using (or supporting or integrating) something like htm, which generates fast rendering functions.

Alternatively, you might consider writing a basic HTML5 parser, which is surprisingly easy and would allow you to completely bypass unnecessary encoding/decoding of HTML - while allowing natural things like inline event-handlers, style object literals, booleans, etc. like JSX allows, but using browser standards.

I do realize this precludes native IE support (without transpiling) but at some point 94% has to be good enough, right? 😉

In summary, the biggest problem with this library, as I see it, is the idea that everything must be turned into strings before it can get to the DOM - this isn’t efficient or practical and, in a sense, the barrier between template functions and the browser object model currently is almost as high as it is between the browser and the server; in my opinion, with a client-side library, the template needs to be much closer to the DOM/BOM than this.

Also, per the README, “It doesn’t have a Virtual DOM”, which is true as far as the external API - but it does internally use the equivalent of a virtual DOM model.

In terms of the total round-trip from template to DOM, this is effectively more steps than a virtual DOM: from data values to HTML-escaped strings, to DOM objects via DOMParser, to your internal “details” model (the “virtual DOM”) and then finally diffing to the live DOM objects.

Compare this with a traditional virtual DOM approach, which doesn’t have the escaping or DOMParser steps - which makes me think, with something like htm in the mix, this would already be faster, simpler, and much closer to the DOM, in terms of templates mapping directly to HTML object properties, rather than taking the whole HTML escaping/parsing round-trip. (Also, htm can be optionally compiled away for even smaller footprint, if desired.)

If you want to truly avoid the virtual DOM step internally as well, as mentioned, you might consider a custom HTML5 parser - which might mean a bit more initialization overhead per template, but should yield substantially faster updates overall. (I’m happy to post a bit more information on this idea, if requested.)

Either of these approaches could also pave the way for proper support for components, possibly with life-cycles. (I know your stated mission is for this library to be an anti-framework, but have you tried manually managing the life-cycles of nested components? If every child component is a global instance as shown in the README, that’s easy - but if you have something like a custom drop-down or date-picker, and have to manually manage the life-cycles of component instances, this quickly gets out of hand.)

I think you have some nice ideas, but the basic idea of treating everything as strings causes too many practical problems.

Anyhow, this is just my personal analysis after some quick testing. Cheers! 🙂

[cjkoepke]

For what it’s worth, complexity and byte size are not always related.

[cferdinandi]

I’m referring to ease of use for developers who aren’t comfortable with or interested in the class syntax.

Anywho, we’re done here.