Is it time to move on from Svelte?

[frederikhors]

Hello everyone,

I've been a Svelte user since the early days.

Today I have a few applications created with Svelte 5 and Svelte Kit 2, some simple, some very complex.

The Svelte ecosystem hasn't grown much over the years; I really miss professional libraries for state management and heterogeneous UI components (I'm tired of using one library for Selects, another for tabs, and yet others, all different to use and all wrapped in my own custom components).

Now that Vue 3.6 with Vapor mode is coming, and given its results better than Svelte 5 what's stopping me from switching to Vue 3.6 and Nuxt 5?

I searched and in 10 minutes I found:

• https://github.com/vuejs/pinia
• https://github.com/posva/pinia-colada
• https://github.com/directus/rstore
• https://github.com/Kong/swrv
• https://github.com/nuxt/ui

And so on.

I loved and still love Svelte, but what future is coming?

Lately, an important issue like state_referenced_locally has caused us a lot of problems in a large application and made us realize we were doing something wrong because that warning is a sign of a possible future bug, and we feel like everything is stale and slow in the Svelte community.

Are we wrong to think this?

I'd like to change, but I love Svelte so much that I can't, so here's this post asking for your help.

[andrewc-monad]

Hello everyone,

I've been a Svelte user since the early days.

Today I have a few applications created with Svelte 5 and Svelte Kit 2, some simple, some very complex.

The Svelte ecosystem hasn't grown much over the years; I really miss professional libraries for state management

What state mgmt libraries do you think you need now or will need in the future? I feel like in Svelte & SvelteKit, this is more of a solution looking for a problem. Page & layout loaders fetch data from an external source, pass it to an SSR +page.svelte, and data is rendered. For client-side state lifecycle management, use a JS class instance with $state members and instantiate an instance of a class with the context API. Move state updates from +page.svelte to the class and it makes it easier to test and keeps things encapsulated nicely.

and heterogeneous UI components (I'm tired of using one library for Selects, another for tabs, and yet others, all different to use and all wrapped in my own custom components).

Why are you using multiple libraries for simple UI components? shadcn-svelte has all of these items and they're all fully customizable. There's other more frameworks that are more "batteries-included" like Skeleton and Flowbite.

As for building more complex custom components out of simple things from the above examples, that's been my experience in any long-term project regardless of framework.

Now that Vue 3.6 with Vapor mode is coming, and given its results better than Svelte 5 what's stopping me from switching to Vue 3.6 and Nuxt 5?

I searched and in 10 minutes I found:

• https://github.com/vuejs/pinia
• https://github.com/posva/pinia-colada
• https://github.com/directus/rstore
• https://github.com/Kong/swrv
• https://github.com/nuxt/ui

And so on.

Disclaimer: I haven't had the occasion to use Vue.js in anything more than a hobbyist environment.

Reading through the above libraries, these all look like they might not fully support the new vapor mode. They do look cool but I'm thinking "YAGNI" (You Aren't/Ain't Gonna Need It).

I loved and still love Svelte, but what future is coming?

Lately, an important issue like state_referenced_locally has caused us a lot of problems in a large application and made us realize we were doing something wrong because that warning is a sign of a possible future bug, and we feel like everything is stale and slow in the Svelte community.

Agreed on this. I recently upgraded our main UI at work to a later version of Svelte and ran into this. We have a thorough set of Playwright specs that cover pretty much every page in our app and we haven't ran into any issues with runtime bugs w.r.t. the above warning condition. My only frustration with the above change in Svelte is that isn't fully clear how to update a piece of code to fix the warning, and different $state and $derived setups could require different solutions that might affect parent components.

Are we wrong to think this?

I'd like to change, but I love Svelte so much that I can't, so here's this post asking for your help.

I can only speak for myself, but using SvelteKit & shadcn-svelte for the past year and a half at work has been a genuine breath of fresh air. Before then, I was fully into the React SPA ecosystem with reflux -> redux -> redux-toolkit -> apollo and etc. Not to mention all the various UI libraries for React. Bootstrap, Material-UI, Semantic-UI. Interestingly enough, I've never had occasion to use Next.js in a professional setting.

SvelteKit just makes it so much easier to reason about building parts of a UI. I think in terms of pages - what data do I need to fetch on this page, and what form actions (if any) are needed for sending data back to an API? (I haven't enabled remote functions yet since it's still in experimental mode, last I checked).

One last point: always remember "the grass is greener..."

[teemingc]

The Svelte ecosystem hasn't grown much over the years; I really miss professional libraries for state management and heterogeneous UI components (I'm tired of using one library for Selects, another for tabs, and yet others, all different to use and all wrapped in my own custom components).

