13 ms·

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

pinoy420 2y ago
[dead]
dvrp 2y ago
pretty good. some people in my team don’t like svelte magic and wish we were using react but others say, and i quote, “damn this is clean” or “almost effortless it just works” and i’ve seen again and again engineers ramp up pretty fast compared to my Knockout, Angular, or React times… Pretty happy! Just wished they didn’t change their “magic” so often, but it’s the price to pay for innovation—if we can even call frontend development that, which I think we should but many frontend haters around here
- pier25 2y ago
  I'm guessing Svelte 5 will last many years. Maybe they'll release v6 to drop old stuff but I don't think the runes paradigm will change any time soon. Plus they need to invest some serious work onto SvelteKit...
snide 2y ago
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 want you passing components with props as props into another component. Svelte gives you "Snippets" instead, which work for some reusability, but are limited. It sort of forces simplicity on you by design, which I like. Most of React's deep nesting and state management doesn't exist in Svelte and is replaced with simple, better primitives. The bigger gain though for me was Svelte(kit) vs. Next JS. It's very clear what is on the server and what is on the client, and there's none of that "use client" garbage with silly magic exports for Next JS things. The docs are great. Svelte's biggest disadvantage is that the UI library ecosystem isn't as large. For me that wasn't as big of an issue because it was my expertise, but everyone else looking for a drop in UI library will find the Svelte versions a little worse than their React counterparts. Because svelte is compiled, it also is by default very snappy. I think choosing Svelte would likely give most devs a speed boost vs. the spinner soup that I've seen most React projects become. A lot of that is going to be in the skill of the programmer, but I love how fast my app is. [0]: https://bsky.app/profile/davesnider.com/post/3lkvum6xtjs2e https://bsky.app/profile/davesnider.com/post/3lkvum6xtjs2e
- strangescript 2y ago
  "There's only one component per file" If you don't do this in React, its your own fault.
  - morcus 2y ago
    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.
    - myko 2y ago
      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.
  - snide 2y ago
    Well. I think that's sort of what I like about Svelte. There's a lot less opportunity to make bad decisions.
  - vermilingua 2y ago
    Unfortunately some of us work with other people, and refusing to let them merge code we don't personally agree 100% with is a great way to stop working with other people :)
  - Toritori12 2y ago
    Maybe things have changed now or I was just a bad react dev but the way hooks works kinda force you to have many child one-off components to not trigger rerenders in the whole component when only a small part was connected to that part of the State being updated. Having all these one-offs components in different files was painful.
- ansc 2y ago
  >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.
CuriousRose 2y ago
I'm not a developer by trade, and have gone from 0 full-stack knowledge to building a MVP for my startup in 18 months using Svelte 4 and SvelteKit. Looking at the JS/TS ecosystem from the outside, it was a total nightmare and Svelte 4 was the only framework that seemed to make logical and aesthetic sense to me. Currently porting to Svelte 5 and it is less elegant in my opinion, but perhaps the problems it tries to solve are for more sophisticated developers and I don't really come across them or have knowledge of them. I would prefer to stay on 4, but I will take Rich's word for it that it will be better long term. Admittedly complicated components with lots of reactivity can be confusing to follow data changes with lots of $: lines so I have tried to minimise that from the beginning. The Svelte 5 code looks cleaner to follow for onboarding devs that aren't familiar with our codebase yet.
dimgl 2y ago
As much as I appreciate Svelte, the React devex is unmatched. I built a client-side app using Wails with Svelte 5 and I found myself wanting React's seamless devex and vast ecosystem. Once I migrated over to React it was like a huge handicap was lifted. Svelte is great. But if you're in a time crunch and you don't have a specific technical requirement that makes React a bad match, I don't think Svelte is worth it. A big part of the Svelte ecosystem is still using Svelte stores, and I found the "one component per file" paradigm to be a bit limiting.
- prophesi 2y ago
  > 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.
  - dimgl 2y ago
    That's right; but a lot of packages, like Superforms, use stores.
    - prophesi 2y ago
      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 https://superforms.rocks/examples?tag=runes
  - deleted 2y ago
    [deleted]
- DimmieMan 2y ago
  I think i'm about a chapter behind you. I'll add devex extends to TSX/JSX itself too, the editor support and language server experience is miles ahead. Alternative formatters/linters like Deno, Biome, oxc etc. all have great support out of the box too, not so much for svelte. For when react is a bad match; I'm investigating solid instead for this reason. The svelte ecosystem is in a particularly unfortunate spot right now comprising of single/few author projects that were starting to stabilise but now have a svelte 4 -> 5 migration shaking things up.
