Svelte was developed by Rich Harris, Graphics Editor at the New York Times. He is best known for developing:
Undeniably, his presence on social media and in meetups greatly contributes to Svelte's fame and make people talk about it (for good or ill), bringing the most interested ones to discover Svelte.
Svelte has been the talk of the town in recent months, and its popularity has risen sharply since April 2019, when version 3 was released. The project has now reached 34k stars on GitHub ! 🤩
But Svelte is nothing new. Though much reactions focus on version 3 these days, the project started in 2016. Why did we have to wait for version 3 to hear about it? Well, because Svelte version 3 focuses on two key points that most developers worry about:
- Simplicity of syntax
When version 1 of Svelte was released, Rich Harris published an article "Frameworks without the framework: why didn't we think of this sooner?" in which he points out a number of problems with current frameworks:
- Weight of applications
- Poor performances
- Lack of interoperability
In this 2016 article, he imagines that in 2018, front-end developers would have entirely given up frameworks that work at runtime.
Wait, this new framework has a runtime? Ugh. Thanks, I'll pass. - front-end developers in 2018
Rich Harris likes to compare Svelte to React or VueJS, he especially likes to provoke them a little and remind that they are not really reactive and that on this point, Svelte has a head start. This seems to be part of his communication strategy to promote Svelte and maybe that's also why we talk about it so much. But why does he feel that React and VueJS are not reactive?
Reactivity is what occurs when an event happening in our application (for example a button is clicked or a value is saved) triggers another action (update the display for example) : a piece of code reacts accordingly and updates the DOM.
In React and VueJS, reactivity works as follows: when a change is detected in the state of a component, the Virtual DOM is updated accordingly and compared to its previous version. If a difference is detected, then an update of the real DOM must be done.
The virtual DOM works well, the comparison algorithm is well optimized, its use is suitable for the majority of uses but when we have performance needs in terms of rendering, especially if we work around data visualization (DataViz) as Rich Harris does at the New York Times, then it is not enough. He also presents the limits of the virtual DOM in a blog article:
React, Vue, Angular, to name a few, work at the runtime. So for your application to work, a large amount of the framework code is embedded in the bundle sent to the user, even for a basic "Hello World". The code written by the user is somehow embedded in an application to work with the code of the framework.
Svelte's foremost promise is to allow developers to write less code. We, developers, spend most of our days reading and writing code. Every line of code we write contributes to the technical debt we accumulate on our projects and generates new bug possibilities. In fact, it is common to hear that the best possible code is the code that isn't written.
The more code a file contains, the greater the cognitive effort required to understand what is being done. To remedy this, we take time to do some refactoring to simplify understanding: we mutualize pieces of code, add comments, etc. Sometimes, all this leads to writing even more code, and then, we enter a kind of vicious circle that hurts productivity.
Finally, and everyone will agree on this fact, writing more code takes more time, leaving less time for other tasks, especially optimization. That's why one of Svelte's goals is to allow developers to write as little code as possible while still ensuring high readability.
Rich Harris wrote about it on Svelte's blog. He presents the syntax of Svelte v3 and has fun comparing it to React and VueJS:
Reactivity is at the heart of Svelte, it is certainly the main point of this version 3 and the feature that caused this sudden rise of popularity.
In Svelte, the idea is to put reactivity back into the language. Reactivity in Svelte is based on the assignment of variables, which means that defining a variable in Svelte already makes it reactive.
Let's not forget that Svelte is a compiler and thanks to this, it can, in the build phase, insert instructions in the code that will be used for reactivity. The added instructions simply say "each time an assignment occurs, calculate the dependencies or side effects, and update the DOM accordingly". Svelte being a compiler, it can calculate the side effects of each user action at the build phase, something its competitors working at runtime can't do. Thanks to this, Svelte directly targets the places in the DOM where to make changes. The responsibility for reactivity is finally borne by the compiler, not by the browser. It's very efficient and above all it's extremely powerful!
Almost a year after the release of its version 3, Svelte continues to make people talk. Rich Harris, especially through his communication, is obviously the main architect of this. He initiated a project that, at a time when developers are looking for new ways to optimize, allows to reduce the size of web applications and enjoy high performance rendering. Svelte keeps its promises of simplicity of writing and reactivity; this contributes to its continuous notoriety.
Compiler frameworks uncover new horizons for the future of the web. Are we heading towards a decline of front-end frameworks as we know them today to make way for compilers? When will this happen? How? Who will be the main actors? It's far too early to say, all this will take time, but one thing is sure, Svelte contributes strongly to this new momentum and makes the web move forward.