There are both handpicked packages https://svelte.dev/packages and user submitted packages https://sveltesociety.dev/library that you can choose from. bits-ui is what shadcn-svelte uses under the hood and that should satisfy most of your component needs.

Now that Vue 3.6 with Vapor mode is coming, and given its results better than Svelte 5 what's stopping me from switching to Vue 3.6 and Nuxt 5?

You should give it a try and report back on what we could improve upon in comparison.

Lately, an important issue like state_referenced_locally has caused us a lot of problems in a large application and made us realize we were doing something wrong because that warning is a sign of a possible future bug, and we feel like everything is stale and slow in the Svelte community.

I’m not sure how the compiler warning relates to the Svelte community, but it’s very important for users to help contribute back with high quality issues and PRs. We need you!

[paoloricciuti]

The Svelte ecosystem hasn't grown much over the years; I really miss professional libraries for state management and heterogeneous UI components (I'm tired of using one library for Selects, another for tabs, and yet others, all different to use and all wrapped in my own custom components).

Not much to add to what @teemingc said: I don't think this is necessarily true and if the best component library is headless you really don't need much choice, you can style the same in multiple ways (and any serious application will need it's own design system). If you don't want to style them shadcn svelte is your friend.

Now that Vue 3.6 with Vapor mode is coming, and given its results better than Svelte 5 what's stopping me from switching to Vue 3.6 and Nuxt 5?

Vue Vapor was "coming" more than 1 and a half year ago, and it's also straightforward for not fully fledged reactivity systems to perform better than fully fledged ones. Are you sure are coming now and not in another year? This also brings me to

and we feel like everything is stale and slow in the Svelte community

We are in the middle of probably the most significant change in Svelte since it's beginning: new syntax with Svelte 5, new reactivity system and now new paradigm to load data (likely the most innovative one) with await expressions. This doesn't feel slow to me. These are many changes and that takes time, effort and time. We could rush out a solution, but we prefer going slow and provide a stable solution (and yet, this change took less than Vue Vapor...no shade to the Vue team, as I've said it DOES take time)

Lately, an important issue like state_referenced_locally has caused us a lot of problems in a large application and made us realize we were doing something wrong because that warning is a sign of a possible future bug

I don't understand the issue here...the issue it's there because people think it's a bug on the svelte side, but it's not: we are warning you that something could go wrong, and you should probably use a derived or ignore it as we've expressed multiple times on the issue. What would be your ideal resolution for the issue? I understand that it's not always straightforward to resolve the issue because you need to reason for each one of them, but what can Svelte do there?

I think especially for frameworks, it's very true that "The grass is always greener on the other side of the fence"...until you live inside an ecosystem you only see the good things of the other ecosystem.

Obviously if you do want to try out Nuxt 5 and Vue feel free to do it and, as @teemingc said, feel free to report back what we are missing here. And if you enjoy it feel free to switch away from Svelte...at the end of the day, the important bit is that YOU feel at home with your framework!

[OmidNejadabbasi]

The better results in question:

[brunnerh]

Yes, the difference between Vue Vapor and Svelte will be insignificant in the vast majority of situations.