Live data from Hacker News

Svelte: $derived can now be overwritten

github.com

41–50 of 55 posts

Re: Svelte: $derived can now be overwritten

#41
post #4

People who have migrated a large enough production codebase to Svelte 5, what's your devex like?

I think Syntax.fm mentioned that the automatic migration tool 4->5 was excellent, and even for larger codebases everything almost immediately worked after conversion, with maybe just a few LoC changes they had to do manually.

Re: Svelte: $derived can now be overwritten

#42
post #9
post #4

People who have migrated a large enough production codebase to Svelte 5, what's your devex like?

I'm almost finished with a large, complex app written with Svelte 5, web sockets and Threlte (Three JS) [0]. Previously, I'd written React for about a decade, mostly on the UI side of things. I vastly prefer Svelte, because of how clean the code feels. There's only one component per file, and the syntax looks and writes deceptively like vanilla JS and HTML. There's a bit of mind-warp when you realize Svelte doesn't w…

>It's very clear what is on the server and what is on the client.

Is it though? Your `+page.svelte` is rendered on the server as well. Not only `.server.` is run on the server.

Re: Svelte: $derived can now be overwritten

#43
post #16

Agh, I understand why runes were implemented, but I still can't get myself to like them. It feels like Runes take away from what made Svelte Svelte (the simple, concise syntax), and changes like this seem like slow concessions back in that direction anyway.

They really are an improvement. Tracking data flow in a complicated component (bound props going in both directions, derived state, …) was terrible before runes — you just had to rely on compiler magic, which worked until it didn’t. Now it’s more or less obvious.

I wish they had found a way to make the compiler just work. No longer having the ability to update the DOM by updating bound variables eliminates one main reason I wanted to use Svelte in the first place. I still love SFC though.

Re: Svelte: $derived can now be overwritten

#44
post #36

Earlier quoted context omitted.

You just have to build a big project with Svelte 5 and you will come to like them. A lot of magic is okay for simple application, but when you want to build anything that scales Svelte before runes was just horrible. With Svelte 5 and Runes you can look at any component and instantly know what it does. You couldn't do that with Svelte 4 unless you wrote the whole code yourself.

I think that's actually the core of the problem. It's the right choice for big projects. But Svelte was an absolute joy to use when brewing up a small or medium size project that you want to just work first time. Runes are the right choice for the library, but there is still a loss there.

Not sure I agree. I’ve built numerous small projects in Svelte 3 & 4, sharing that same joy many of us had! Stores were generally amazing.

I was highly skeptical of runes upon the original announcement and very cursory usage during beta phase.

When I finally got to porting a couple simple projects, I shrugged “this isn’t too bad, but what’s all the fuss?”. I ported a mid size project and it really clicked.

Then I went to build a brand new small project, and I found myself in love with runes. Having spent the time to get under the hood (especially using them as classes), being able to leverage them during the design phase really sped me up and facilitated cleaner/better state management.

Re: Svelte: $derived can now be overwritten

#45
post #28

Earlier quoted context omitted.

> A big part of the Svelte ecosystem is still using Svelte stores Just a nitpick, with runes in Svelte 5, stores have largely become obsolete. $state, $derived, and $effect replace most of the needs people would normally use stores for.

That's right; but a lot of packages, like Superforms, use stores.

That's fair. The major libraries I use migrated to runes even before Svelte 5 was officially released. You can use runes with Superforms[0] as any store-based API can have rune-based reactivity passed to it, but it sounds like using runes internally is a V3 milestone.

[0] https://superforms.rocks/examples?tag=runes

Re: Svelte: $derived can now be overwritten

#46
Since Svelte 5 was announced, we began using our own library for state management as we could not fully understand the semantics and were afraid of potential changes. If you're curious, here it is: https://github.com/okcontract/cells

It is compatible with both Svelte 4/5 and more importantly pure TS libraries.

Re: Svelte: $derived can now be overwritten

#47
post #43
post #16

Earlier quoted context omitted.

They really are an improvement. Tracking data flow in a complicated component (bound props going in both directions, derived state, …) was terrible before runes — you just had to rely on compiler magic, which worked until it didn’t. Now it’s more or less obvious.

I wish they had found a way to make the compiler just work. No longer having the ability to update the DOM by updating bound variables eliminates one main reason I wanted to use Svelte in the first place. I still love SFC though.

> No longer having the ability to update the DOM by updating bound variables

What do you mean by that?

Re: Svelte: $derived can now be overwritten

#48
post #42
post #9

Earlier quoted context omitted.

I'm almost finished with a large, complex app written with Svelte 5, web sockets and Threlte (Three JS) [0]. Previously, I'd written React for about a decade, mostly on the UI side of things. I vastly prefer Svelte, because of how clean the code feels. There's only one component per file, and the syntax looks and writes deceptively like vanilla JS and HTML. There's a bit of mind-warp when you realize Svelte doesn't w…

>It's very clear what is on the server and what is on the client. Is it though? Your `+page.svelte` is rendered on the server as well. Not only ` .server. ` is run on the server.

Yeah, this is SvelteKit's biggest weakness. Easy to write code that seems to work until some unusual confluence of circumstances makes it run on the client when you've always tested it on the server, or vice versa, and it breaks. I still really like it for personal projects, but I think I'd want a clearer client-server separation for anything more complex.

Re: Svelte: $derived can now be overwritten

#49
post #47
post #43

Earlier quoted context omitted.

I wish they had found a way to make the compiler just work. No longer having the ability to update the DOM by updating bound variables eliminates one main reason I wanted to use Svelte in the first place. I still love SFC though.

> No longer having the ability to update the DOM by updating bound variables What do you mean by that?

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

Re: Svelte: $derived can now be overwritten

#50
post #49
post #47

Earlier quoted context omitted.

> No longer having the ability to update the DOM by updating bound variables What do you mean by that?

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?
Post reply on HN