3 ms·
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. Sce
by 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.
- kevingadd 7y agoThat's the cost of the operation you're performing, it has nothing to do with whether you're using the DOM or not. If you want the size of the element, someone has to perform layout - either the browser engine, or your virtual DOM. The dimensions it was created with are in attributes and CSS. You can check those without causing layout. If you want to check the layout result, you have to perform layout. Virtual DOMs are not magic. I've worked on browser engines. You misunderstand why parts of the DOM are and aren't slow, even if you understand Virtual DOMs. Property accessors (what was the 'width' attribute set to?) are easy to optimize and most of the obvious slow ones have been optimized by self-hosting to the point that they can be inlined.