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

381–390 of 404 posts

Re: Svelte 5: Runes

#381

Post by vjerancrnjak »

rich_harris wrote: post #380
ramesh31 wrote: post #377

Earlier quoted context omitted.

>All of this looks like MobX Shhhh. Don't tell the Vue/Svelte community that they're just reinventing the React ecosystem on a 5 year delay. It will spoil all of their fun.

Michel and I have been internet acquaintances for years, and we've even talked about this stuff IRL. MobX certainly isn't something we just somehow never learned about! But anyway: it's absurd to compare this with React+MobX. MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, re…

MobX does not rerender entire components.

Unlike Redux at that time (~2016), it was a first approach where minimum rendering was happening effortlessly.

You can have a list of components where each component references a bit of global state and rerenders only if that bit changes, even though the list might have enlarged or other elements changed.

Last time I used it (2016-2020), they used all of the tricks of the trade, get, set object attributes, dropped decorators and it still worked the same.

Re: Svelte 5: Runes

#382

Post by jbergens »

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…

There was/is a state management lib called Mobx that was released years ago and was usually combined with React. It was kind of reactive, very easy to use and fast. It normally only updated the components that was effected by a state change.

It was a bit sad that it didn't get more popular and possibly improved. Some devs liked it but we were a minority compared to those who liked/used Redux.

One strange thing they did was to release a new "version" called Mobx State Tree which was very different. It had a great api but was different and slower.

Re: Svelte 5: Runes

#383

Post by rich_harris »

vjerancrnjak wrote: post #381
rich_harris wrote: post #380

Earlier quoted context omitted.

Michel and I have been internet acquaintances for years, and we've even talked about this stuff IRL. MobX certainly isn't something we just somehow never learned about! But anyway: it's absurd to compare this with React+MobX. MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, re…

MobX does not rerender entire components. Unlike Redux at that time (~2016), it was a first approach where minimum rendering was happening effortlessly. You can have a list of components where each component references a bit of global state and rerenders only if that bit changes, even though the list might have enlarged or other elements changed. Last time I used it (2016-2020), they used all of the tricks of the tra…

Notice that you just said "You can have a list of components _where each component_ references a bit of global state". In other words, in order to avoid re-rendering everything, you need to have a component for each item in the list.

In React, the component is the unit of re-rerendering. MobX can't change that fact. The only thing you can do is work around it with hacks that imperatively update the DOM.

Re: Svelte 5: Runes

#384

Post by wentin »

EvanYou wrote: post #376
rich_harris wrote: post #369

Earlier quoted context omitted.

Hi! First up — not that it matters, but since people will wonder — our design wasn't informed by the Reactivity Transform. We evaluated something close to 50 designs, some of them extremely wacky, before settling on runes, and it wasn't until after that time that the Reactivity Transform was brought to our attention. Nevertheless, it's interesting and validating that we landed on such similar approaches. While the Re…

> $state and $ref are quite different. I wouldn't say they are "different" - they are fundamentally the same thing: compiler-enabled reactive variables backed by runtime signals! But yes, Vue already exposes the underlying concept of refs, so for users it's two layers of abstractions. This is something that Svelte doesn't suffer from at this moment, but I suspect you will soon see users reinventing the same primitive…

In Svelte 4, the let counter = 0 syntax is already reactive by default, a feature enabled by the compiler. This has been the status quo for Svelte prior to the rune change. The introduction of the $state(0) rune actually provides more hints about its reactivity than before, and restore the original meaning of let counter = 0 (in rune mode). While it's true that the compiler's "invasion" into JS/TS syntax has been a point of discussion, this invasion has been happening for a while, and the initial shock wave has been well-absorbed by the community.

Interestingly, the new changes could be seen as a retreat from that initial invasion, likely triggering a different response from the community. In fact, the resistance I've seen (and my own as well) has been in the opposite direction—it's hating this retreat, complaining Svelte becoming less "magical." and more close to regular joe Javascript.

Re: Svelte 5: Runes

#385

Post by vjerancrnjak »

rich_harris wrote: post #383
vjerancrnjak wrote: post #381

Earlier quoted context omitted.

MobX does not rerender entire components. Unlike Redux at that time (~2016), it was a first approach where minimum rendering was happening effortlessly. You can have a list of components where each component references a bit of global state and rerenders only if that bit changes, even though the list might have enlarged or other elements changed. Last time I used it (2016-2020), they used all of the tricks of the tra…

Notice that you just said "You can have a list of components _where each component_ references a bit of global state". In other words, in order to avoid re-rendering everything, you need to have a component for each item in the list. In React, the component is the unit of re-rerendering. MobX can't change that fact. The only thing you can do is work around it with hacks that imperatively update the DOM.

Yes, this clarifies what you've meant and I can see the case that is not covered with MobX+React but I assume it is covered by Svelte's runes.

You're saying that I can have the whole app written in a single file without any separation and the updates will still happen only in the place that needs it.

That makes sense. With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains html elements that are referencing the state.

Re: Svelte 5: Runes

#386

Post by RussianCow »

hajile wrote: post #363
RussianCow wrote: post #257

