3 ms·

Virtual DOM is a shaky long term bet since it's essentially betting that the cost of DOM operations will always be high enough to justify all the work you're do

Virtual DOM is a shaky long term bet since it's essentially betting that the cost of DOM operations will always be high enough to justify all the work you're doing (both at runtime and at trying-to-figure-out-how-to-write-this-code time). When it's easy to do your virtualization, you can just go 'well this is an optimization i can remove at any point', but if it's suddenly so complex it introduces bugs, you're in trouble. Naturally, the cost of DOM operations didn't go unnoticed and while people have been going in on virtual dom solutions like React, the devs of Firefox, Chrome and Safari have all been aggressively optimizing the dom - making the native code bits faster and moving more of the DOM into javascript so all your JS can get inlined and optimized. It gets harder and harder for libraries to compete with regular DOM as a result.

striking 7y ago
react-dom (https://github.com/facebook/react/tree/master/packages/react-dom https://github.com/facebook/react/tree/master/packages/react...) is shipped as a dep of react, and seems to be where all the heavy lifting is. I believe that, should DOM ops become fast enough that you don't need vDOM anymore, you could easily no-op all of this out with direct DOM calls.
mantap 7y ago
Surely JS engines are also optimising React-style code. e.g. the article says that react style code does a lot of unnecessary object creation (e.g. map) but if that is now a common pattern then JS engines can do a lot to optimise that away.
- kevingadd 7y ago
  You can optimize the unnecessary operations but it's a lot more work to fully determine that they're unnecessary and erase them.
addicted 7y ago
Well, you could also potentially have a future where the VDom is the primary Dom in itself. As in, the VDom doesn’t need to be converted to HTML for the browser to render, but rather, the browser directly converts the VDom objects into Pixels.
pier25 7y ago
The cost of the DOM operation is the same. The difference is that React batches the changes to reduce the number of operations whenever possible.
- Sawamara 7y ago
  Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst, it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its several orders of magnitudes faster compared to a badly written DOM-manipulation-heavy code.
  - kevingadd 7y ago
    You overestimate the cost of modern DOM operations. It's a battle between your virtual DOM (to optimize DOM operations without lots of diffing overhead) and the native DOM (which is frequently a bunch of JS that can get inlined and avoid duplicate work)
    - Sawamara 7y ago
      No I do not. You will have to work very hard to back up the claim that modern DOM operations are not costly. Plenty of lookups can cause repaint or reflow. Scenario A: (Vdom-like approach) - Render x with dimensions x,y,z,w. - Store the reference to the created DOM elements. - Store dimensions it was created with If you do not go towards this way, and actually query DOM-land to get the dimensions you need to check against, you will run into issues. By storing your state alongside the endpoint, you will only have to diff against the stored state and props, not the endpoints themselves. That COMPLETELY bypasses DOM access, and only updates the changed elements. Show me how bypassing this and just using dom alone is superior. Or how adding layers of layers of js-land checks is not approaching the solution that vdom and differs already arrived at.
      - 7y ago
tannhaeuser 7y ago
DOM operations (node insertions, deletions) are trivial. It's the CSS reflow/relayout that's expensive. Though that can be trivially solved by preparing a shadow DOM off-screen, then finally replacing the changed fragment by the newly build-up one. DOM diffing is just a convenient method to do it.

striking 7y ago

react-dom (https://github.com/facebook/react/tree/master/packages/react-dom https://github.com/facebook/react/tree/master/packages/react...) is shipped as a dep of react, and seems to be where all the heavy lifting is. I believe that, should DOM ops become fast enough that you don't need vDOM anymore, you could easily no-op all of this out with direct DOM calls.

mantap 7y ago

Surely JS engines are also optimising React-style code. e.g. the article says that react style code does a lot of unnecessary object creation (e.g. map) but if that is now a common pattern then JS engines can do a lot to optimise that away.

kevingadd 7y ago
You can optimize the unnecessary operations but it's a lot more work to fully determine that they're unnecessary and erase them.

addicted 7y ago

Well, you could also potentially have a future where the VDom is the primary Dom in itself. As in, the VDom doesn’t need to be converted to HTML for the browser to render, but rather, the browser directly converts the VDom objects into Pixels.

pier25 7y ago

The cost of the DOM operation is the same. The difference is that React batches the changes to reduce the number of operations whenever possible.

Sawamara 7y ago
Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst, it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its several orders of magnitudes faster compared to a badly written DOM-manipulation-heavy code.
- kevingadd 7y ago
  You overestimate the cost of modern DOM operations. It's a battle between your virtual DOM (to optimize DOM operations without lots of diffing overhead) and the native DOM (which is frequently a bunch of JS that can get inlined and avoid duplicate work)
  - Sawamara 7y ago
    No I do not. You will have to work very hard to back up the claim that modern DOM operations are not costly. Plenty of lookups can cause repaint or reflow. Scenario A: (Vdom-like approach) - Render x with dimensions x,y,z,w. - Store the reference to the created DOM elements. - Store dimensions it was created with If you do not go towards this way, and actually query DOM-land to get the dimensions you need to check against, you will run into issues. By storing your state alongside the endpoint, you will only have to diff against the stored state and props, not the endpoints themselves. That COMPLETELY bypasses DOM access, and only updates the changed elements. Show me how bypassing this and just using dom alone is superior. Or how adding layers of layers of js-land checks is not approaching the solution that vdom and differs already arrived at.
    - 7y ago

tannhaeuser 7y ago

DOM operations (node insertions, deletions) are trivial. It's the CSS reflow/relayout that's expensive. Though that can be trivially solved by preparing a shadow DOM off-screen, then finally replacing the changed fragment by the newly build-up one. DOM diffing is just a convenient method to do it.