Svelte 5 is a Completely Different Framework
Svelte 5 was finally released a few days back and this one is a bit controversial. The framework went through a major rewrite in order to provide a dev experience similar to the rest of the industry, but not everyone is happy with this change. Here is what you have to know about Svelte 5 and its potential future impact on modern web development.
Before looking at the really disruptive updates, let’s quickly review what Svelte is promising. Its main selling point is a seamless way to build user interfaces for the web. It uses a compiler to convert declarative component code, based on HTML, CSS and JavaScript, into tightly optimized JavaScript. And now, with the release of version 5 your apps should become faster, more predictable , and they should require less JS boilerplate transferred over the wire.
In practice, your UI is built using Svelte components which are compiled into JavaScript code. This code will then be able to update the DOM, keep track of reactive state, register event listeners and perform reactive changes whenever the component data is updated.
What made Svelte feel different in the past was the “magic” factor. Essentially you were able to build apps by simply writing what appeared to be plain JavaScript.
<script>
let count = 0;
function increment() {
count += 1;
}
</script>
<h1>{count}</h1>
<button on:click={increment}>+1</button>
Then, the Svelte compiler was doing all the heavy lifting by sprinkling in the reactivity needed to keep the state and UI in sync. The result shipped to the browser was highly optimized code which was doing all the work for you. However, this apparent magic loved by the community is what keeps Svelte back.
Reactivity
The main thing you need to know is that reactivity is the bread and butter of UI frameworks. This is the process of detecting changes in the component data and performing various side effects based on those changes. During the years frameworks came up with different ways to detect data changes ranging from inefficient solutions like dirty checking to the most recent fine-grained reactivity based on signals. Svelte compiler based reactivity is somewhere in the middle, sacrificing some of the performance aspects for a seamless dev experience.
On top of that, component composition is rather awkward because it treats event handlers and ‘slotted content’ as separate concepts. More importantly however, the dollar sign construct used to reactively re-run statements was merging two separate concepts which should be kept separate.
So you get the idea. Devs got this really amazing programming experience at the cost of fine tuned performance and underlying complexity.
Runes
This is where the controversial decision comes in. Svelte 5 removes these inconsistencies and introduces an explicit mechanism to declare reactivity called runes.
let count = $state(0);
let doubled = $derived(count * 2);
$effect(() => {
console.log(`=> count is ${count}`);
});
Runes are specialized functions that let developers control and fine-tune reactivity more precisely, creating a more predictable and performant experience.
As a result, your Svelte 4 reactive assignments and side effects become a bit more verbose in Svelte 5. I get it, and the framework authors also get it. This seems like a step back. However, note that as applications grow in complexity, figuring out which values are reactive and which aren’t can get tricky, and this process will begin to hinder your app’s performance.
So this is the price we have to pay for performance. At this point I believe it is fair to say that all established UI libraries offer a very similar dev experience, and, I would argue, very similar performance results when building your average web app.
This can only benefit us web devs because there are fewer concepts we need to master, and I’m looking forward to the day all these options will converge into one single library anybody can use, so we can retire and start raising chickens.
If you feel like you learned something, you should watch some of my youtube videos or subscribe to the newsletter.
Until next time, thank you for reading!