_benton 2y ago
Started out great and progressively degraded.
mentalgear 2y ago
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.

[dead]

dvrp 2y ago

pretty good. some people in my team don’t like svelte magic and wish we were using react but others say, and i quote, “damn this is clean” or “almost effortless it just works” and i’ve seen again and again engineers ramp up pretty fast compared to my Knockout, Angular, or React times… Pretty happy! Just wished they didn’t change their “magic” so often, but it’s the price to pay for innovation—if we can even call frontend development that, which I think we should but many frontend haters around here

pier25 2y ago
I'm guessing Svelte 5 will last many years. Maybe they'll release v6 to drop old stuff but I don't think the runes paradigm will change any time soon. Plus they need to invest some serious work onto SvelteKit...

snide 2y ago

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 want you passing components with props as props into another component. Svelte gives you "Snippets" instead, which work for some reusability, but are limited. It sort of forces simplicity on you by design, which I like. Most of React's deep nesting and state management doesn't exist in Svelte and is replaced with simple, better primitives. The bigger gain though for me was Svelte(kit) vs. Next JS. It's very clear what is on the server and what is on the client, and there's none of that "use client" garbage with silly magic exports for Next JS things. The docs are great. Svelte's biggest disadvantage is that the UI library ecosystem isn't as large. For me that wasn't as big of an issue because it was my expertise, but everyone else looking for a drop in UI library will find the Svelte versions a little worse than their React counterparts. Because svelte is compiled, it also is by default very snappy. I think choosing Svelte would likely give most devs a speed boost vs. the spinner soup that I've seen most React projects become. A lot of that is going to be in the skill of the programmer, but I love how fast my app is. [0]: https://bsky.app/profile/davesnider.com/post/3lkvum6xtjs2e https://bsky.app/profile/davesnider.com/post/3lkvum6xtjs2e

strangescript 2y ago
"There's only one component per file" If you don't do this in React, its your own fault.
- morcus 2y ago
  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.
  - myko 2y ago
    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.
- snide 2y ago
  Well. I think that's sort of what I like about Svelte. There's a lot less opportunity to make bad decisions.
- vermilingua 2y ago
  Unfortunately some of us work with other people, and refusing to let them merge code we don't personally agree 100% with is a great way to stop working with other people :)
- Toritori12 2y ago
  Maybe things have changed now or I was just a bad react dev but the way hooks works kinda force you to have many child one-off components to not trigger rerenders in the whole component when only a small part was connected to that part of the State being updated. Having all these one-offs components in different files was painful.
ansc 2y ago
>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.

CuriousRose 2y ago

I'm not a developer by trade, and have gone from 0 full-stack knowledge to building a MVP for my startup in 18 months using Svelte 4 and SvelteKit. Looking at the JS/TS ecosystem from the outside, it was a total nightmare and Svelte 4 was the only framework that seemed to make logical and aesthetic sense to me. Currently porting to Svelte 5 and it is less elegant in my opinion, but perhaps the problems it tries to solve are for more sophisticated developers and I don't really come across them or have knowledge of them. I would prefer to stay on 4, but I will take Rich's word for it that it will be better long term. Admittedly complicated components with lots of reactivity can be confusing to follow data changes with lots of $: lines so I have tried to minimise that from the beginning. The Svelte 5 code looks cleaner to follow for onboarding devs that aren't familiar with our codebase yet.

dimgl 2y ago

As much as I appreciate Svelte, the React devex is unmatched. I built a client-side app using Wails with Svelte 5 and I found myself wanting React's seamless devex and vast ecosystem. Once I migrated over to React it was like a huge handicap was lifted. Svelte is great. But if you're in a time crunch and you don't have a specific technical requirement that makes React a bad match, I don't think Svelte is worth it. A big part of the Svelte ecosystem is still using Svelte stores, and I found the "one component per file" paradigm to be a bit limiting.

prophesi 2y ago
> 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.
- dimgl 2y ago
  That's right; but a lot of packages, like Superforms, use stores.
  - prophesi 2y ago
    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 https://superforms.rocks/examples?tag=runes
- deleted 2y ago
  [deleted]
DimmieMan 2y ago
I think i'm about a chapter behind you. I'll add devex extends to TSX/JSX itself too, the editor support and language server experience is miles ahead. Alternative formatters/linters like Deno, Biome, oxc etc. all have great support out of the box too, not so much for svelte. For when react is a bad match; I'm investigating solid instead for this reason. The svelte ecosystem is in a particularly unfortunate spot right now comprising of single/few author projects that were starting to stabilise but now have a svelte 4 -> 5 migration shaking things up.

_benton 2y ago

Started out great and progressively degraded.

mentalgear 2y ago

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.