Svelte has never looked more like Vue to me. I don't mean this as a dig, I think it looks great.
It's just even less obvious to me why I might pick it over Vue at this point.
Svelte 5: Runes
181–190 of 404 posts
Re: Svelte 5: Runes
#182I've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in…
I'd argue that there are way more libraries, since vanilla JS libraries integrate beautifully, unlike in React. Unless you are only talking about component libraries, of course.
Re: Svelte 5: Runes
#183It'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 comp…
I loved MobX. Used it for years with React and Inferno.
But not only it's an added layer of abstraction, it's also a complex piece of machinery which is not needed when the framework solves reactivity.
When I started using Svelte back in 2019 I was very happy to let go of MobX.
Re: Svelte 5: Runes
#184This 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…
I'm replying to you, but I'm asking the room: what, if anything, stops vue3 from compiling down to pure JavaScript like svelte does and reaping the speed benefits?
Re: Svelte 5: Runes
#185It'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 comp…
This is the way.
Mobx tc39 decorator support is pretty much done too. I check in on the PR weekly haha.
Re: Svelte 5: Runes
#186Earlier quoted context omitted.
> 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.
We've toyed with this idea. There's a couple of problems though. Firstly, if you have this...
type Reactive = T; function $state(value: T): Reactive
...then TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this...
type Reactive = T & { [uniquesymbol]: any };
...in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive` to `number`.
But it also creates problems here:
let message = $state('hello'); obj = { message };
The type of `obj.message` is Reactive, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.
It's possible that we can do some fun stuff with TypeScript plugins, but we haven't dived too deeply into it yet.
Re: Svelte 5: Runes
#187Perhaps 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…
Agree. Svelte is a blast to write as an old grumpy backend engineer. But yes, probably just scared for nothing. Turning onMount() into $effect() is a tiny change, but this self-aware smol brained grug likes onMount() as it means something! To enable logical grouping, Svelte 5 allows us to nest the $effect()s? What does that even mean? Where am I? Nurse!
Re: Svelte 5: Runes
#188Earlier quoted context omitted.
I don't think I'm entirely out of band to say there could be a better way of naming them, like why not call them SubscribableStream . Saying its an observable invokes a messy gray area in people's brains. I know this because I've had to explain observables to co-workers more times than I can count in my career (I'm a big fan of RxJS, I didn't mean what I said as a dismissal), and I like them for async work vs promise…
Maybe it would be easier for you (and your colleagues) if the function to "observe" observables was called... observe, instead of "subscribe ?
not particularly, I think it would make it more confusing.
When I break it down to folks explaining its stream processing over iterables or async work and you subscribe (and can unsubscribe) a pipeline that runs over that stream, people get it quickly.
When I say you can "observe a stream" people start getting other connotations, for some reason. I have ran into this over and over and over. Smart people too, not talking about just juniors here
Re: Svelte 5: Runes
#189This is what happens when bored developers just have to improve something that doesn't need improving.
Always gotta be someone like you in the crowd eh?
Perhaps, just perhaps it's a good change for a lot of people?
Re: Svelte 5: Runes
#190Earlier quoted context omitted.
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?
The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. The fact that React can prioritize rendering of some things over others means that it can be slower overall, but still feel faster to users.