Same thing but without magic - Angular Signals.
I do not like magic in code.
Svelte 5: Runes
51–60 of 404 posts
Re: Svelte 5: Runes
#52This 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 first place, to have only one way data binding and to re-render the entire page in a smart way. React will soon get its own compiler as well which will made regenerating the DOM even more efficient.
It's like every other framework is slowly rediscovering why React made the decisions it made. 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, or the usage of Rx libraries, and how having too many of these would cause you to lose your mind debugging the intricate webs you inadvertently spun.
Re: Svelte 5: Runes
#53I recently wrote a game in Svelte 4, and went through a transition from using the /$ reactivity to stores. This looks MUCH nicer to deal with.
Their examples seem to be missing some imports? Trying to use $state as shown with svelte@5.0.6 gives "ReferenceError: state is not defined".
Re: Svelte 5: Runes
#54All these compilers and language forks, man...
Re: Svelte 5: Runes
#55Earlier quoted context omitted.
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.
> 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.
Re: Svelte 5: Runes
#56This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?
It looks so close to react hooks, that is the first thing that struck me. Of course the syntax is slightly different but functional it is mostly the same. It seems weird that we are definitely converging between the various frameworks. For a while with svelte I though we were diverging but that seems to be changing now.
Re: Svelte 5: Runes
#57> Isn't it better if let count is reactive by default?
> Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky.
People keep re-learning that there's a certain amount of context that needs to be explicit, and you can't just imply everything. Just like when ruby and python made the mistake of getting rid of let/contst/var/etc and programmers said wait no that's a bad idea, now it just makes everyone's job harder, because neither the compiler nor the developer can figure out what context something belongs to.
Re: Svelte 5: Runes
#58I’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…
Fair enough. I’ll see how things go and wish you well. For simple cases, the new will be syntactically-inferior, but it makes sense that the explicitness allows it to be more consistent. Ah, modelling mutable trees as stores… not a great deal of fun.
Re: Svelte 5: Runes
#59Earlier quoted context omitted.
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.
> 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…
We sometimes have to step back from our high tech bubble. Check out jQuery's usage on the web. The unbeatable juggernaut that React seems from up here clocks at under 5% market share. It's sobering.
https://w3techs.com/technologies/overview/javascript_library
Re: Svelte 5: Runes
#60This 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 it seems to be reserving direction.