3 ms·

Spoiler: there will be performance concerns. The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exis

Spoiler: there will be performance concerns. The bottleneck is in the DOM operations themselves, not javascript. This is the reason virtual-dom approaches exist: it is faster to operate on an intermediate representation in JS than the DOM itself, where even reading an attribute might be costly.

naythaniel 1y ago
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.
- ricardobeat 1y ago
  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.
- hinkley 1y ago
  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.
hinkley 1y ago
From my own time in the trenches working on ridiculously complex and dense web UIs: I’ve always found this a bit specious. And indeed there are any number of libraries out there that are 4x faster than React these days. The problem is not access it’s pipelining. When the DOM is relatively homogenous there are simple code transformations and idioms that increase the render throughput by 10-50x or more. It’s interlacing reads and writes in a sequence that’s murder. So when you get to a heterogenous DOM with many different people working on different parts, it gets awkward to prevent the interlacing. The virtual DOM is one way to force the separation, but it’s not the only way and it adds a lot of overhead, both computationally and cognitively. I can’t wait for it to die in a fire.

naythaniel 1y ago

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.

ricardobeat 1y ago
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.
hinkley 1y ago
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.

hinkley 1y ago

From my own time in the trenches working on ridiculously complex and dense web UIs: I’ve always found this a bit specious. And indeed there are any number of libraries out there that are 4x faster than React these days. The problem is not access it’s pipelining. When the DOM is relatively homogenous there are simple code transformations and idioms that increase the render throughput by 10-50x or more. It’s interlacing reads and writes in a sequence that’s murder. So when you get to a heterogenous DOM with many different people working on different parts, it gets awkward to prevent the interlacing. The virtual DOM is one way to force the separation, but it’s not the only way and it adds a lot of overhead, both computationally and cognitively. I can’t wait for it to die in a fire.