This isn't true. DOM access is fast. DOM manipulation is also fast. The issue is many DOM manipulations happening all at once constantly that trigger redraws. Redrawing the DOM can also be fast if the particular DOM being redrawn is relatively small.
React was created because Facebook's DOM was enormous. And they wanted to constantly redraw the screen on every single interaction. So manipulating multiple elements simultaneously caused their rendering to be slow. So they basically found a way to package them all into a single redraw, making it seem faster.
It’s the interlacing that’s the cost. Read after write forces redraw.
My big win on my first AJAX app was splitting read and write into two phases to reduce a page load from 30s on IE6 down to about 2 seconds. I didn’t even have to rearchitect. It was one loop in one (maybe 2) functions. Just had to split it into 2 loops.
If React wins (which I don’t agree that it does, but don’t want to have that argument), it’s that it allows you to compose tricks like this across a whole page instead of one component type.
All of the issues with reflow, layout invalidation, forced layout on property access, recalculating styles, which require careful solutions like batching change operations and optimized rendering strategies, will also affect anything operating on the DOM via WASM.
The point stands; maybe a faster VDOM can be built in a compile-to-wasm language, though the bottleneck will remain the browser's DOM API and rendering, not the language interpreter.
