Live data from Hacker News

Svelte 5: Runes

svelte.dev

101–110 of 404 posts

Re: Svelte 5: Runes

#101

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…

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

> reserving direction

autocorrect style typo, i think

Re: Svelte 5: Runes

#102

I'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?

jQuery changed the game for frontend web development. Instead of static pages on the browser, interactivity for the client-side proliferated because DX on top of jQuery was way better. Then they started cursing jQuery for its limitations.

Then came React -- which again changed the game for frontend web development. Instead of wonky scripts and targetting CSS classes, you get a modular and reactive approach in building the web. Then they started cursing React because of performance issues and implementation complexities.

Svelte was designed to behave like React but perform better and reduce the implementation complexities. I had the chance to work with Svelte 1 back then and as a React developer, it would really make you think "Why did React do that?".

This is probably on top of HN because people loved Svelte too -- but some followers are now questioning the direction as this change is gravitating towards solutions that React already implemented. As it happens, React did solve a lot of problems for the frontend, and they really nailed it.

Re: Svelte 5: Runes

#103

If you like this, I recommend you also look into SolidJS, which is basically this idea with less compiler magic and fewer dollar signs (and more JSX). It also comes with a built-in model layer called Stores which is genius in its simplicity. In React land I’ve used Flux, Redux, MobX, mobx-state-tree, zustand and pullstate, and IMO Solid Stores beats them all (because Solid makes this possible, not because those libs…

What is different about stores compared to what React offers?

Re: Svelte 5: Runes

#104
I've been trying Svelte for the last couple of months. At first the claim was that it's not complicated like React because there's a lot less concepts to learn. And it's just using basic Javascript and CSS so those skill sets are transferable to any other job. As I use it more and more, there's more and more special way of doing things I have to learn: store, reactive variable, $, $$, etc. I didn't mind, sure I'm in Svelte's world. But the number of libraries is limited and it really slowed me down tremendously. Now with runes, it's just more "magic" to learn. I think that's the last straw for me. I'm done with Svelte experiment. Back to React land.

Re: Svelte 5: Runes

#105

Earlier quoted context omitted.

Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…

> create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're describing. Care to elaborate or do you have a link to a blog post explaining further?

I'll try — I'm currently fielding a zillion messages so excuse brevity!

Basically, you can only modify state _where it's declared_. If you want to allow the 'outside world' to modify that state, you need to expose a function that does so. This is unlike cases where you're passing around an observable object where anyone with a reference, which they need for reading, can also write to it by doing `thing.value += 1`.

This is something Solid gets right — you can only change a signal's value if you have a reference to its setter.

Re: Svelte 5: Runes

#106
Everyone comparing to React but this looks similar to RxJS Observables as well. Don't leave out us Angular folks!

Re: Svelte 5: Runes

#107
> Like every other framework, we've come to the realisation that Knockout was right all along.

I never had so much fun and understanding of a UI framework as I did when working with KnowckoutJS and DurandalJS way back when.

Re: Svelte 5: Runes

#108
post #83

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

One day my MooTools skills will be cutting edge again, i'm positive.

I was very glad when jQuery won. I never liked MooTools or Prototype, really. jQuery was love at first sight [site]

Re: Svelte 5: Runes

#109
post #33

Earlier quoted context omitted.

> code written in 2018, when hooks first came out, still works today Does not Svelte from 2018 works today?

jQuery from 2009 also still works today. What I meant was, developers want to use the latest and greatest. Hooks added in 2018 havent changed, there’s no replacement api for them - it’s still modern code. They got the DX right from the start, that other libraries are still trying to emulate.

that's one thing I admired about the React team back then, they took the time to think about how things "should" work long term. The functional/hooks release was criticised as people liked their class components, but time has shown that hooks were the correct decision.

I feel they lost that as people gradually rotated out of the team, around the time they announced concurrent-mode, now suspense and the half baked RSC "release".

Re: Svelte 5: Runes

#110

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 it's entirely Javascript. No templates, computed/derived values or any of that other bullshit. You could probably implement the compile step in like 5 lines of code.

I've built big projects in Vue and find it almost impossible to find a reason to use it. Svelte looks cut from the same cloth. They just fundamentally have the wrong approach.

Post reply on HN