Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte 5: Runes

svelte.dev

Post reply on HN
Print view View original

191–200 of 404 posts

Re: Svelte 5: Runes

#191

Post by ttfkam »

kabes wrote: post #115
lolinder wrote: post #77

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…

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.

Let's be honest: the state (see what I did there?) of React state management is a dumpster fire.

https://fe-tool.com/awesome-react-state-management

That's an article listing the top 18 state management libraries for React.

18?!?

React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about?

Folks don't adopt utility libraries for things that were already easy to reason about on their own. I'm glad you've found peace with React's basic notion of state, but it's a far cry from optimal. And the "state ecosystem" of React is a dumpster fire. Layers upon layers of madness that acolytes peer through and proclaim insight.

> These rerenders can only happen down from where in the tree the state change happens.

Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

Re: Svelte 5: Runes

#192

Post by gnaritas99 »

satvikpendem wrote: post #52

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…

[dead]

Re: Svelte 5: Runes

#193

Post by [deleted] »

wentin wrote: post #178

One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can w…

[deleted]

Re: Svelte 5: Runes

#194

Post by rich_harris »

wentin wrote: post #178

One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can w…

We evaluated somewhere close to 50 different design ideas (seriously) before settling on this one, and what you describe was one of those ideas.

But one of our goals was for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3. For that to work, reactivity has to be opt-in, not opt-out.

And that's how it _should_ be — someone reading the code should be clued into the fact that this `let` won't behave like a normal `let` in JavaScript, and it should be possible to move code between modules (and between modules and components) without worrying about whether a specific file was opted in to certain behaviour.

In other words this...

> This way, the change wouldn't break existing code

...isn't quite right — it would break _all_ your existing code that wasn't in .svelte files.

> If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want.

On this point specifically: unfortunately not. The code in a .ts file, for example, has to be valid and typecheckable. You can't insert a preprocessing step ahead of the TypeScript compiler. Again though we concluded that this is a good thing, since it means this all works with all existing ecosystem tooling.

Re: Svelte 5: Runes

#195

Post by danaw »

jussayin wrote: post #64

I'm evaluating Svelte for a project. The previous Svelte syntax governing reactivity is easier to reason about. For what it's worth, I don't understand the new proposal after several readings. I suggest that the Svelte team pause and consider feedback for a year before jumping into a what appears to be a wrong design direction.

Had the opposite experience. It seems intuitive and a step forward making the API clearer. It also eliminates a bunch of potential footguns at the same time.

Re: Svelte 5: Runes

#196

Post by jraph »

schnebbau wrote: post #9

This is what happens when bored developers just have to improve something that doesn't need improving.

I was a bit apprehensive reading the comments here, but reading the presented changes, I'm actually quite happy.

I built two Svelte apps. I liked using Svelte but was a bit annoyed by the aspects these changes are fixing.

The code also seems easier to write and to understand.

My feeling that the Svelte team has taste is strengthened.

Re: Svelte 5: Runes

#197

Post by rich_harris »

gsuuon wrote: post #156

Interesting that signals are coming back hard - Elm had and removed signals due to the learning curve and complexity. With solidjs I pretty immediately ran into the gotchas of signals. I like that reactivity is explicit rather than implicit in svelte 5 - implicit reactivity makes debugging stale views pretty unintuitive.

Yes. Signals are a wonderful mechanism, but they do come with headaches. Our goal was very much to adopt the elegant reactivity model without all the downsides, and we've approached this by making them an under-the-hood implementation detail that you don't interact with directly.

Re: Svelte 5: Runes

#199

Post by ttfkam »

satvikpendem wrote: post #137
jauntywundrkind wrote: post #111

Earlier quoted context omitted.

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.99…

> 99.99999% of times it goes great. I'll disagree with you on that. I've seen and used enough 2-way binding in various projects to know that even the best of devs can create tangles of effects everywhere. At some point, you gotta blame the tool for having footguns, which is why Rust was created over C and C++, to solve such footguns. In the same vein, something like that should be made for frontend frameworks too.

But have you used 2-way binding with a more modern framework? Or are you still hanging on to your experience with a defunct framework like Knockout from over a decade ago?

And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun. Oh! Sorry! Forgot that React's footguns are aKeats elegant and reasonable while everything else's footguns are dealbreakers.

Re: Svelte 5: Runes

#200

Post by hajile »

ttfkam wrote: post #191
kabes wrote: post #115

Earlier quoted context omitted.

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.

Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were alread…

React isn't a state manager and why should everyone be forced to use the one "blessed" manager?

Despite there being so many, only a handful (redux toolkit, jotai, zustand recoil, and mobx) see much real-world use and they are basically just 3 approaches (reducers, signals, and directed graphs) with varying levels of complexity and features.

> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

Not true. It only needs to diff the leaves of the part that changed and some of those sub-trees can be skipped too if they are functionally pure (or uses shouldComponentUpdate). This is how they reduce complexity down from O(n^3) to something generally closer to O(n)

Post reply on HN