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

71–80 of 404 posts

Re: Svelte 5: Runes

#71

Post by satvikpendem »

skrebbel wrote: post #63
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 recently took Solid for a spin and I found none of that 2-way data binding mess you complain about. To be fair, I think you’re assuming is has behavior that it doesn’t. Eg if a form input changes, that change triggers an onChange and in a handler function, you can let the change just flow through the data layer (ie through a signal or a store, which is just a hierarchy of signals). This then updates the input, but…

Sorry, I should have been more clear, I was talking more about Vue and Svelte rather than Solid, which explicitly says they don't have 2-way binding due to learning about how dangerous it is and how React doesn't have it: https://www.solidjs.com/guides/faq#why-can-i-not-just-assign...

Re: Svelte 5: Runes

#72

Post by mmmeff »

skrebbel wrote: post #63
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 recently took Solid for a spin and I found none of that 2-way data binding mess you complain about. To be fair, I think you’re assuming is has behavior that it doesn’t. Eg if a form input changes, that change triggers an onChange and in a handler function, you can let the change just flow through the data layer (ie through a signal or a store, which is just a hierarchy of signals). This then updates the input, but…

What you’re talking about is unidirectional data binding, and what you’re replying to specifically mentions its failure to scale with complex applications.

It’s not the kind of problem you can appreciate when taking any framework for a spin with a form input.

Re: Svelte 5: Runes

#73

Post by pevey »

epmatsw wrote: post #6

This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?

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.

Re: Svelte 5: Runes

#74

Post by pbowyer »

rich_harris wrote: post #20
schnebbau wrote: post #9

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

Svelte 3 came out in early 2019, and the framework hasn't really changed much in that time — one thing we can't be accused of is making changes for changes' sake. But since then, the front end community has discovered valuable new ideas and techniques. Meanwhile, people have encountered the limits of the Svelte 3 approach. Svelte is really good at solving most of the problems you throw at it, but it's not perfect. Th…

That's a great - and funny - video. Nicely done!

Re: Svelte 5: Runes

#75

Post by handsaway »

I've dabbled with Svelte and find it pleasant to use and I think this is a step in the right direction. The main reason I ultimately keep coming back to React is I find the compile-time alterations to the semantics of my code difficult to reason about.

I've spent a lot of time building an intuition for how Javascript code executes and how I can combine its primitives to make reasonable abstractions. The fact that this _looks_ like Javascript but suddenly operates differently is almost more confusing to me than if Svelte was just a non-Javascript language.

React's `useState`, `useMemo`, etc. are perhaps more verbose but they're just functions. Dependency arrays are messy but it's fairly easy to extrapolate their behavior from a basic description.

Re: Svelte 5: Runes

#76

Post by devmor »

interactivecode wrote: post #55
devmor wrote: post #36

Earlier quoted context omitted.

> I’m still waiting for every other framework to realize that jQuery was right all along. I find myself feeling this way a lot while writing front-end code. While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so sim…

Thats similar to me as a frontend dev seeing all the backend complexity and thinking it would be easier just to read and write a json file instead of a db + apis. It works but on longer projects where requirements can explode in complexity it becomes a problem. It really helps to have tools that can stay maintainable.

That comparison works against your point quite well because there are an absolutely incredible amount of backend services built with scalability and sharded postgres dbs with redis caching or what-have-you that would have been perfectly served by a perl script and an sqlite file.

Re: Svelte 5: Runes

#77

Post by lolinder »

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 a very explicit picture of how and when components will update. React, on the other hand, expects you to trust its smart algorithms, which definitely removes a lot of the pain from day-to-day coding but also makes troubleshooting performance problems harder.

I see the distinction as similar to GC languages vs something like Rust: if all you need is to have an app that does a job and you don't care about how it does it, React is a good choice. If you need to have control over exactly what will update and when, Vue's model gives you fine-grained control over updates that's hard to achieve in React.

EDIT: And with that in mind, it's obvious why Svelte, which prides itself on being lean and fast, would avoid the React smart-but-complicated runtime model in favor of the Vue model.

Re: Svelte 5: Runes

#78

Post by paavohtl »

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.

jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.

Re: Svelte 5: Runes

#79

Post by satvikpendem »

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…

> * 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 as humans we can learn from each other rather than randomly mutating our codebases [1]. It's the same reason why we see a lot of languages starting to adopt more functional features such as not using `null` and having exhaustive pattern matching, such as Rust (from OCaml), Dart 3, recent versions of Java, etc.

[0] https://en.wikipedia.org/wiki/Convergent_evolution

[1] https://en.wikipedia.org/wiki/Genetic_programming

Re: Svelte 5: Runes

#80

Post by chrisco255 »

mgaunard wrote: post #66
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.

My experience with JavaScript is limited, but knockout is what I use because it's what makes sense.

Knockout is fine to use if your JS doesn't exceed 1000 lines or so. After that, in more complex apps, 2 way data binding becomes an absolute mess of side effects.
Post reply on HN