You know, on Saturday I generally spend my day with my family rather than answering snarky comments. But since I have some time now let's get down to the answer:
> Runes Only Work in Svelte Components or .svelte.ts Files
Yes and this is actually a positive thing: you want the compiler to touch a very contained part of your application, when you know you can expect magic. This also allow us to be more "aggressive" in the transformation since we know regular js libraries will not be affected by it.
> Hooks Using Runes Must Wrap State in Functions
This is true for svelte, Vue, solid and whatever signal based framework: the difference? Other frameworks can't deal with primitive values so you feel like you have to do extra work in svelte. In reality you can actually build both Vue and solid styles in svelte (the opposite is not true). $state({ value: "myval" }); if basically Vue ref.
> Classes as First-Class Citizens for Runes... or Not?
You start talking about classes and then complain that pojos don't have the same treatment? Those are two very different things, and again, it was a specific design choice...it might be a quirk that you have to know about (that the compiler literally highlight for you) but it serves as a guardrail for you to write less bug prone code. P.s. as said above you can actually build a ref function a la Vue pretty easily and you can use your ref function just like in Vue if you really want this behavior.
> Svelte Templates Include Features That Cannot Be Implemented in JavaScript
This is just blatantly false: you can test a bindable props by passing in state as props and that's literally it. If you want you can do
```ts
const props = $state({ value: "" });
render(Component, { props });
```
or if you want to have a literal prop you can just use getters and setters
```ts
const value = $state("");
render(Component, { props: {
get value(){
return value;
},
set value(new_value){
value = new_value;
}
}});
```
> Form Components Are Uncontrolled by Default, Which Can Cause Issues
As you've said this isn't specific to svelte...the controlled nature is specific to react. Why this would be the right thing? Most of the times having an uncontrolled form is much better and you can sync the state on submit or even better just use normal forms with enhance and sync the state on the server by getting progressive enhancement for free. And if you need it to be controlled, you have the tools to do it.
> Small Ecosystem
If you search for svelte specific packages you will certainly find less than react...but you can literally just use any JS package with ease in svelte. That said even for the things you describe in the post it seems you are a bit nitpicking: there a router but not an in memory one, there's shadcn/svelte but it has problems with shadow Dom...the rest you probably just need to search better: `virtua` is a wonderful virtual list, LayerChart a wonderful chart library.
> Community Response
We are definitely trying to work to reduce the apparent complexity...a lot of people looked at svelte 5 superficially and deemed it too complex. The same people after trying it for good agreed that is not complex at all and a huge step forward for composability and performance. Just try it out, trust us.
That said: despite almost all the point being imho invalid this is still a good post because it show us where we can improve the docs and the explainers to ease out this experience.
View transition api is a new set of api that allows you to animate between routes. This library aim to make this as simple as possible without loosing much in flexibility!
It's finally time to announce what Antonio Sarcevic and me were up to for the SvelteSociety Hackaton.
Introducing SvelteLab: a supercharged svelte REPL, built with stackblitz webcontainers and hosted on vercel with SvelteKit, for SvelteKit by Svelte lovers
The power of node in your browser combined with an accessible editor, tailored for SvelteKit experimentation:
As for why we need $ or reactive is because JavaScript does not comes with a way to express reactivity. In the case of svelte this means having to come up with a syntax for the compiled language, for Vue means that you need to wrap your normal object in a proxy to let Vue know when you are accessing or setting a variable.
I guess this is just a difference in opinion then, haha. Not so different from Python vs Ruby.
If we talk about bundle size, then there might be more interesting discussion. Svelte claims to be pretty small - I wonder how that pans out compared to an "equivalent" app in Vue or even vanilla JS.
> Svelte claims to be pretty small - I wonder how that pans out compared to an "equivalent" app in Vue or even vanilla JS.
I don't have helpful benchmarks here, but can anecdotally confirm that the compiling and bundling magic that svelte does is... magical. They do some really smart tree-related things at build which are (imo) a major feature leading to this quick-and-small packaging of an app.
You can use the local version using the command `npx -y @sveltejs/mcp` or use the remote version with `https://mcp.svelte.dev/mcp`)
It provides tools and resources for docs and an autofixer tool that gives the LLM suggestions on how to write proper Svelte code.
And it's open source, of course: https://github.com/sveltejs/mcp to look at the code and open issues/feature requests!
We are eager to make your AI experience writing Svelte the best possible!