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.

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.