Virtual DOM is pure overhead (2018)
svelte.dev
Virtual DOM is pure overhead (2018)
1–10 of 344 posts
Re: Virtual DOM is pure overhead (2018)
#2[deleted]
Re: Virtual DOM is pure overhead (2018)
#3I have never used modern JS frameworks like Angular, React and Vue and I have always assumed (hoped) that they contained optimisations that you would be unlikely to use in your vanilla JS code even though you could. Something like FastDOM which batches read/write operations to avoid unnecessary reflows. Do they contain anything like that?
Re: Virtual DOM is pure overhead (2018)
#4Virtual 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.
Re: Virtual DOM is pure overhead (2018)
#5This is absolutely true.
Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code!
A large portion of JSX expressions are static, and renderers should never waste the time to diff them. The dynamic portions are clearly denoted by expression delimiters, and any change detection should be limited to those dynamic locations.
This realization is one of the reasons for the design of lit-html. lit-html has an almost 1-to-1 correspondence with JSX, but by utilizing the static/dynamic split it doesn't have to do VDOM diffs. You still have UI = f(data), UI as value, and the full power of JavaScript, but no diff overhead and standard syntax that clearly separates static and dynamic parts.
The syntax is very close:
JSX:
render(props) {
return
Hello {props.name}
{props.items
? {props.items.map((item) =>
{item.label})}
: No Items
}
;
}
render(props) {
return html`
Hello ${props.name}
${props.items
? html`${props.items.map((item) =>
html`${item.label}`)}
`
: html`No Items
`}
`;
}
edit: closed JSX fragment as pointed out
Re: Virtual DOM is pure overhead (2018)
#6Svelte's philosophy on turning the virtual DOM concept inside out sounds like it has merit, and is very promising. But it's going to take a lot more than that, in my opinion, before a large number of people consider switching from React, Ember, etc.
I don't see that as a drawback, I see it as an open opportunity for Svelte to keep building out on improvements other than the DOM updates, and catching up with everything else the SPA alternatives provide that have nothing to do with the virtual DOM.
For example, Ember is just a joy to work with, and makes it easy to rapidly prototype reactive frontends in a way that reminds me of Ruby on Rails's initial appeal to developer happiness, and the tooling is very mature. If you could unlock all those benefits while keeping the blazing fast DOM updates, oh boy!
Re: Virtual DOM is pure overhead (2018)
#7I have never used modern JS frameworks like Angular, React and Vue and I have always assumed (hoped) that they contained optimisations that you would be unlikely to use in your vanilla JS code even though you could. Something like FastDOM which batches read/write operations to avoid unnecessary reflows. Do they contain anything like that?
I'm not sure if this is exactly what you mean, but Ember.js has a concept called a "runloop" which batches different actions into queues, which does seem to help with rendering/reflows.
Re: Virtual DOM is pure overhead (2018)
#8[deleted]
Re: Virtual DOM is pure overhead (2018)
#9I have never used modern JS frameworks like Angular, React and Vue and I have always assumed (hoped) that they contained optimisations that you would be unlikely to use in your vanilla JS code even though you could. Something like FastDOM which batches read/write operations to avoid unnecessary reflows. Do they contain anything like that?
To varying degrees depending on the library, I believe the answer is "yes, they sometimes do". Angular and Ember at least have systems for batching user interactions, which translate into model updates, and thus potentially DOM updates. I believe the respective systems for handling this are called Zone and Backburner for Angular and Ember, but I've been out of touch with those projects for a couple of years.
There's definitely a trade-off, however. They make a huge difference for noisy events (like mouse move, scrolling, dragging, etc), but tend to make debugging much harder in my experience. When things go wrong, the stack traces nest deeply into the event handling systems and code paths no longer resemble the relatively straightforward world of traditional event calls, where a callback handler is invoked directly in response to a single event.
Re: Virtual DOM is pure overhead (2018)
#10Virtual DOM is pure overhead*
* Compared to doing static analysis and optimizing your UI updates at build time.
While I certainly agree that svelte's approach may be the future, I think React and others, are very much a needed stepping stone (especially when you consider all the work done transpiling JS code).
The Virtual DOM was the most performant solution that applied generally to many a large number of cases. The reason almost everyone did `x.innerHtml = html` is that it was the most general and widely available solution.