Thread by @slightlylate

I can't say it enough: "vdom" is not fast. It is slow.

The only *defensible* claim is that it isn't as slow as one might think given how much overhead it adds...but that doesn't make it competitive or good.

https://twitter.com/slightlylate/status/1450133114571812864

Why is vdom slow?

It does too much work.

Computing diffs through something like React's reconciliation algorithm is a clever way to avoid needing to have knowledge of the potential changes that can occur on either the JS or DOM side.

But it's correspondingly very expensive.

Reactive systems that constrain *either* how you update DOM (e.g. Lit's template system) *or* cabin the effects of JS side-effects (Svelte's "reactive declarations", FAST's Observables) deliver superior performance because they don't need to model + compare the whole world

Now, React and other vdom systems have ways of saying "don't diff me bro!", but they don't reduce the memory and GC overhead of diff management, and they're error prone.

But most importantly, they aren't the default. Which means the default is *SLOW*.

There are other ways that the toolchains that tend to come with React (hilariously, justified by performance concerns) tank startup and destroy the first best chance to make a good impression with users...but just know that the core is *also* slow.

By design.

Someone will inevitably slide into my DMs with DBMon whataboutism. *Sigh*.

Every framework can tune for hot paths (usually by getting back to NOT diffing). But the question is average costs across components built the usual way.

The problem of hot repaint loops is exotic and unusual.

Yes, it happens. Yes, perf matters there. But it's so rare as to be a special case.