Perl called these sigils. They were incredibly useful and powerful, but the dev community decided that they hated them.
Svelte 5: Runes
11–20 of 404 posts
Re: Svelte 5: Runes
#12"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.
I thought that quote of yours was a sarcastic overview you yourself had written but no, it's an actual quote from the article!
> Like every other framework, we've come to the realisation that Knockout was right all along.
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
That's a sad development and further makes the framework more complect (as defined by Rich Hickey), with more hidden layers and "magic".
Re: Svelte 5: Runes
#13This 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?
Re: Svelte 5: Runes
#14"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.
> with 2-way data binding and never going back.
We used to know that, too. We also used to know that entirely event-driven architectures were a level of chaos you shouldn’t invite into your enterprise. Don’t need to look hard to see those either.
Whole industry has been cycles of collective amnesia going back to at least 1975.
[Edit] but in this case what we seem to be doing is having another go at Aspect Oriented Programming, which I was interested in for some time but concluded it, like event-only systems, are a poor fit for the average developer’s mental model, and also a terrible way to encode business requirements. Particularly from a testing perspective. They are usually dabbling at functional core, imperative wrapper architectures, but tend to retain global shared state which is a reliability nightmare waiting to happen.
Re: Svelte 5: Runes
#15This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?
I kind of feel the same. React and all the new stuff now feels like unnecessary complexity but they definitely got the initial DX right
Re: Svelte 5: Runes
#16I never expected that in 2023 someone will still be inventing new abstractions in JavaScript.
I see it a bit like chess now, there will always be people making progress on a particular opening and variant.
Re: Svelte 5: Runes
#17This is what happens when bored developers just have to improve something that doesn't need improving.
I think Rich clearly demonstrated the pitfalls in today's Svelte and the introduction of runes seemed like a great solution to them. I'm not a Svelte user but this new feature does seem clearer to me when looking at the refactored code than the magic reactivity behind the `$` syntax. Overall a net win in my opinion.
Re: Svelte 5: Runes
#18This 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 :)
Re: Svelte 5: Runes
#19React Hooks has its problems, but it got so many things right from the start - code written in 2018, when hooks first came out, still works today. No need to rewrite everything when a new major release comes out.
That said, svelte5 does solve a lot of problems that stop me from trying it.
Re: Svelte 5: Runes
#20This is what happens when bored developers just have to improve something that doesn't need improving.
Svelte 3 came out in early 2019, and the framework hasn't really changed much in that time — one thing we can't be accused of is making changes for changes' sake.
But since then, the front end community has discovered valuable new ideas and techniques. Meanwhile, people have encountered the limits of the Svelte 3 approach. Svelte is really good at solving most of the problems you throw at it, but it's not perfect. The changes we announced today are _necessary_.
If you're not convinced, I encourage you to watch this video, where I talk about why that is: https://www.youtube.com/watch?v=RVnxF3j3N8U