Live data from Hacker News

Svelte 5: Runes

svelte.dev

231–240 of 404 posts

Re: Svelte 5: Runes

#231
I'm cautiously optimistic for this. My first instinct is that it doesn't seem to provide much value add over just sticking with stores, which I think were already thoughtfully designed, but I won't knock it till I've tried it.

Re: Svelte 5: Runes

#232
post #122

Earlier quoted context omitted.

Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…

Pretext: I'm a backend developer that often needs to stare into the abyss that is frontend.

I used to say these same things about reactivity. It was highly confusing to me years ago; as a backend developer doing frontend tasks was always reaching outside of my cookie jar and testing the boundaries of what I knew vs what I thought I knew. Many headaches ensued. That said, using Vue 3 and Svelte 4 has made utilizing stores and reactivity a lot more obvious in my opinion. Things render when they're supposed to and my applications remain performant. As a non-frontend person, I mainly like the APIs that Vue and Svelte bring. In React I'm almost always switching to class based components for what I can do in the compositional API in Vue or what's natively possible in Svelte. That brings a lot of repeated code and doesn't look as clear to people not as familiar with React.

Re: Svelte 5: Runes

#233
post #176

Earlier quoted context omitted.

Thanks for the reply, Rich. It seems that, given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. Granted, I haven't used runes and based on your blog post here, I'm not reading where it would prevent such headaches as there's not much mention of that there, so I don't know exactly how it'd work, but just based on my experience using things like Vue and…

> An analogous concept might be quite interesting to implement in all these signal based frameworks as well. Which is what Svelte 5 is doing with its compiler. > […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously…

Based on your profile and comments, it seems you have some particular grudge against React, so I'm not sure I can convince you of anything React related that you have not already convinced yourself of. Nevertheless, I (nor you, it seems) have not used Svelte 5 yet so I cannot judge, just that based on my, yes, personal experience, 2 way data binding based frameworks create messes. Even though you can shoot yourself in the foot in any language or framework, some are simply better at preventing it, such as C versus Rust, as I analogized.

Re: Svelte 5: Runes

#234

This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the firs…

> no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place

Honestly never understood this - 2 way is less code and way more understandable to me. Redux style codebases are very difficult for me to understand, and never saw benefits praised for. More frequently was "why isn't this updating?".

Different strokes I suppose.

Re: Svelte 5: Runes

#235
post #232
post #122

Earlier quoted context omitted.

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…

Pretext: I'm a backend developer that often needs to stare into the abyss that is frontend. I used to say these same things about reactivity. It was highly confusing to me years ago; as a backend developer doing frontend tasks was always reaching outside of my cookie jar and testing the boundaries of what I knew vs what I thought I knew. Many headaches ensued. That said, using Vue 3 and Svelte 4 has made utilizing st…

Seems like your comment cut off there, but if you're using class components in React, there will be repeated code, yes, which is why hooks were invented and why they enable you to reuse such code.

Re: Svelte 5: Runes

#236
theyre really not mucking about - just a cursory play in the live preview and it promises to solve basically 99% of the weirdness I encounter in my projects. it makes sense that automatic reactivity for any let was always overkill, and the use of $: in complex scenarios got stringy. $state / $derived / $effect seems elegant and I'm sure will make everyday grokking + maintenance easier ("ergonomics"). bigup

Re: Svelte 5: Runes

#237

Earlier quoted context omitted.

> create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're describing. Care to elaborate or do you have a link to a blog post explaining further?

I'll try — I'm currently fielding a zillion messages so excuse brevity! Basically, you can only modify state _where it's declared_. If you want to allow the 'outside world' to modify that state, you need to expose a function that does so. This is unlike cases where you're passing around an observable object where anyone with a reference, which they need for reading, can also write to it by doing `thing.value += 1`. T…

> fielding a zillion messages

Surely you mean signals? :)

Re: Svelte 5: Runes

#238

Earlier quoted context omitted.

That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.

I love all the changes except that single thing with let count = $state(0); I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default? $reactive(() => { let name = 'world'; }); vs let name = $state('world');

They mentioned that the team tried around 50 different variations. Meaning they spent a lot more time than a comment on this. I would trust they know what they are doing considering track record of Svelte team.

Tbh this seems kinda rude. Maybe check github i am sure the whole journey can be seen there.

Re: Svelte 5: Runes

#239
I snooped around Rich's GitHub history and found he's working on esrap[1], a package to convert an AST into code. It uses Bun for development and testing!

Crazy theory: esrap will be part of a transpiler that converts Svelte 4 code to Svelte 5 code. I'm not sure if that's actually the case or if it's even technically possible. But it would be really cool!

[1] https://github.com/Rich-Harris/esrap

Re: Svelte 5: Runes

#240

Earlier quoted context omitted.

I love all the changes except that single thing with let count = $state(0); I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default? $reactive(() => { let name = 'world'; }); vs let name = $state('world');

They mentioned that the team tried around 50 different variations. Meaning they spent a lot more time than a comment on this. I would trust they know what they are doing considering track record of Svelte team. Tbh this seems kinda rude. Maybe check github i am sure the whole journey can be seen there.

I don't mean to be rude, I'm just brainstorming. I'm sure they have thought about it I'm just commenting in the small chance that they haven't
Post reply on HN