Contents
In brief
A Dev.to note remembers the promise of early Svelte: write let count = 0, change the variable, and the UI updates on its own, with no hooks and no dependency arrays. Version 5 replaced that promise with the runes $state, $derived, and $effect. The author treats them as close relatives of useState, useMemo, and useEffect, and argues not that explicit reactivity is useless, but that the framework stopped standing apart from the ones it used to tease.
What happened
Svelte 5 was announced on 20 September 2023 and stabilized in late 2024. Runes are explicit calls: state, a derived value, and an effect. The compiler used to track assignments to ordinary variables. Now the developer marks what is supposed to be reactive. For someone who came to Svelte specifically to avoid that mark, the shift feels like a changed contract, not a cosmetic syntax tweak.
The framework team explained the move by saying the implicit scheme does not scale: in a large app it is hard to see what an update depends on. The author does not deny that pain. He also cites the gain that, for him, settles the argument in favor of the new version: a bundle about 55% smaller. Code is also easier to split across files once reactivity is named instead of hidden in an assignment. That is no longer “runes are bad”. It is “what did we give up the old simplicity for”.
The rest of the tone is personal. He describes the feeling that a one-of-a-kind framework is being washed out and that Svelte now looks like the rest. The conclusion he calls uncomfortable: explicit, function-shaped reactivity looks like a shared destination, not one team’s surrender. The compiler still does work that plain hooks do not, but the runes removed the shield of “you do not have to think about reactivity”. He writes that he will most likely stay on version 5: the smaller bundle outweighs the nostalgia.
Why it matters
For a team choosing a framework in 2026, the old comparison “Svelte without hooks versus React with hooks” is already false. Compare explicit model to explicit model: where the compiler still removes work, how much smaller the bundle is, and whether people can live with $state instead of “just a variable”. A four-year-old promise in a job post or a tutorial should be corrected, or a newcomer will arrive for magic and meet runes.
There is a second layer, about the identity of a tool. Convergence on one idea is not the same as uselessness. If several frameworks independently arrive at explicit dependencies, the implicit scheme lived poorly in large codebases — marketing did not simply win. The loss is real: fewer surprises, at the cost of declaring reactivity again. That is an honest trade if you name it as one.
In practice
The note is one developer’s opinion, not a bundle measurement of your app. Treat 55% as something to check with a build before and after the move, not as a passport for Svelte 5. Migrating old assignments to runes breaks the habit “change the variable and you are done”, so start with modules where the dependencies were already confusing.
Staying on version 4 “so it feels like before” has a cost too: new material and fixes look at runes. The author chooses version 5 for himself and asks people not to pretend nothing changed.
- In onboarding, show
$state,$derived, and$effectnext to the familiar hooks, and do not sell the outdated magic. - Before a migration, build your own app and compare size, not only how the syntax feels.
- Move first the modules where implicit updates are already hard to read.
- Do not expect the compiler to hide reactivity again. You still declare it, even if the compiler takes part of the work.
Takeaway
Svelte 5 kept the compiler and dropped the promise that the UI updates from an ordinary assignment. The author counts that as a loss of character and, at the same time, a reasonable price for scale and a smaller bundle. For choosing a framework, nostalgia matters less than whether the current explicit model matches what you still tell the team about Svelte.
Comments