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.

Peace out