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.
Reactivity
Reactivity is a core concept of modern JavaScript frameworks, which give us the tools to build applications, that immediately react to changes, update components’ state and re-render the view. It is achieved by some kind of state declaration and API that allows us to change this state. Although in previous framework’s versions there was this.set() method (so similar to React’s this.setState()), in Svelte 3 (according to the idea of making everything easier and more vanilla JS style) there is no API at all. There are only pure language concepts used - the state is just a variable declared in the component and to update a local component state you just need to use assignment operator. How simple is that! Moreover, Svelte uses labeled statements, JS feature that isn’t really commonly used, to make reactive declarations. By using $: statement you can easily declare variables that are derived from other variables and will be automatically recomputed when referenced value changes.
Quit virtual DOM
Svelte bring us a radically new approach, compared to traditional one, known from other JavaScript frameworks like React or Vue, that stays behind performance improvement, i.e. a departure from techniques like virtual DOM diffing. Instead of using virtual DOM, Svelte writes code that surgically updates the DOM when the state of your app changes.
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
Angular is considered as the most mature of the JavaScript frameworks and I’m a big fan of it, but I remember my first steps with it and I can totally agree that the Angular’s learning curve is steep and some concepts of development with it may be really difficult for beginners. React seems to be a little easier, and you don’t need to have even four different files for one component, but still, there is JSX to familiarize with to write components in React. And now we have Svelte, that allows us to build boilerplate-free component using just languages that are every front-end developer’s holy trinity - HTML, CSS, and JS.
You may like it or not but, similar like in Vue, in Svelte there is only one file (.svelte type but looking just like HTML) with good all known <script> and <style> tags, that contains whole component’s template, logic, and style. In combination with all those things that I described earlier and ready to use bind value and event handler directives, it is hard to argue with the statement that a React component is typically around 40% larger than its Svelte equivalent. I believe that, for someone who has just started to work with JavaScript frameworks, this particular one can really deliver an outstanding developer experience.
Performance
A svelte team from the very beginning says loudly that the whole concept has started because of the performance. Their goal was to deliver optimized and reduced in size compiled code, rather a large JS that is killing app's startup performance, not only with network time but also the time spent on parsing and evaluating the script, during which time the browser becomes unresponsive. And they delivered - "a framework without a framework" - one which doesn’t actually run in the browser but a compiled vanilla JS code and they point out that their solutions beat other JavaScript frameworks to the draw in benchmark tests.
Accessibility
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
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.
Bundle size
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.