A a high level there's not much difference between template literals and JSX, they are both syntax-sugary ways to represent trees of essentially function calls.

> efficiently update just the changed portions

Since actually applying each change to the real DOM is too slow, the only way to efficiently update is to batch changes and then apply the delta to the actual DOM.

That means we need to keep track of some state, namely the previously applied state and the current goal state, which you then compare.

Now, you may have noticed that we've just independently invented the concept of diffing. And the extra state that needed to be tracked can be given a spiffy name, like "virtual DOM", since it's like the DOM, but not the real thing.

So, I'm quite unconvinced by Lit-html's claim that they are able to efficiently mutate the DOM without using a vDOM anywhere.

Either their method is not efficient (for example it falls over for rapid updates), or there is a data structure under the hood that is analogous to a vDOM, even if they prefer to give that data structure a different name.

Oh well, we gotta thanks the great developers of Lit-html for making it transparent then. And a lot faster than React.

https://krausest.github.io/js-framework-benchmark/current.ht...

Yes, looking it into it more, Lit-html is doing a few things to make it all work:

1. It leans on support for the <template> element from browsers to hold fragments of HTML

2. For most use cases, it has a more restricted programming model compared to React or other vdom libraries, because templates are not allowed to change the shape (the tree structure of nodes) of the templated DOM.

3. For some cases where you want it to act more like React (for example, dynamically picking an HTML tag) you must use other mechanisms such as unsafeStatic. The docs explicitly tell you this immediately triggers a re-render = slow.

So I guess that answered my own curiosity: the vDOM is mostly replaced by a collection of static templates that don't need to be diffed, because the onus is on the dev to write DOM fragments where the tree does not change.

This is a more restrictive model that what React gives you, where you can generate any fragment tree, including ones with different shapes, entirely programatically.

If you do want the tree's shape to change, then lit-html isn't promising you good performance. You'll need to use methods like unsafeStatic which are slow. All in all, this is pushing more work off onto the developer.

Is this a good tradeoff? I think for most websites you can probably work within Lit's programming model. But the benchmarks you yourself linked points to many, many vDOM libraries that are about as performant as Lit (including React, whose main downside somewhat more memory usage) and has a more convenient React-like programming model.

Thanks for the comprehensive analysis, quite interesting.

I disagree about the trade-off in convenience tho, React programming model (especially related to managing state) is quite confusing, verbose and error-prone.

Multiple useless re-renders are the norm.

useEffects inside the body of functions a very poor way to manage the lifecycle of a component and this is way simpler with Lit.

All in all, just for it to be more like React pre-15 I would choose Lit.