Since the release of version 3 in April 2019, Svelte has been in the news all the time. But why? What fuels this popularity? What is new about it? Can Svelte be seen as the successor to the trendy front-end JavaScript frameworks? So many questions that I will try to answer through this article.
What is Svelte ?
Svelte is a component-oriented JavaScript library like React and VueJS for example. Like most popular front-end JS libraries, Svelte offers a lightweight framework, with powerful features and syntactic sugar to make the developer's job easier. The main difference with Svelte is the library internal engine, because Svelte is primarily a compiler.
Rich Harris
An outstanding personality
Svelte was developed by Rich Harris, Graphics Editor at the New York Times. He is best known for developing:
With Svelte, Rich Harris is not at his first attempt at creating a JavaScript library.
On top of his developer skills, Rich is also very active in the JavaScript community. Very active on Twitter, he participates in discussions about the JavaScript ecosystem, often with a very strong opinion and good repartee. He's also an excellent and inspiring speaker who travels to meetings and conferences to talk about Svelte. I highly recommend his talks, especially this one about reactive programming:
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.
History
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
- Reactivity
What Rich Harris criticizes about frameworks
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
From where he stands web applications embed too much code. This is a reality and it has a big impact on their performances. The time lapse before a possible interaction with the web application you want to access, the famous "time to interactive", is not only related to the network time needed to download the application's content but also to the time spent by the JavaScript engine to parse and interpret the code. Motivated by this observation, Rich Harris decided to create Svelte and make it a compiler and not a runtime framework.
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.
The reactivity of React and VueJS is based on a virtual DOM system. It is actually a JavaScript object that contributes to the internal functioning of these two libraries. It is a virtual representation of the real DOM and is used to make comparisons without having to manipulate the DOM API. Thus, frameworks can detect if there are changes to be made to the real DOM and generate a new rendering for the user.
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:
Svelte's stances
A compiler to embed only the essentials
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 has a different approach, and that's what compilers are all about. What Svelte offers is the ability for developers to write code using a particular syntax, and Svelte will only be the tool that can understand that code and generate standard browser-optimized JavaScript. Since it is a compiler, no unessential code will be embedded in the application. The final bundle will only contain what the developer has written following the Svelte syntax, translated by the compiler. Svelte only translates instructions into browser-optimized code during the build phase.
Write less to produce more
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:
Increased reactivity
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!
Conclusion
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.
Top comments (38)
Coming from stuff like jQuery, a lot of devs who used React were like "wow", and coming from React, Svelte feels amazing too!
People just need to try it, it's so incredibly simple too!
Yes, that's the point, it's so easy to use !
For many years, I didn't touch anything JS but when I came back to it, I was impressed by its evolution. I really like nodeJS for example but when I tried Svelte, it blew my mind.
However, it's still too incomplete for me to adopt it in a project but I'll definitely revisit it later!
Interesting, what are you missing to make it complete enough ? 🤔
It may have changed now but when I tested it, I remember I had to type everything. By that, I mean there was no easy element management, especially for the UI.
For example, I am using VueJS for my project and with it, ElementJS so I don't have to design myself UI components (and because I'm not a good designer). I know I'm being lazy but if it's easier and faster, you're more flexible too.
As I said, it was at the time I tested it and I remember joining a discord channel about Svelte where someone mentioned he was working on something similar to a UI element repository so maybe now it's available.
completely overhyped.. and i find the docs to be very poorly written, unlike vue&nuxt ecosystem, when i read docs, everything is crystal clear... then again i'm super tired atm.
and switching paradigms too often confuses my brain, i'll rechecl svelte when its further in the development than rc1
You can get a hard time testing the components compared to other frameworks
Testing was not too hard because those were quick and one-time things. However, implementing it on production would require something more flexible and easy to maintain (UI elements comes to mind. I forget other aspects).
Hi, what do you miss?
Mainly UI elements management, I guess.
Well, I say "mainly" because I forgot the other points now 😅
Maybe you should also look at the excellent RiotJS - it predates Svelte by years, and Svelte seems to be awfully similar
Indeed, Riot.js also comes with a compilation phase. But it seems too verbose for me, more complicated to read and write than Svelte. Just a personal feeling ;)
I agree with you @anthony_legoas
Whenever I see new frameworks coming out in JS, I think about following statement a lot.
In web development, we are not doing anything new, we are doing same thing in different way.
Totally agree ! We just find new ways to optimize over time.
Another competitor is SolidJS which claims to be even fastest and smallest but with the usability of React. Quite an interesting claim.
I'm curious if anyone try it into production projects.
"Yes, the size might be smaller, but still. You can't write some magic code, compile it and expect that it will work in the browser out of the box."
Why cant you compile code, you have written, into code that will work in the browser.
Frameworks like React has many features to solve many different problems. When you load a framework, you'll likely get code to solve problems that you don't even have in the current page of the application. Route-based tree shaking and code splitting can help remove this unused code, but even still, there's part of the core of the framework that can't be split up. I believe Next.js is constantly working to fix this problem by seeing if they can ship less of React with each route. Svelte is different. It doesn't try to remove unused code that already exists, it just never outputs that code in the first place.
In other words, you haven't actually looked at Svelte, understood how it works, or built anything in it, but already you know that it's hype. I guess you saved yourself some trouble there.
Anthony, nice post. As @mattwaler said, this is the only framework brought "wow" to me. And, one more thing is that... Svelte has a great, very well organized tutorial. Last Sunday, I started learning it and it's amazing. It's one more plus point.
Since I started writing React, I felt like it's not the thing, even with hooks. This gives me some hope. I'll be learning the rest this weekend.
Thanks again!
Yeah you're right, the tutorial is really great !
Glad you enjoyed the post 😉
Even though it's been a while since Svelte has been released there hasn't been an attempt to onboard an official CLI utility. In fact there is a discussion going on regarding the same.
degit is the preferred Dev utility with which one can clone any of the starter kits to their local machine. I strongly feel there is a space for a dedicated CLI tooling as we have for other frameworks out there, and this thought led me to create svelter-cli. It is still in it's very early phase, would love to have contributions from the community.
Thanks for sharing, I'll take a look 😉
Really great summary Anthony! Appreciate you rounding up all the important Svelte points into one place 😊
I'm glad you enjoyed it 😉
So.. I have missed the point in the article where you discussed the benefit of the Virtual DOM vs Svelte pure JS compilation.
The Virtual DOM has been praised for long time and it's one of the main factor of the success of React and Vue, how does Svelte compare in that sense?
Just my two cents, I think it takes time to build virtual DOM and compare them while Svelte can avoid that? But for me personally it's the less code, less bundle size, built in animation etc that provides a good dev experience that attracts me to favor Svelte.