Earlier quoted context omitted.

> The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. I don't know, IME it's pretty easy to run into bottlenecks with React. To resolve these, you have to spend time optimizing data flow and preventing unnecessary re-renders, and it can be really difficult to trace where an update originally comes from. Svelte and other reactive frameworks give you good p…

What is the actual difference between React and Svelte? People don't actually know, but this isn't like the old days where React offered 10x (or more) performance increase over AngularJS without even trying to optimize. We're arguing "better" using very slim margins. Looking at the geomean benchmark suite everyone uses, it's 1.33 for Svelte 4 and 1.67 for React. That's a mere 0.2x difference and most of that is due t…

The statistical performance difference is somewhat irrelevant. The measure should really be the extra time spent optimizing your code, and that value can be far higher in React than it is in Svelte. It doesn't matter if the raw performance difference is only 20%—if that 20% means the difference between a smooth UX and a janky experience, it's still extra work you have to do with React that you don't need with Svelte.

Now, I'll grant you that it really depends on the project. Building a simple admin interface? This probably won't matter. But for an interactive dashboard with dynamic charts and data being updated in realtime? You're almost certainly going to spend some time making it fast. And optimizing React code is currently a pretty poor experience.

For the record, I'm not arguing that the performance difference alone makes Svelte worth using over React. In fact, I think the developer experience with Svelte is far better, which is (in the majority of cases) a much better reason to use a framework. I just want to dispel this myth that React is so fast that you'll likely never have to think about performance, because I've had to do a non-trivial amount of optimization work on just about every React codebase I've worked on.

Re: Svelte 5: Runes

#387

Post by sprkv5 »

pcthrowaway wrote: post #219
pevey wrote: post #73

Earlier quoted context omitted.

This might be the impression on first glance because it uses the word "state." But keep reading, and its much more akin to what Solid is doing. In fact, the new docs openly credit the work Solid's team is doing. They also credit Knockout's approach form way back in 2010.

Under the hood it's doing something more similar to solid, but the API exposed is a step in the direction of React (it doesn't expose the signals to the user). It's not quite React either because there's no 'setter', just a different way to opt in to reactivity which also (IIUC) makes it possible in .js/.ts files

For a second, ignore Hooks, Signals and Runes, and look at the way Runes were presented in the video "Introducing Runes.. with Rich Harris". You will find this presentation very similar to but much shorter than "React Today and Tomorrow and 90% Cleaner React With Hooks" video. Both of them talk about:

1. primitives for managing state - $state vs useState

2. removal of lifecycle mechanisms - onMount vs componentDidMount

3. replacing lifecycle mechanisms with new primitives - $effect vs useEffect

It's like the Svelte team took a leaf out of React team's book on how to upgrade a framework - this is evident by the way these features are presented as opt-in like how React marketed Hooks as opt-in. I would go on to predict that the upgrade to Runes will just like the upgrade to Hooks. Developers will use it and then love it - because it presents improvements to the way codebases will be structured and maintained just like React did with Hooks. This is really a Hooks moment for Svelte. Good job Rich and the Svelte team!

Re: Svelte 5: Runes

#388

Post by ramesh31 »

rich_harris wrote: post #380
ramesh31 wrote: post #377

Earlier quoted context omitted.

>All of this looks like MobX Shhhh. Don't tell the Vue/Svelte community that they're just reinventing the React ecosystem on a 5 year delay. It will spoil all of their fun.

Michel and I have been internet acquaintances for years, and we've even talked about this stuff IRL. MobX certainly isn't something we just somehow never learned about! But anyway: it's absurd to compare this with React+MobX. MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, re…

> MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, regardless of whether that's a boon to readability and maintainability.

This is not true. MobX has had an `` component for years now. You can be as fine detailed as you wish with rerenders in a larger component.

https://github.com/mobxjs/mobx-react#observer

Re: Svelte 5: Runes

#390

Post by ramesh31 »

vjerancrnjak wrote: post #385
rich_harris wrote: post #383

Earlier quoted context omitted.

Notice that you just said "You can have a list of components _where each component_ references a bit of global state". In other words, in order to avoid re-rendering everything, you need to have a component for each item in the list. In React, the component is the unit of re-rerendering. MobX can't change that fact. The only thing you can do is work around it with hacks that imperatively update the DOM.

Yes, this clarifies what you've meant and I can see the case that is not covered with MobX+React but I assume it is covered by Svelte's runes. You're saying that I can have the whole app written in a single file without any separation and the updates will still happen only in the place that needs it. That makes sense. With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains…

>With MobX, this could be done but not with React and not without a bunch of boilerplate that obtains html elements that are referencing the state.

It's trivial with MobX. The Observer component essentially gives you an "inline" component wherever you need reactivity, without the need to actually componentize.

i.e using a MobX State Tree store:

  const store = types.model('Store', { value: types.string }).create({value:'But I will!'});

  const Page = () => {
    return (
      
        I won't rerender
        
          {()=> { 
            const { value } = store;
            return (
              {value}
            )
          }
        
      
    )
  }
Post reply on HN