Svelte is just another component framework but created based on different assumptions. Its advantage over traditional framework is built upon three pillars:
- Write less code
- No virtual DOM
- Truly reactive
Let’s go trough Svelte manifesto and find out what stays behind those promising declarations.
Quit virtual DOM
With the virtual DOM diffing technique, changes to the real DOM can’t be applied without first comparing the new virtual DOM with the previous snapshot. Node by node, which is considered fast enough but not for Rich Harris. That is why Svelte doesn’t work at run time by changing virtual DOM but works as a compiler that in a build time generates a code, which is, in fact, proper if statement, that describes how things could change in the app. Declarative state-driven paradigm was replaced by efficient imperative code.
Significantly less boilerplate
While describing all the advantages of new Svelte version, Rich Harris caused loud laughter in the audience, saying that "this framework will let you write a markup that isn’t accessible but it won’t respect you for it". Accessibility, however, is rather serious than fanny and Rich Harris knows, as well as we all do, how important it is in modern website development. That is why he introduced to his product the mechanism that will warn developers from writing code without paying attention to proper semantics. The code with warnings compiles, but at the end who would leave those annoying warnings in finale product. I believe that most developers won’t and thanks to that the Internet may become a little more friendly place and this small detail in Svelte I respect a lot.
Styles in Svelte component is encapsulated, which is of course very convenient. Moreover Svelte has also a built-in mechanism to recognize unused CSS selectors and warns developers, guiding them to remove unnecessary code. It also delivers built-in directives for transitions, and since CSS animations are run outside the main thread, as everything in Svelte, it has a good impact on performance.
Svelte team has also thought about bundle size. If you don’t use a particular feature, e.g. transition, that was mentioned before, it won’t be included in the final compiled code delivered to the user, because it will only contain a minimum subset of features that are used and nothing else. It allows the Svelte team to develop features that they think may be useful (and they can expand the framework with no compromises) but it allows also us, as developers, not to use them and do not care about their size.
Take it or leave it?
The new stable Svelte version is already the third one, and although the progress and change that was made between new and previous one was really significant, Svelte community has a lot of ideas on how to improve their product. I’ve read opinions that one-file-approach isn’t convenient for having good IDE or code editor experience and the fact that it can’t be used with TypeScript is really unsatisfactory. It’s true but Svelte team is aware that they don't yet have the bounty of editor extensions, syntax highlighters, component kits, devtools and so on that other frameworks have. They know they should fix that alongside with adding first-class TypeScript support. There are also some side projects related to Svelte like Sapper, which is about server-side rendering or Svelte Native that allows to write Android and iOS apps in Svelte.
All of this makes some of us in Merixstudio really interested in Svelte future, we are going to follow its further development. I’m starting to write my first Svelte app and I encourage you to also give it a try.