4 ms·
I think it's a misunderstanding that Svelte is fast because it is "compiled" into imperative DOM updates. This is partly because the documentation says so, and
by jeswin 6y ago
I think it's a misunderstanding that Svelte is fast because it is "compiled" into imperative DOM updates. This is partly because the documentation says so, and the early blog posts emphasized this aspect.
Compilation actually has nothing to do with it. Svelte is fast because it doesn't do all the Virtual DOM stuff, and the DOM diffing. You could very well build Svelte as a library without the compiler, and it would be just as fast.
But the compiler helps a bit with the ergonomics - it's cleaner to do count+=1, rather than setState({count:count+1}).
- TehShrike 6y agoThe compiler turns 20 lines of runtime code into 2 lines of runtime code. The performance effects are real!
- leeman2016 6y agoDue to compilation, bundle size gets a lot smaller which will boost start-up/load time.
- hajile 6y agoI believe infernoJS complete with vdom still matches and even exceeds on most metrics. Last I checked, svelte compiled different code paths for every single component. This means that most DOM manipulations in real-world applications (not micro benchmarks using the same components repeatedly) won’t ever optimize in Svelte. Meanwhile, the vdom code runs constantly and is hand-tuned to help ensure deopts don’t happen. Likewise, potential optimizations to reuse old nodes and other “garbage” are much easier to implement with a unified DOM implementation. Finally, once you implement the vdom once, you don’t do it again. With Svelte, your code is recreated for every component. This may give smaller component in the short term, but there’s an inflection point (and it’s in the small-medium range) where svelte starts shipping more code for the same work.