Web tech. So much noise about trivial things.
Svelte 5: Runes
61–70 of 404 posts
Re: Svelte 5: Runes
#62I'm not a website programmer like most people here (I work mostly in C and ARM assembly) so can someone knowledgeable on this topic please explain what is the purpose and background of this?
Also, I don't really understand why it's at the top of HN either, is this a groundbreaking change to whatever Svelte is?
Re: Svelte 5: Runes
#63This 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 it already had that value so nothing happens. It’s pretty much the unidirectional loop that React people love to talk about.
Re: Svelte 5: Runes
#64I'm evaluating Svelte for a project. The previous Svelte syntax governing reactivity is easier to reason about. For what it's worth, I don't understand the new proposal after several readings. I suggest that the Svelte team pause and consider feedback for a year before jumping into a what appears to be a wrong design direction.
Re: Svelte 5: Runes
#65Having moved from React to Svelte, it was always a breath of fresh air to write less and have it just work. Feels strange seeing state/props/effect again, almost like I'm back to React.
Re: Svelte 5: Runes
#66"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.
Re: Svelte 5: Runes
#67Hmmm. Perhaps "intrinsic" would have been ok for this? "a function which a compiler implements directly". In any case, it really seems like mainstream frontend programming has gone too far, and has started parodying itself... Runes... sigh :-p
Facebook itself (and FB messenger) are pretty buggy apps that are built on React, so not even the "masters" know how to do React properly, judging by the results... To be honest, I don't know that the whole thing that KnockoutJS started is really necessary. These days I prefer to work with the DOM directly when possible. http://domenlightenment.com/ is a good resource for people wanting to explore how to implement HTML5 applications, going back to the basics.
Re: Svelte 5: Runes
#68Why not just call it signal and computed? (instead of state and derived)
Re: Svelte 5: Runes
#69So it's a kind of type system using a kind of Hungarian notation? :Flashbacks to Win32 intensify: I think a real type system (i.e. compiler checked, rather than relying on falibilities of human programmers) would be a better solution. If Svelte already has a compiler why not implement this as part of it?
Can you clarify what you mean? I'm not sure how you watched/read that and got "type system" out of it.
Adding annotations (runes) to expressions to describe their properties is basically putting type annotations on expressions. Maybe I missed something, but that what it seemed like to me.
Re: Svelte 5: Runes
#70Earlier 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.
Yeah, sure. It's pure joy of mantainability and dependencies.
Just watch out for that dust, if you sneeze next to a 5 year old Node.js/React project, the whole thing falls apart.