Hacker News new | ask | show | jobs
by joseneca 454 days ago
Agh, I understand why runes were implemented, but I still can't get myself to like them. It feels like Runes take away from what made Svelte Svelte (the simple, concise syntax), and changes like this seem like slow concessions back in that direction anyway.
5 comments

I felt the same way at first, but even in my small project, I've come to greatly appreciate them—or at least what they seem to enable. I've found deeply nested bindings to work without a hitch, which wasn't always the case in Svelte 4.
You just have to build a big project with Svelte 5 and you will come to like them.

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.

I think that's actually the core of the problem. It's the right choice for big projects. But Svelte was an absolute joy to use when brewing up a small or medium size project that you want to just work first time.

Runes are the right choice for the library, but there is still a loss there.

Not sure I agree. I’ve built numerous small projects in Svelte 3 & 4, sharing that same joy many of us had! Stores were generally amazing.

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.

I agree. I ported a non trivial project last year from 4 to 5 and runes are a game changer.
They really are an improvement. Tracking data flow in a complicated component (bound props going in both directions, derived state, …) was terrible before runes — you just had to rely on compiler magic, which worked until it didn’t. Now it’s more or less obvious.
I wish they had found a way to make the compiler just work. No longer having the ability to update the DOM by updating bound variables eliminates one main reason I wanted to use Svelte in the first place. I still love SFC though.
> No longer having the ability to update the DOM by updating bound variables

What do you mean by that?

In Svelte, traditionally, changing the value of a variable updates DOM elements using that variable.
Right, and what makes you think you can't do that in Svelte 5?
The release announcement? https://svelte.dev/blog/svelte-5-is-alive

   let count = $state(0);
You can't just set a variable anymore, you need to use runes. Which is silly - I shouldn't need to tell Svelte this is reactive, any variable referred to inside the HTML in the component is logically reactive and Svelte should know this. Like it used to. This is why we had a compiler.

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.

I get why runes, but you're right. That simple Svelte I loved feels a bit further away now. Not sure how I feel about it long-term.
Agree. Loved Svelte, but after the update I made the switch to React and can’t imagine going back outside of small, static viz apps.