[samwillis]

The VDOM was never about performance problems with the actual dom. It was always slower as you still have to mutate the actual DOM. The "VDOM if faster" was always FUD.

The VDOM was invited to prevent bugs by removing the difficult of managing fine grade DOM mutations. Technically you are doing more work with a VDOM and diffing, than carefully mutating the DOM, it's slower.

Of course if you just threw away the whole DOM and re built it, then he's the VDOM was quicker, but that's not how anyone was building stuff.

[dimal]

It was not FUD. It’s not faster than carefully mutating the DOM, but back then, almost no one was “carefully mutating the DOM” all the time. It was a shit-show of ad hoc re-rendering strategies that often re-rendered excessively because no one has time to do it carefully for every case. For most common use cases, VDOM had great performance with little cognitive overhead.

[cztomsik]

There were other frameworks before React: AngularJS, Knockout.JS, Backbone.JS, ExtJS, and I'm probably missing few others... Most of them had a concept of props/dirty-checking/retained-mode and they were definitely faster than naive React.

What VDOM made easier (in terms of performance) was memoization, you could get faster if you carefully evaluated your dependencies, but to be fair, it introduced many edge-cases and many people avoid memoization to this day.

VDOM also made react-native possible, and it made cross-browser programming bearable (but other frameworks at the time did that too)

Now, one REALLY COOL thing about VDOM is fragments, because being able to render multiple elements from one component, makes certain layouts very easy using plain CSS - either with simple > * or even with CSS GRID.

I am not sure, if Svelte 4 can do that, but it's very simple thing to do with VDOM. And it certainly was not common feature for a very long time.