I work on the Lit team at Google. A colleague there who went on to work on Flutter's VDOM-like system once said that React traded off CPU cycles for developer ergonomics and conceptual simplicity.
A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you repeatedly compare many nodes that will never show a diff, and that's just waste.
VDOM brought three important things to the table, initially paid for by that overhead:
* Template as values. JSX expressions produce JS values, and this is allows a functional programming approach to UI.
* Expressions and control flow in JS. This shrunk the domain of the template DSL to just the component nodes, and reused knowledge and machinery of JS. Theoretically that leads to faster and smaller templating.
* One-way data flow. This is a result of the first two items, but important on its own. Two way binding is nice sugar for some situations, but it makes it hard to reason about the state a template is in.
Those are really great aspects of the VDOM approach (for a class of programmers, markup based templates are great for others).
So the challenge to me had been to preserve those features, actually deliver on the smaller and faster part, and reduce the CPU overhead. That can be done with compiler-first systems like Svelte, but I think we get just as faster or faster, and as small or smaller with a pure runtime approach based on template literals, like we have with lit-html.
Template literals let us describe the static and dynamic parts of a template separately, so there's no VDOM overhead. We don't compare the output of template expressions, we compare the inputs to the dynamic bindings. It's often an order-of-magnitude less diffing work, and approaches the point where the required DOM operations are the limiting factor. So we get low-CPU overhead, templates as expressions, logic in JS, and one-way-bindings, with no compiler. I really think this is the best of both conceptual simplicity and overhead - preserving much of the VDOM model, but doing it faster.
I think this approach definitely has a lot of merit, but in terms of absolutes, it's still not quite there. Specifically, you're still going to be diffing as many bindings as a component has, be it one or one hundred, even if only one changed.
Another more micro-level issue is that dynamically resolving which DOM properties to update is polymorphic, so you don't get nearly as much JIT optimization compared to a compiled approach that outputs monomorphic static property assignments.
I quite like Solid.js' approach, which addresses both of these problems via a reactive data flow and aggressive compilation, while still providing a React-like experience.
A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you repeatedly compare many nodes that will never show a diff, and that's just waste.
VDOM brought three important things to the table, initially paid for by that overhead: * Template as values. JSX expressions produce JS values, and this is allows a functional programming approach to UI. * Expressions and control flow in JS. This shrunk the domain of the template DSL to just the component nodes, and reused knowledge and machinery of JS. Theoretically that leads to faster and smaller templating. * One-way data flow. This is a result of the first two items, but important on its own. Two way binding is nice sugar for some situations, but it makes it hard to reason about the state a template is in.
Those are really great aspects of the VDOM approach (for a class of programmers, markup based templates are great for others).
So the challenge to me had been to preserve those features, actually deliver on the smaller and faster part, and reduce the CPU overhead. That can be done with compiler-first systems like Svelte, but I think we get just as faster or faster, and as small or smaller with a pure runtime approach based on template literals, like we have with lit-html.
Template literals let us describe the static and dynamic parts of a template separately, so there's no VDOM overhead. We don't compare the output of template expressions, we compare the inputs to the dynamic bindings. It's often an order-of-magnitude less diffing work, and approaches the point where the required DOM operations are the limiting factor. So we get low-CPU overhead, templates as expressions, logic in JS, and one-way-bindings, with no compiler. I really think this is the best of both conceptual simplicity and overhead - preserving much of the VDOM model, but doing it faster.