Is this the turning point where svelte start to over engineer stuff and becomes just like other frameworks/libraries? The whole selling point of svelte is simplicity and straightforward implementation, you over complicate it, I will just use something else, popular at least.
Svelte 5: Runes
271–280 of 404 posts
Re: Svelte 5: Runes
#272Earlier quoted context omitted.
> An analogous concept might be quite interesting to implement in all these signal based frameworks as well. Which is what Svelte 5 is doing with its compiler. > […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously…
I think the true lesson here is that if you fundamentally dislike a programming paradigm, then everything written in it looks like a big ball of mud.
Re: Svelte 5: Runes
#273This 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…
Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.
Re: Svelte 5: Runes
#274Comparisons (Svelte 4 vs. Svelte 5 and other Frameworks): https://component-party-runes.vercel.app/
Re: Svelte 5: Runes
#275Perhaps 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…
But watch the introduction video. It isn't at all like the functional reactivity that entered other frameworks. It's still the svelte way. Read and assign is plain javascript. Only the initialization syntax changed.
They even promise backwards compatibility, so you don't have to migrate or migrate file by file if you want to. Which is also not how other frameworks handled this in the past.
Re: Svelte 5: Runes
#276Earlier quoted context omitted.
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…
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…
Performance was the main issue because one incorrect usage of a hook can make a huge difference.
Re: Svelte 5: Runes
#277https://github.com/brownplt/flapjax
https://cs.brown.edu/~sk/Publications/Papers/Published/mgbcg...
http://static.cs.brown.edu/research/pubs/theses/ugrad/2007/l...
It might be interesting to do a compare/contrast with v5's Runes and Flapjax's implementations.
Re: Svelte 5: Runes
#278I dont use Svelte or react, im sure its lovely and solves real problems. And maybe im just getting old, but over the last 20 years all evidence I have is that "magic" is a trap. Its so strange to me to see such a high profile project leaning into it like this. Youre writing javascript, but the way you must reason about what your code is doing is so different than javascript.
React gets a bad rap because of all the rubbish built around it, but if you do ever want to try the declarative model over vanilla/jQuery, React is actually exactly what you want if you want to avoid compile time magic. The only thing happening at compile time with React is a line-for-line swap from JSX tags: {boop} to a createElement function call: React.createElement("foo", { bar: "baz" }, ...boop); Other than that…