Live data from Hacker News

Svelte 5: Runes

svelte.dev

111–120 of 404 posts

Re: Svelte 5: Runes

#111

Earlier quoted context omitted.

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect. > why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you…

Now if only we had an analogous borrow checker in Vue and Svelte so that we don't hang ourselves with 2-way binding. That might a good research project, actually.

React & redux both come standard with tools to dynamically observe behavior. A flurry of updates is easy to pin down & fix.

Static analysis seems like a nice to have. All in all I class this category of concern as very far down the list of concerns, one way or two way. Yes bad things are possible. But the martial attitude that oh no people will do it wrong this tech is horrible is, in my view, actively harmful.

99.99999% of times it goes great. We don't need to make coding environments were bad things are impossible.

Re: Svelte 5: Runes

#112

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…

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect. > why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you…

React is the pragmatic answer.

Most devs are of average talent and will hang themselves and everyone else with the stateful webs they weave. Even with careful PR reviews, these things have a way of sneaking in and becoming permanent hinderances.

Performance hasn't been a dealbreaker in most JS apps for years now. What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is disposable based on the whims of the company. The bits that aren't disposable are used enough to justify having them designed and maintained by your best devs who should also have the skill to write performant code.

Re: Svelte 5: Runes

#113

I've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in…

Did you read the bit about how runes make all those things unnecessary in future?

Re: Svelte 5: Runes

#115

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…

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect. > why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you…

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

Re: Svelte 5: Runes

#116
Perhaps I'm just the grumpy old guy that's afraid of change.

But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together.

I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of?

But I can't help seeing this as ominous:

> This is just the beginning though. We have a long list of ideas for subsequent releases that will make Svelte simpler and more capable.

Please don't turn Svelte into a black magic box.

Re: Svelte 5: Runes

#117

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…

> I am assuming it's because the users who are making these frameworks now have not used or do not remember the times where "signals" were called observables

And also a tendency to not have experiencing working on large web apps (I’m talking 100k+ cloc) where issues arise, and why those React engineers made the decisions that they did

Re: Svelte 5: Runes

#118

"Like every other framework, we've come to the realisation that Knockout was right all along." Nope, nope. Been there, done that, with 2-way data binding and never going back.

I’m still waiting for every other framework to realize that jQuery was right all along. But if these guys are only now reaching Knockout, I still have to wait for them to catch up to Backbone.js, I guess.

<3 backbone

Re: Svelte 5: Runes

#119
post #96

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…

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

second this, plus its mature ecosystem, which is very valuable for the long term.

though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

Re: Svelte 5: Runes

#120

I’m not particularly comfortable with some of the nature of the change. Runes are magic compiler symbols, but they look even more like just normal code than was the case before. Previously, Svelte’s reactivity model was very easy to understand, including its limitations, because it was the result of very simple analysis—you can cover the rules in a few minutes without difficulty. It included some things that were obv…

Functions can return primitives, so there’s nothing wrong with $state() returning a number that you can +=1.

What is weird is that it’s actually typed as a svelte-compiler-only ‘extended int’ that can have side effects when you increment it, and weird knock on results from reading it.

Post reply on HN