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.
The idea that the DOM is slow and that v-DOM makes it faster is completely ridiculous. V-DOM can only optimize user land code. DOM manipulation will always be at the mercy of the browser implementation.
Yeah, it is a better approach than badly optimized jQuery style code, no shit, but it's not really the fastest approach either as others like Svelte and Imba have demonstrated.
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)
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.
That'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.
