For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.
Virtual DOM is pure overhead (2018)
11–20 of 293 posts
Re: Virtual DOM is pure overhead (2018)
#12The most important line:
> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.
Declarative, state-driven UI development is a valuable abstraction.
I really hope readers take this to heart, rather than the article title becoming a new meme.
Re: Virtual DOM is pure overhead (2018)
#13Okay, but - why does Rust frontend libraries (like Yew and Seed) use vdom instead of doing whatever Svelte does? Actually, is anyone else doing it the Svelte way?
There are some VDom-less libraries popping up now. https://github.com/sycamore-rs/sycamore
Re: Virtual DOM is pure overhead (2018)
#14You could also say Python is pure overhead. You can write any Python programme in C, but more efficiently! C is faster, and therefore better. This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually wor…
> This article avoids the fact that declarative programming has proven to be more pleasant for most people.
No it doesn't. Second-to-last paragraph:
"It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones."
Re: Virtual DOM is pure overhead (2018)
#15You could also say Python is pure overhead. You can write any Python programme in C, but more efficiently! C is faster, and therefore better. This article avoids the fact that declarative programming has proven to be more pleasant for most people. And React simply is fast enough for most use cases, even though it has a performance penalty compared to Svelte. The virtual DOM is an elegant optimisation that usually wor…
> This article avoids the fact that declarative programming has proven to be more pleasant for most people. No it doesn't. Second-to-last paragraph: "It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is…
You're right! Seems like I skimmed over that part. My point still stands, though.
Re: Virtual DOM is pure overhead (2018)
#16I think this 3 year old topic needs to be revisted considering the improvements that Concurrent mode will provide.
Re: Virtual DOM is pure overhead (2018)
#17For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.
For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.
Re: Virtual DOM is pure overhead (2018)
#18This blog says what I've always thought - that to keep a large web application performant, you need to eliminate all redundant calls and operations, even in to pure JavaScript code - not just DOM calls. If your pure JS code already is designed to eliminate redundant calls, then you already get the minimal DOM calls from JavaScript too. That's the best case, and VDOM can only be slower as it adds diffing overhead on top.
There might be other good reasons to use a VDOM (including cases like using the DOM in a web worker). But I don't think performance is one of them.
Re: Virtual DOM is pure overhead (2018)
#19The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study.
I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that.
Maybe, the Virtual DOM is pure overhead if you look at the complete system, but:
1. It was reasonable at the time 2. Some other patch to the Web Ecosystem will fix this
The more systems are interconnected, the more difficult is to change anything radically and only incremental changes are possible.
Re: Virtual DOM is pure overhead (2018)
#20While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html