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

161–170 of 404 posts

Re: Svelte 5: Runes

#161

Post by trueadm »

cornfutes wrote: post #117
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…

> 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

I work on Svelte 5 and I was also a React engineer on the core team previously FWIW.

Re: Svelte 5: Runes

#162

Post by dleeftink »

satvikpendem wrote: post #79
bhouston wrote: post #60

Earlier quoted context omitted.

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

> * But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.* Convergent evolution [0]. Just as a shark, dolphin, and ichthyosaur all have the same body shape which is efficient for swimming and hunting in the water, so too do technologies converge when the problems are all the same and the solutions are understood, only…

But for every similar shaped organism, there exist as many, if not more dissimilar ones, either alive or preceding. Convergence is not a given, and for every instance of convergence there are just as many divergences, even when appearing similar on the surface. For each degree of software 'carcinization' [1], I'd contend there are as many evolutionary offshoots going against the grain.

[1]: https://en.m.wikipedia.org/wiki/Carcinisation

Re: Svelte 5: Runes

#163

Post by eyelidlessness »

rich_harris wrote: post #45
chrismorgan wrote: post #34

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…

> it looks like it’d be needing to do quite a lot of control flow analysis Implementation-wise, this is vastly simpler than Svelte 4, because everything is explicit. One thing we didn't really show today is how this works in your editor in practice — for example, TypeScript thinks `$state` and `$derived` are just the identity function. It makes sense when you use it, but I appreciate that I'm basically asking you to…

> for example, TypeScript thinks `$state` and `$derived` are just the identity function

That seems like a missed opportunity on Svelte’s part… but hard to fault, because TypeScript doesn’t support nominal primitive types very well. Ideally it would be something like Reactive to signal (ha) that it’s not just a plain value.

Re: Svelte 5: Runes

#164

Post by hajile »

satvikpendem wrote: post #152
hajile wrote: post #140

Earlier quoted context omitted.

It's not convergence, it's the cycle of development patterns. Patterns come and go leaving bad memories that become anecdotes. Anecdotes become "misunderstanding the paradigm" and even the misunderstandings are long forgotten when the pattern that made them comes into vogue again.

I wonder if it's due to how new people are to the industry, as well as how new the industry itself is. In disciplines like mechanical or chemical engineering, you don't see nearly this much reinvention of the same patterns. I imagine most people these days using React, Vue, Svelte, or Solid have never even used jQuery or Knockout, as those are almost 15 years or older at this point.

If you're an engineer, physics are always there to smack you in the face. As a result, engineers collect sets of things that physics seem to be fine with and reuse them. If engineering were programming, a woodpecker in Central Park would bring down the Eiffel Tower.

Programming is not physical. It is generally bound by Turing completeness, the halting problem, 2 generals problem, and the like, but most developers don't even write code on that level. That leaves them with an infinite number of ways to solve problems with the real limiting factor often being the humans instead of the fundamental limits. If you use 5 different design patterns in 5 different frameworks, they all still work, so now you must decide (based on ever-changing factors) which one is actually the best.

Complicating this is the issue that not all people were taught the same or think the same way either, so an approach that makes sense to some people might not make sense to other people. The extremes here based on education and what you learned first are massive even when there are objectively better answers too. An entire generation of devs either retired or died rather than move from assembly to Fortran or C. That generation retired or died rather than move to OOP and the OOP people are retiring/dying rather than moving on to more functional approaches to programming.

Re: Svelte 5: Runes

#165

Post by mwcampbell »

hajile wrote: post #112
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…

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 d…

Counterpoint: https://ericwbailey.website/published/modern-health-framewor...

Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?

Re: Svelte 5: Runes

#167

Post by notfed »

As someone who just started Svelte two days ago, my naïve take is that this feels like adding verbosity.

1. Is there no way for the compiler to automatically, recursively find reactive dependencies?

2. Assuming no, is there not a more terse way to decorate reactive expressions?

Re: Svelte 5: Runes

#168

Post by satvikpendem »

dleeftink wrote: post #162
satvikpendem wrote: post #79

Earlier quoted context omitted.

> * But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.* Convergent evolution [0]. Just as a shark, dolphin, and ichthyosaur all have the same body shape which is efficient for swimming and hunting in the water, so too do technologies converge when the problems are all the same and the solutions are understood, only…

But for every similar shaped organism, there exist as many, if not more dissimilar ones, either alive or preceding. Convergence is not a given, and for every instance of convergence there are just as many divergences, even when appearing similar on the surface. For each degree of software 'carcinization' [1], I'd contend there are as many evolutionary offshoots going against the grain. [1]: https://en.m.wikipedia.org…

That's true, but perhaps just like in biological evolution, the ones that are against the grain don't survive, for whatever reason. So it could even be that convergence occurs via selection.

Re: Svelte 5: Runes

#169

Post by wikoj1021 »

What about scoped reactivity? Sometimes you need to react on some of the states not all of them. Right now we are achieving this by passing function with arguments to react on to $: but with $derived and $effect it seems to be not possible because it takes variables from every function passed. Are there any plans how to resolve this? Also nested $effect instead of onMount looks awfull and to be honest is less readable.

Re: Svelte 5: Runes

#170

Post by cassepipe »

throwaway46281 wrote: post #128
no_wizard wrote: post #121

Earlier quoted context omitted.

I always found observables need better nomenclature. I know its not anyones fault (RxJS is amazing), but it does seem to invoke some gray area in the brain, thinking observables would do more heavy lifting around change tracking of inputs / sources, when its not that straightforward. They more rightly should be called SubscriptionStreams maybe I think its always been somewhat poorly named, based on how often I've had…

Huh? It's called observable because it can be observed (that's what "-able" means). If it were actually meant to observe something (as you say), it would have been named "observer." But it's not - it's the callback that's the observer. Also observables are more like streams than arrays.

Indeed !

`observers` do exist in RxJs by the way: https://rxjs.dev/guide/observer

Post reply on HN