Virtual DOM is pure overhead (2018)
svelte.dev
Virtual DOM is pure overhead (2018)
1–10 of 293 posts
Re: Virtual DOM is pure overhead (2018)
#2The blog ends with
> But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
Re: Virtual DOM is pure overhead (2018)
#3I thought most of the JS world know that virtual DOM is slow and ahead-of-time direct binding is the way forward at this point - why do something expensive inside your users browser when it should be done on the developer's machine? Svelte will either take over, or React will get patched to start doing this in a major new release. It could go either way at this point.
Re: Virtual DOM is pure overhead (2018)
#4Re: Virtual DOM is pure overhead (2018)
#5You 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 works well in the real world, and methods like `shouldComponentUpdate()` can be used in the 1% of cases where the default is not fast enough.
Re: Virtual DOM is pure overhead (2018)
#6This article is from 2018. Plenty of water under the JS bridge since then.
Re: Virtual DOM is pure overhead (2018)
#7I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality.
I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimulus JS is good enough. Personally I do not see why everyone wants to build a Single Page App when 80% of your pages are static and can be server rendered and with SSR frameworks you can build something a lot faster than building a Frontend and Backend separately and fragmenting or hiring extra developers when it is not needed.
DHH said your code reflect your org structure and I agree companies that use SPA and Backends micro service arch usually tend to require more developers rather than companies that use SSR monoliths which appeal to smaller 1-3 developer companies that are building out a POC before committing huge amount of venture capital or their own money behind an idea that may not succeed.
Re: Virtual DOM is pure overhead (2018)
#8Okay, 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?
Re: Virtual DOM is pure overhead (2018)
#9The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
Yes, I too was hooked but disappointed there was no link to a follow-up article!
Re: Virtual DOM is pure overhead (2018)
#10The blog ends with > But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in. Ok. I’m convinced in principle but is there a follow-on blog that describes specifically what Svelte does differently?
Svelte is:
- smaller (because Svelte doesn't include Svelte in the binaries it outputs, but rather a dynamically generated static mapping between data and elements)
- better organised (single function components, with the JS, HTML and CSS in a single file) - like Vue!
- simpler (name = 'Joe' instead of const [getName, setName] = useState(null); setName('joe')). The last one isn't quite true as you can't use this in all circumstances - fruits.push('pear') won't update fruits, you have to run 'fruits = fruits' afterward to trigger the update (there are other ways too).