A lot of magic is okay for simple application, but when you want to build anything that scales Svelte before runes was just horrible. With Svelte 5 and Runes you can look at any component and instantly know what it does. You couldn't do that with Svelte 4 unless you wrote the whole code yourself.
Runes are the right choice for the library, but there is still a loss there.
I was highly skeptical of runes upon the original announcement and very cursory usage during beta phase.
When I finally got to porting a couple simple projects, I shrugged “this isn’t too bad, but what’s all the fuss?”. I ported a mid size project and it really clicked.
Then I went to build a brand new small project, and I found myself in love with runes. Having spent the time to get under the hood (especially using them as classes), being able to leverage them during the design phase really sped me up and facilitated cleaner/better state management.
What do you mean by that?
let count = $state(0);
I should point out that indeed (as you're correctly pointing out) updating bound variables looks the same, just that declaring them sucks. I don't really trust they won't do similar things to updating bound variables though.
let someState = someOtherState.thing;
$: someState = someOtherState.thing;
Svelte 5 does still have a compiler, and there's still a lot of "magic" involved — it just asks you to be more explicit about your intentions in some cases. Of course in an ideal world it could just figure it out, but some distinctions (do I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?) need to be specified explicitly, and I prefer clear syntax for that explicit specification over the terrible, verbose hacks that you used to have to use in order to prod the compiler "magic" in the right direction.
I was a runes hater, then I bit the bullet and migrated a big app to Svelte 5. Now I get it. You should give them a chance as well.
Yep. We're agreed there.
> I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?
Reasonable to default to first, ask the developer to be explicit about the second if needed.
Honestly I still love SFC and Svelte having opinions about CSS and state storage is great. But it feels like this was the wrong direction. The 'magic' is why we used Svelte.
Edit: I think my tone here is a little off due to illness. Sorry if I sound grumbly. Wasn't my intention.
I wonder what Ryan Carniato, the author of Solid, thinks of it.
Together, they offer a seamless entry into development, allowing you to swiftly grasp concepts akin to JS/HTML.
Other options require a significant learning effort.
Wish it came earlier...
It is compatible with both Svelte 4/5 and more importantly pure TS libraries.
I vastly prefer Svelte, because of how clean the code feels. There's only one component per file, and the syntax looks and writes deceptively like vanilla JS and HTML. There's a bit of mind-warp when you realize Svelte doesn't want you passing components with props as props into another component. Svelte gives you "Snippets" instead, which work for some reusability, but are limited. It sort of forces simplicity on you by design, which I like. Most of React's deep nesting and state management doesn't exist in Svelte and is replaced with simple, better primitives.
The bigger gain though for me was Svelte(kit) vs. Next JS. It's very clear what is on the server and what is on the client, and there's none of that "use client" garbage with silly magic exports for Next JS things. The docs are great.
Svelte's biggest disadvantage is that the UI library ecosystem isn't as large. For me that wasn't as big of an issue because it was my expertise, but everyone else looking for a drop in UI library will find the Svelte versions a little worse than their React counterparts.
Because svelte is compiled, it also is by default very snappy. I think choosing Svelte would likely give most devs a speed boost vs. the spinner soup that I've seen most React projects become. A lot of that is going to be in the skill of the programmer, but I love how fast my app is.
[0]: https://bsky.app/profile/davesnider.com/post/3lkvum6xtjs2e
Is it though? Your `+page.svelte` is rendered on the server as well. Not only `.server.` is run on the server.
If you don't do this in React, its your own fault.
Currently porting to Svelte 5 and it is less elegant in my opinion, but perhaps the problems it tries to solve are for more sophisticated developers and I don't really come across them or have knowledge of them. I would prefer to stay on 4, but I will take Rich's word for it that it will be better long term.
Admittedly complicated components with lots of reactivity can be confusing to follow data changes with lots of $: lines so I have tried to minimise that from the beginning. The Svelte 5 code looks cleaner to follow for onboarding devs that aren't familiar with our codebase yet.
Pretty happy! Just wished they didn’t change their “magic” so often, but it’s the price to pay for innovation—if we can even call frontend development that, which I think we should but many frontend haters around here
Plus they need to invest some serious work onto SvelteKit...
Svelte is great. But if you're in a time crunch and you don't have a specific technical requirement that makes React a bad match, I don't think Svelte is worth it. A big part of the Svelte ecosystem is still using Svelte stores, and I found the "one component per file" paradigm to be a bit limiting.
Just a nitpick, with runes in Svelte 5, stores have largely become obsolete. $state, $derived, and $effect replace most of the needs people would normally use stores for.
I'll add devex extends to TSX/JSX itself too, the editor support and language server experience is miles ahead. Alternative formatters/linters like Deno, Biome, oxc etc. all have great support out of the box too, not so much for svelte.
For when react is a bad match; I'm investigating solid instead for this reason.
The svelte ecosystem is in a particularly unfortunate spot right now comprising of single/few author projects that were starting to stabilise but now have a svelte 4 -> 5 migration shaking things up.