Live data from Hacker News

Svelte: $derived can now be overwritten

github.com

51–55 of 55 posts

Re: Svelte: $derived can now be overwritten

#51
post #13

Earlier quoted context omitted.

"There's only one component per file" If you don't do this in React, its your own fault.

I also don't really see why this is a positive. If you have too much in a file, then split it off? It doesn't fundamentally add or subtract and complexity either way.

I think Svelte likely has a lot of benefits over React but I feel like this is a negative. It's easier for locally of code to keep related components together, and they can always be put into their own files later.

Re: Svelte: $derived can now be overwritten

#53
post #50
post #49

Earlier quoted context omitted.

In Svelte, traditionally, changing the value of a variable updates DOM elements using that variable.

Right, and what makes you think you can't do that in Svelte 5?

The release announcement? https://svelte.dev/blog/svelte-5-is-alive

   let count = $state(0);
You can't just set a variable anymore, you need to use runes. Which is silly - I shouldn't need to tell Svelte this is reactive, any variable referred to inside the HTML in the component is logically reactive and Svelte should know this. Like it used to. This is why we had a compiler.

I should point out that indeed (as you're correctly pointing out) updating bound variables looks the same, just that declaring them sucks. I don't really trust they won't do similar things to updating bound variables though.

Re: Svelte: $derived can now be overwritten

#54
post #53
post #50

Earlier quoted context omitted.

Right, and what makes you think you can't do that in Svelte 5?

The release announcement? https://svelte.dev/blog/svelte-5-is-alive let count = $state(0); You can't just set a variable anymore, you need to use runes. Which is silly - I shouldn't need to tell Svelte this is reactive, any variable referred to inside the HTML in the component is logically reactive and Svelte should know this. Like it used to. This is why we had a compiler. I should point out that indeed (as you're c…

On the one hand, yes, it's annoying to have to explicitly declare state. On the other hand, it's much easier and clearer to declare derived state now. Pre-Svelte 5 code had a lot of this:

    let someState = someOtherState.thing;
    $: someState = someOtherState.thing;
Which was awful.

Svelte 5 does still have a compiler, and there's still a lot of "magic" involved — it just asks you to be more explicit about your intentions in some cases. Of course in an ideal world it could just figure it out, but some distinctions (do I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?) need to be specified explicitly, and I prefer clear syntax for that explicit specification over the terrible, verbose hacks that you used to have to use in order to prod the compiler "magic" in the right direction.

I was a runes hater, then I bit the bullet and migrated a big app to Svelte 5. Now I get it. You should give them a chance as well.

Re: Svelte: $derived can now be overwritten

#55
post #54
post #53

Earlier quoted context omitted.

The release announcement? https://svelte.dev/blog/svelte-5-is-alive let count = $state(0); You can't just set a variable anymore, you need to use runes. Which is silly - I shouldn't need to tell Svelte this is reactive, any variable referred to inside the HTML in the component is logically reactive and Svelte should know this. Like it used to. This is why we had a compiler. I should point out that indeed (as you're c…

On the one hand, yes, it's annoying to have to explicitly declare state. On the other hand, it's much easier and clearer to declare derived state now. Pre-Svelte 5 code had a lot of this: let someState = someOtherState.thing; $: someState = someOtherState.thing; Which was awful. Svelte 5 does still have a compiler, and there's still a lot of "magic" involved — it just asks you to be more explicit about your intention…

> Of course in an ideal world it could just figure it out

Yep. We're agreed there.

> I want this variable to always update when its dependencies change? or do I just want to set an initial value based on the dependencies?

Reasonable to default to first, ask the developer to be explicit about the second if needed.

Honestly I still love SFC and Svelte having opinions about CSS and state storage is great. But it feels like this was the wrong direction. The 'magic' is why we used Svelte.

Edit: I think my tone here is a little off due to illness. Sorry if I sound grumbly. Wasn't my intention.

Post reply on HN