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

81–90 of 404 posts

Re: Svelte 5: Runes

#81

Post by rich_harris »

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…

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 describing.

Signals and observables (e.g. RxJS) are related but separate concepts. The framework world is converging on signals as the appropriate mechanism for conveying reactivity — even Angular (which has historically been most closely tied to RxJS) is moving in this direction. I promise you it's not just a mass delusion.

Re: Svelte 5: Runes

#82

Post by LapsangGuzzler »

bhouston wrote: post #60
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…

> It's like every other framework is slowly rediscovering why React made the decisions it made. Definitely there is convergence in DX now. No need for everyone to admit one or another framework was right first or not - that is just creating antagonism or negating people lived experiences and innovation. But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte…

I think this somewhat inevitable given the flexibility of javascript. The lack of convergence on one single paradigm as a long-lasting set of best practices speaks to all of things that a web framework needs to have in order to accommodate all developers.

In Svelte's case, it feels like they went as far as they could without directly addressing observables until they reached a point where it became one of the largest features that had yet to be addressed.

Open source frameworks, not unlike companies, need to continue attracting new users to grow the ecosystem, which means pleasing an ever-growing user base.

Re: Svelte 5: Runes

#83

Post by twic »

tambourine_man wrote: post #27
chrisco255 wrote: post #8

"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.

One day my MooTools skills will be cutting edge again, i'm positive.

Re: Svelte 5: Runes

#85

Post by satvikpendem »

lolinder wrote: post #77
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…

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.

Re: Svelte 5: Runes

#86

Post by jasim »

What about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation/update only the corresponding view elements?

This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. But it is not possible in an array. You have it iterate through each element and do a shallow comparison to see if the references have changed.

That said, it is fairly easy to escape to DOM from inside a React component with useRef and the portal pattern. Then we can write vanilla JS which makes updates to only the values it changes.

If Svelte solves this in an elegant manner, then it would be a very compelling feature over React. I'm asking here because last I checked, most of the examples in Svelte's documentation pointed to simple counters and regular objects, and I couldn't find an example of a large linear list.

Re: Svelte 5: Runes

#87

Post by rich_harris »

jasim wrote: post #86

What about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation/update only the corresponding view elements? This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. Bu…

Yep! https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...

Re: Svelte 5: Runes

#88

Post by mbStavola »

As a recent adopter of Svelte, these changes are intriguing but I don't really have a grasp of how I feel about it quite yet.

One thing that I am definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing:

  let input = 'Hello';
  // ...
  let loudInput: string;
  $: loudInput = `${input)!`;
Instead of:

  let input = 'Hello';
  // ...
  $: loudInput: string = `${input)!`;
It's an incredibly minor thing, but when you do it 1000 times it becomes very frustrating. Having reactivity be rune-based should help TS avoid the syntactic confusion, bringing us to:

  let input = $state('hello');
  // ...
  let loudInput: string = `${input)!`;

Re: Svelte 5: Runes

#89

Post by skrebbel »

If you like this, I recommend you also look into SolidJS, which is basically this idea with less compiler magic and fewer dollar signs (and more JSX).

It also comes with a built-in model layer called Stores which is genius in its simplicity. In React land I’ve used Flux, Redux, MobX, mobx-state-tree, zustand and pullstate, and IMO Solid Stores beats them all (because Solid makes this possible, not because those libs are dumb)

https://www.solidjs.com/

Post reply on HN