Live data from Hacker News

Svelte 5: Runes

svelte.dev

271–280 of 404 posts

Re: Svelte 5: Runes

#271

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.

Seems like Svelte 5 is conceptually simpler and significantly less "clever" than its predecessors. No more playing fast and loose with the semantics of Javascript syntax. It was the hoops Svelte had to go through to provide reactivity that always that always seemed like over-engineering to me.

Re: Svelte 5: Runes

#272
post #176

Earlier 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.

That's completely true. A concede the point.

Re: Svelte 5: Runes

#273
post #96

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…

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.

I have a similar feeling. I keep up to date on changes to these other frameworks but in my work we've never run into React performance issues that couldn't be fixed by approaching things with good principals. Signals are brought up in convo every now and then as an approach to fix an issue, but stepping back we always seem to find a better solution but just re-writing bad React code. I'm sure if you're on a certain scale of users or extremely custom UI you could run into circumstances where signals would help you, but for our system that serves hundreds of thousands a day, we don't need them yet.

Re: Svelte 5: Runes

#275

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…

Was my first gut reaction as well. Especially when i saw `$state(0)`.

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

#276
post #112

Earlier 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…

I've seen people hang themselves with (or should I say on?) hooks.

Performance was the main issue because one incorrect usage of a hook can make a huge difference.

Re: Svelte 5: Runes

#277
It's amazing how far back all the research and experimentation goes on reactive Web/JS tech, e.g. Brown PLT's work on Flapjax starting back in 2006, even before the JS renaissance kicked off by googl's V8!

https://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

#278

I 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…

yes, good point, I shouldnt have evoked react itself, its everything else thats been built on top of it. But yes, Vue is exactly what I mean. Its so difficult to reason about how things work unless you live in it all day every day.
Post reply on HN