Svelte5: A Less Favorable Vue3

[rxliuli]

https://gist.github.com/rxliuli/c886198390a9fd1138853d0e260025f3

Just some complaints after using Svelte 5 for 3 months, each one will reference a Svelte GitHub issue or Reddit link for explanation. I posted the same content on Reddit, but it seems to have received a poor response. The claim made by defenders that "Svelte's reactivity doesn't exist at runtime" is entirely wrong in Svelte 5. I hope the discussion here can be a bit friendlier, especially regarding the possibility of improvements afterward.

[brunnerh]

Runes Only Work in Svelte Components or .svelte.ts Files

I do not see the issue with that. Svelte components also require .svelte files and you would not expect to be able to write components elsewhere.

Hooks Using Runes Must Wrap State in Functions

Often the boilerplate can be reduced by using $state proxies, i.e. instead of

export function useTime() {
  let now = $state(new Date());
  // other code...
  return {
    get now() {
      return now
    },
    set now(value) {
      now = value
    },
  }
}

you return an object:

export function useTime() {
  let state = $state({ now: new Date() });
  // other code...
  return state;
}

Though, even with getters and setters, for more complex scenarios this is probably still preferable to the mess that is the stores API in JS.

Classes as First-Class Citizens for Runes... or Not?

I would only use classes if I really need the performance, one of the reasons classes are not deeply reactive is to preserve speed.

Use regular objects in $state for proxy-based deep reactivity.

As documented, you cannot use bindable props in tests because they're template-specific features with no JavaScript equivalent.

Bindable props are properties with a getter & setter, as has already been pointed out in your linked question.

Form Components Are Uncontrolled by Default, Which Can Cause Issues

What happens if you remove the bind? One-way binding? No, it only sets the initial value, then the input's internal state takes over, contrary to expectations.

This is not quite correct. The element is updated according to state changes so if the referenced state is changed later, the element will be updated. It just does not prevent the user or element from changing the state.

If you want to prevent interaction with a form element, make it read-only or disabled, everything else is just confusing the user.

Small Ecosystem

Updates for Svelte 5 will take some time, the new version has only been out for a few months, and for the most part, if there is a vanilla JS implementation of something, it can usually be integrated fairly easily.

Virtual List: Couldn't find libraries supporting variable row height/column width for lists/grids

If you are able to find any JS library that actually does this well, let me know because I have not come across one so far.

---

I will agree that there is a certain increase in complexity regarding the base APIs. It is a tradeoff that yields more flexibility, a more uniform reactivity system and higher performance. The reactivity system in particular also simplifies certain things, e.g. stores are now obsolete (though of course they are still in use in various libraries).

You claim that there are "many edge cases and quirks" but the same is true for previous Svelte versions, but you have gotten used to those or were luck enough to not run into them.

Personally, I think Svelte 5 is an improvement overall but that it could be a bit more work to get into.

[rxliuli]

I do not see the issue with that. Svelte components also require .svelte files and you would not expect to be able to write components elsewhere.

It reminds me that React hooks must start with "use," which is a very strange thing, no matter how they explain it. Additionally, I mention this because Vue 3/SolidJS, which also uses proxies, does not require you to use special file names; you can use it in any regular JS.

Often the boilerplate can be reduced by using $state proxies, i.e. instead of

I don't know about this, but I will give it a try!

If you want to prevent interaction with a form element, make it read-only or disabled, everything else is just confusing the user.

I want to decide whether to block user interaction based on business needs, such as multi-select functionality.

Kapture.2025-03-08.at.22.32.25.mp4

I would only use classes if I really need the performance, one of the reasons classes are not deeply reactive is to preserve speed.
Use regular objects in $state for proxy-based deep reactivity.

I think there are two ways to abstract logic from components. One is to write a class and use the entire instance of the class as reactive state; in this case, the class instance hardly touches the framework's state API, like Vue3 or MobX. The other is to use the method of React hooks, declaring state using the framework API and writing logic code around the state. However, in "Classes as First-Class Citizens for Runes... or Not?", I found that both methods are not very effective in Svelte.

[brunnerh]

I mention this because Vue 3/SolidJS, which also uses proxies, does not require you to use special file names; you can use it in any regular JS.

Runes are compiler instructions which are necessary for the API.

If you want to use reactive primitives in Vue, you need a ref which wraps the value in a { value } object. You could do the same in Svelte by defining a function in a module that just returns a $state({ value: x }) object.

This function then could be used in any regular JS module but then you also have to use .value everywhere in code as is the case in Vue (at least in JS, which does not automatically unwrap the value).

I want to decide whether to block user interaction based on business needs, such as multi-select functionality.

Stuff like that requires a lot of custom event handling anyway, so I don't think Svelte's handling of state matters much there.

[adiguba]

Hello,

I want to decide whether to block user interaction based on business needs, such as multi-select functionality.

I tried to implement that, and I didn't see any problems : it's just a handler on onchange that updates the value of the checkboxes...

https://svelte.dev/playground/8f4d17bcfaa34e47ab2d3561c0d0e223?version=5.22.6