> Runes Only Work in Svelte Components or .svelte.ts Files
This is like complaining that types only work in .ts files
> Hooks Using Runes Must Wrap State in Functions
This is on purpose, as you know. They want reactivity to be explicit. The benefit of runes is, that if you like Vue and Solid so much, you can literally create their reactive primitives in Runes, and it works.
> Classes as First-Class Citizens for Runes... or Not?
This entire section is weird. The title complains about classes, but then the second code snippet is a function back again. And the third is also equally weird, why would you ever need that.
> Svelte Templates Include Features That Cannot Be Implemented in JavaScript
This one I don't know sufficiently about. I'll let others argue about it. But I do think this was already present before
> Form Components Are Uncontrolled by Default, Which Can Cause Issues
Same here, Svelte always had this behavior. As you also state, this is present in other frameworks, such as Vue itself, which you're promoting as better than Svelte
> Ecosystem
If you want someone to point out the issues people had when migrating to Vue3, and still have to this day, sure. Every framework really, when they go through such a big change.
> Community Response
Criticism is fine. But a lot of the things have been discussed over and over tbh, and a lot of it is poorly structured, e.g. saying "svelte is react now", which just brings noise to the table. I've personally seen a lot of other criticism which has led to action being taken.
As a proof of that, recently here in hacker news there was a post criticizing Svelte 5. It is now mentioned on this PR as a change for it https://github.com/sveltejs/svelte/pull/15469
I do criticize things in Svelte as well, e.g. I do like the patterns for passing reactivity through boundaries, but I do think it needs to be well documented on how to, as people can get a bit lost. Or maybe some utilities shipped to it. But I don't personally like `ref` and `createSignal`. They come with their own issues.
> This is like complaining that types only work in .ts files
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.
> This is on purpose, as you know. They want reactivity to be explicit. The benefit of runes is, that if you like Vue and Solid so much, you can literally create their reactive primitives in Runes, and it works.
It just adds extra boilerplate work. Unless you use a custom Proxy to wrap the runes state, I don't think it's possible to implement the Vue Composition API, and if you do that, there will be a double proxy, and even $state.snapshot won't save me.
> This entire section is weird. The title complains about classes, but then the second code snippet is a function back again. And the third is also equally weird, why would you ever need that.
Because the escape hatch left by svelte5 is very strange and seems inconsistent, in the four situations I listed, svelte5 can only make half of them effective, while vue3 and similar frameworks can make them all work properly.
> Same here, Svelte always had this behavior. As you also state, this is present in other frameworks, such as Vue itself, which you're promoting as better than Svelte
Yes, it has always existed, but svelte5 still hasn't addressed it. Also, I don't think vue3 is better than svelte4 because I believe their APIs are very different and not easy to compare. The runes API of svelte5 looks very familiar, and I will certainly try to compare them.
> 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.
You can name hooks whatever you want. The `use` prefix is just a linting thing. Once transpiled to JS, there isn't really any way for React to know whether you prefixed your hook with `use`.
I understand the mistake though. The React docs state `You must follow these naming conventions` when talking about the `use` prefix. But that's all it is -- a convention.
These frameworks have so many versions over time because the web, browsers, and people’s expectations of the capabilities of websites are a moving target.
Over time you’ll see many major revisions as you do in every other framework in existence.
This is like complaining that types only work in .ts files
> Hooks Using Runes Must Wrap State in Functions
This is on purpose, as you know. They want reactivity to be explicit. The benefit of runes is, that if you like Vue and Solid so much, you can literally create their reactive primitives in Runes, and it works.
> Classes as First-Class Citizens for Runes... or Not?
This entire section is weird. The title complains about classes, but then the second code snippet is a function back again. And the third is also equally weird, why would you ever need that.
> Svelte Templates Include Features That Cannot Be Implemented in JavaScript
This one I don't know sufficiently about. I'll let others argue about it. But I do think this was already present before
> Form Components Are Uncontrolled by Default, Which Can Cause Issues
Same here, Svelte always had this behavior. As you also state, this is present in other frameworks, such as Vue itself, which you're promoting as better than Svelte
> Ecosystem
If you want someone to point out the issues people had when migrating to Vue3, and still have to this day, sure. Every framework really, when they go through such a big change.
> Community Response
Criticism is fine. But a lot of the things have been discussed over and over tbh, and a lot of it is poorly structured, e.g. saying "svelte is react now", which just brings noise to the table. I've personally seen a lot of other criticism which has led to action being taken.
As a proof of that, recently here in hacker news there was a post criticizing Svelte 5. It is now mentioned on this PR as a change for it https://github.com/sveltejs/svelte/pull/15469
I do criticize things in Svelte as well, e.g. I do like the patterns for passing reactivity through boundaries, but I do think it needs to be well documented on how to, as people can get a bit lost. Or maybe some utilities shipped to it. But I don't personally like `ref` and `createSignal`. They come with their own issues.
reply