141–150 of 404 posts
GG
Earlier quoted context omitted.
Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…
Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…
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, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…
This 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?
And the output from the compiler is much smaller. You can compare the output on the Svelte 4 REPL to the output on the Svelte 4 REPL. The runtime has grown a bit, but the output overall is still much smaller even when factoring that in
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…
What about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation/update only the corresponding view elements? This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. Bu…
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.
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 promises in many many cases, but the nomenclature does not invoke easy understanding
Earlier quoted context omitted.
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.
As a recent adopter of Svelte, these changes are intriguing but I don't really have a grasp of how I feel about it quite yet. One thing that I am definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing: let input = 'Hello'; // ... let loudInput: string; $: loudInput = `${input)!`; Instead of: let input = 'Hello'; // ... $: loudInput: string = `${input)!…
Perhaps 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…
I've got a couple of thousand hours of Svelte dev experience, and these changes offer me nothing I really want.
Svelte dependencies outside my .svelte files? No thanks, I'll keep them usable in non-Svelte projects.
A new way to do reactivity to try to appeal to React users? ("When people come to our community in future..." in the vid.) No, thanks! Svelte 3/4 reactivity was very straightforward, one could learn the whole thing in a day from the excellent tutorials. It was better than React.
There was definitely a bit of weirdness with overuse of reactive vars but that's been incentive to keep components small and simple. A good thing!
Personally I'm still stuck on v3 because 4 introduced breaking changes I haven't had a chance to debug, so it'll be a while until any of this impacts me anyway.