These updates lean heavily towards how Vue approaches setting reactivity.
Is there any slam-dunk case for using Svelte over Vue?
Svelte 5: Runes
131–140 of 404 posts
Re: Svelte 5: Runes
#132Earlier quoted context omitted.
Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.
second this, plus its mature ecosystem, which is very valuable for the long term. though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.
I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration.
I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.
Re: Svelte 5: Runes
#133It's great to see people moving in this direction, but I'm disappointed that everybody has decided to reimplement basically the same thing independently.
Mobx was ahead of the game here (though, granted, it too draws on Knockout.js). You can use Mobx to declaratively describe reactive state, much like this. But it isn't integrated into any framework - you can use it in vanilla JavaScript with no other runtime or compilation required. You define models with Mobx, then on top of that there's mobx-react, which ties your model into React's update APIs (essentially making render() automatically observe values, and making relevant changes trigger a re-render), or there's mobx-vue, or mobx-svelte, or mobx-preact, etc etc. Decoupling this is super helpful - for example I'm using mobx to model raw state, computed state & reactions to changes in server side Node.js, no problem.
Meanwhile, recreating the same reactive concepts independently in each library instead makes all the resulting code incompatible, so even your pure JS state models are coupled to your UI framework - e.g. createCounter in this post has to import & use $state from Svelte. That makes it far harder to change frameworks in future, hard to share code between apps using different frameworks (plausibly even different versions of the same framework), etc etc.
I'd love to see a native common standard for this, similar to how promises were eventually standarized and suddenly everything had a compatible model for handling async future results (I could swear I've seen initial discussion on exactly that already, but I can't find it anywhere now sadly).
Re: Svelte 5: Runes
#134This 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…
Two way data binding and signals are such bad ideas when dealing with large real-world apps. I feel they only make sense in small code snippets that are cool to tweet.
For me they're a dealbreaker when considering a new framework.
Re: Svelte 5: Runes
#135Earlier 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.
I mostly agree with you. Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.
What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cache that determines whether to refetch from the server or to keep the state local.
Re: Svelte 5: Runes
#136This makes a lot of sense and will simplify some confusions around reactivity. I'm guessing runes will make it easier for the compiler to track the reactivity which will enable stuff like automatic partial hydration? Maybe even something like qwik? I only read the blog post and didn't watch the video... was there any mention on perf and size improvements?
Smaller and faster :)
Can't wait to see some numbers!
Re: Svelte 5: Runes
#137Earlier quoted context omitted.
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.
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.
Re: Svelte 5: Runes
#138Earlier 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…
it may have been true in the Knockout days, however signals in Solid is very very similar in feel and reasoning to React hooks.
It makes it straightforward to reason about, because you aren't dealing with globals, undeclared deps etc. like in the Knockout days
Re: Svelte 5: Runes
#139Perhaps I'm just the grumpy old guy that's afraid of change. But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together. I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of? But I can't help seeing this as ominous: > This is just the beginning though. We have a…
This set of changes makes things more explicit. That's the opposite of a black magic box as far as I can see
Re: Svelte 5: Runes
#140This 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…
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.