That perception of the DOM/VDOM situation is and always was false. React was always slower at runtime than a carefully-engineered system designed for performance.

As Dan Abramov said a couple of years later <https://medium.com/@dan_abramov/youre-missing-the-point-of-r...>, people were missing the point of React: it was never about VDOM; rather, that was a cost that at the time they reckoned had to be paid in order to write reliable code in an immediate mode style, because if you tried doing that without DOM reconciliation the result would be atrociously bad. VDOM came about because the alternative (the consistently faster alternative, I may add) entailed things like explicit DOM mutation that was far too easy to make mistakes with, and reactive data flow was generally even buggier. It was a carefully-chosen trade-off: shedding some performance, for greater robustness and ease of use.

“DOM is slow, VDOM is fast” was a straw man comparison that entered the public perception but which the React team mostly stayed well clear of: almost no serious systems have ever used the DOM directly in the immediate mode style, because it has obvious and serious problems in both performance and transient UI state like scroll and caret positions and element focus (… and transient state things are problems for all immediate mode interfaces, not just DOM ones: escape hatches are fundamentally required).

Was VDOM worth the cost at the time, compared with the other options then available? For most people, probably. And even for the rest, React presented useful food for thought that led to other options improving too. Is VDOM worth the cost now? Well, I’m with Rich Harris that VDOM is pure overhead <https://svelte.dev/blog/virtual-dom-is-pure-overhead> and that we have more efficient ways of doing things now.