SolidJS seems designed right so that it doesn't need so many major revisions and it feels quite stable.
It feels like an evolved React that is simpler to use.
Also its signals and stores can be used in normal .ts files, so it is easier to create re-usable "stores".
edit: BTW haven't been following Svelte but it's already version 5? I thought it was the newest framework.
Which is exactly what is said about every framework
The solid-js surface is relatively small, the jsx / css is identical to the native, the Hook simply builds the DOM once. solid-js therefore brings above all a createSignal that adds an observer where it is called in the DOM to directly update the DOM accordingly.
You might think of solid-js more as a signal primitive than a real framework.
(Telling myself: damn should of put that in my original comment cause of course someone's gonna comment that.)
Over time you’ll see many major revisions as you do in every other framework in existence.
The simplicity and the power it brings is so good.
I’ve also used SolidStart for a project and it’s by far the best meta framework I’ve tried so far. Again, simplicity, power and extensibility.
However, the SolidJS ecosystem falls behind when building a full web application: The router is okay? Metadata is very separate... and SolidStart isn't pulling it all together in the way it should. Working with async is also a mess.
This makes it feel like you're having to learn 3-4 entirely separate systems.
- I can write for-loops, conditions, etc. in the same language I write my logic in with the same TypeScript and (Vscode) IDE support (e.g. refactoring, formatting, error reporting) vs using a special template language + IDE plugin.
- I find HTML templates really ugly and harder to read in that your dynamic logic code gets lost inside the static markup and presentation code e.g. `<li v-if="items.length > 2" v-for="{ id, text } in items" :key="id" class="card card-body fw-bold small"> {{ text }} </li>` vs `{items.length > 2 && items.map(({ id, text }) => (<li key={id} class="card card-body fw-bold small">{text}</li>))}` (still quite ugly but most of the logic is on the outside now).
- I can easily assign chunks of HTML to variables or generate HTML snippets via concise functions in regular TypeScript instead of being forced to create a new verbose component via HTML templates each time e.g. the arrow function above can be assigned to variable and reused. HTML templates feel very limiting in comparison.
It's sometimes awkward finding the JSX syntax (like for using Vue slots), but this is more because it's less common.
Would be curious of others who have tried this Vue 3 + JSX combination!
``` li.card.card-body.fw-bold.small(v-if="items.length > 2" v-for="{ id, text } in items" :key="id") | {{ text }} ```
Personally I find this really readable. The HTML element is the most visible thing, then we get classes, then all the logic in parentheses. Then, standing by itself, the content. And we don't need any closing tag.
It also makes debugging harder because there’s a heavier translation of stuff you see in dev tools vs your codebase. It also makes gripping and automated project code replacement harder.
You also can’t easily copy paste HTML code examples from other places. Other developers have to learn and might resist it so you have a mix of template systems.
I could keep going…
I have never needed to move pug code to non pug. If I switched from Vue to Svelte I'd keep using Pug.
I have sometimes needed to do the opposite. There are tools to automate it, but even manually it's much less effort than say converting Vue to React.
Lastly, the promise of your comment, that technical debt is always an important consideration in all projects, is not correct.
There's a million considerations.
Ruby on Rails went through this over a decade with HAML with wide scale adoption and it was largely a mistake, projects always end up moving back to HTML. Or into JSX or whatever HTMLy syntax.
I've worked on at least 3 or 4 projects that switched JS frameworks and stuff like pug would always be burden on moving over.
Ive been down that rabbithole enough times and it's simply not worth the mostly overstated DX benefit. Nerds trying to be hyper efficient in the wrong ways.
Simpler and closer to standards is always always better.
const elToolbar = generateToolbar(toolbarItems) // returns JSX
const elUserCards = users.map(user => <div class="card card-body fw-bold">{{ user.name }}</div>)
return <div>
{elToolbar}
{elUserCards}
</div>
Makes me wonder why this is all so difficult. Vue has a lot less problems for me than previous iterations and frameworks, but it's still frustrating how many footguns still exist. Like gotchas where you lose reactivity where linters/compilers won't catch the problem for you, and you forget the gotchas if you're not immersed in that framework for a while.
I'm not getting why we can't have robust static checking for this stuff vs trusting every developer to be careful.
https://github.com/pugjs/pug/activity
That is not necessarily a bad thing, sometime stability is what matters the most. But here the last commit was removal of a security and bugs branch...
Ha, I do this in places but I'm not sure if this approach is encouraged? Compared to slots, I like this too, it's a lot less verbose and the syntax is simple and easy to remember.
> While JSX is officially supported by Vue, it does not seem to be encouraged and may have subpar support in the ecosystem. But that is only something I'm afraid of, I do not have any experience with it, yet.
Worst case, you can switch to Vue HTML templates in some files and use JSX in others. I've not found issues mixing them together like this.
I’ve seen the third party package for the compiler that has popped up to try and handle this, but I don’t like the limitations.
I’m hoping with Vue 4 they will find a way to support multiple components in one SFC file (which kinda violates the naming but hey…)
Yes, as in a component would be a regular JavaScript function that takes some parameters and gives you back some JSX to render. It's really concise and there's no need to muck around with plugins or anything special, it's just regular JavaScript.
When I'm working on projects that use Vue HTML templates, I've often got pages that have some small HTML snippet that appears two or three times, and just don't want to go through the effort of having to break the snippet out into its own component file because its so verbose. JSX makes this really low friction so you do it more often.
And for one more reason: the only tooling needed is esbuild, which can handle TSX. No finding a Vue SFC plugin, just a single dependency and you're off.
(Of course you'll probably also want to install typescript itself as IDE type checking isn't adequate for a real project.)
https://vuejs.org/guide/extras/render-function.html#jsx-tsx
Edit: Yes, oops, wrong link.
Do you happen to know if I can I use my own bundler set up with this? (esbuild, rspack, etc?)
> 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.
I strongly disagree. This is literally how HTML works. This makes forms with default values MUCH less awkward to author.
I think Svelte has a nicer template syntax and the reactivity is cleaner is some cases, but it feels like there's no "best practice" or "recommended" patterns in a lot of common cases and I don't have the confidence to make something that won't suck later.
Vue has been more stable for longer so it's easier to find dozens of examples of the thing you're trying to do with less argument over how to do it, and LLMs seem to produce much better Vue code.
The 5th version made two "non-error", but ergonomic changes, for the sake of larger code bases and standard formats over quick, yet reliable, reactive and testable code (which first attracted me to svelte): - the need for getters and setters when using $runes in functions; this is a waste of time and almost always unnecessary in the contexts in which one uses small store classes. Not that Svelte 4 was better, it was different.. in a pinch, I'd take 4 though. - using folders for routing and using standard page.svelte.js and server.svelte.js naming for everything; it clutters your IDE file list. You could say it's good practise, but limiting to one component per file also causes more files in some cases than multiple components per file (as is possible in React)
Despite all this, Svelte 5 introduces $writable, which is kind of for the use case of one-off simple state - which doesn't need getters/setters - so the whole thing doesn't feel that consistent.
I don't mind using consistent runes - that is a bit of boilerplate, but makes it easier to reason about. I still love the reactivity of using bind (like Vue) and using $effect with it automatically figuring out what to do without the footguns of Reacts useEffect. I love that I can just start writing files and routing will work, css can just go there without a node module to process it.
Increasingly, I've realised React is probably going to remain my number 1: - Recent changes are mostly just shorthands to reduce boilerplate - Mobx has got state down - Hooks have footguns, but I know them - The eco-system is still unmatched - `use` and other statements allowing async loading (like other recent shorthands) is helpful, a lot of my components used to have boilerplate to do async stuff, and it took effort to make failure cases/loading work well. This pairs very well with server functions too.
Yes, but then you can just use a class.
> using folders for routing and using standard page.svelte.js and server.svelte.js naming for everything
This wasn’t introduced with Svelte 5, this is SvelteKit.
> Despite all this, Svelte 5 introduces $writable
No it doesn’t? Do you mean $state()?
Yes, but I immediately pointed out the oddities of the combination of class and runes below, which looks very strange and inconsistent.
> Despite all this, Svelte 5 introduces $writable
I don't know what this is.
True, and it is a bit weird, but you made it difficult to understand your point by talking about a function which creates and returns a class for some reason.
It took me a second to work out you were the author of the original article, rather than OP by the way, didn’t really understand properly for a moment.
> 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
It is either plain ASP.NET MVC, Spring or Next.js, depending on the programming language, and that is it.
I am also an old timer. Hand rolled HTML and JavaScript since '97?
Came up with ASP (both VBScript and JSCript (it's like we're full circle with JS SSR)). Move to ASP.NET when it was in beta. jQuery, Prototype, Knockout.js.
Vue.js SFC is the thing that feels closest to HTML + JavaScript components done right. It's reactivity model is the same as that of JS whereas React's reactivity model is "inverted" [0]
The state model (Pinia or just composable reactive primitives) is simple, Just Works, and never gets in your way.
Lots of folks like JSX because they don't like HTML and CSS. I'm the opposite; I like Vue because I like HTML and CSS and I like JavaScript. Vue is HTML + JavaScript done right with a congruent reactivity model.
[0] https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...
Privately I seldom use any kind of JavaScript frameworks, other than when doing WebGL/WebGPU side projects, and then it is mostly Babylonjs.
Vue 3.6, for example, is incorporating a new signals rebuild that's several times faster and probably the fastest signals implementation out there[0]
Vue Vapor will also release in experimental mode in 3.6 and once it's mainstreamed, will probably also be among the fastest render models.
Both changes do not affect the DX and require no migrations, but will provide faster performance for ever more complex apps.
Basically, if I understand correctly, it's not "shiny" enough -- even though it is going to significantly improve signals performance.
V2 came out in 2016. The number of apps written before v2 is minuscule compared to even newer JS frameworks of today.
I would argue that Vue has been one of the most stable frameworks in JS world and that stability and focus on simplifying the state mental model (aka, it just works) has been the reason for Vue’s continued steady growth across organizations and projects of all sizes.
I do agree that Vue is clearly the better paradigm, but unfortunately it's still very much lagging behind React in terms of adoption. I think big breaking changes might have a considerable part in that, it's hard to sell that upwards.
I would put Vue on third place of FE JavaScript frameworks.
One big point that the post misses, is that the Class escape hatch for runes is incompatible with constructor-set parameters.
Say you have a class that wraps a HTMLElement which you set in the constructor. This doesn't work:
class Wrapper {
dom: HTMLElement = $state()
constructor(el: HTMLElement) {
this.dom = el
}
}
class Wrapper {
dom: HTMLElement
constructor(el: HTMLElement) {
let d = $state(el)
this.dom = d
}
}
class Wrapper {
constructor(el: HTMLElement) {
this.dom = $state(el)
}
}
class Wrapper extends Store {
@state() accessor dom: HTMLElement;
constructor(el: HTMLElement) { this.dom = el; }
}
I'm not saying Svelte 5 is flawless at all, but I think we found an approach that minimizes the downsides. The upside is really good performance and a metaframework that makes the most sense out of all the current options.
I think the generic is what you are looking for
class Wrapper {
dom = $state<HTMLElement>();
constructor(el: HTMLElement) {
this.dom = el;
}
}
let x = 10
<div>{x}</div>
x = 12
now the div changes.
It had its own unique, clean way of doing things and had its own identity.
Now they went down the route of looking like exactly like the others while doing everything much worse.
Of course a bunch of people keep telling me that yeah, this is much better. But they are brainwashed.
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.
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.
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.
It's not that i can't get used to them, it's that i just don't want to have to deal with them when they exist mainly because it made it easier to implement, not easier to use. It just gets the balance wrong for me. To each their own. I've met people who love them.
Some of these arguments resonate, some don't.
In the case of Svelte 5, it is (unfortunately) easier to understand if you look at the post-compiled code. Which often makes it totally obvious what is going on and what works or doesn't. Which is not great. It also often issues error messages that remind me of C++ 20 years ago in their unhelpfulness, before a lot of time was spent making the error message better. For example, I walked the tanstack folks through an example of generated code, because totally reasonable and smart people have trouble wrapping their head around what happens under the covers and what the error messages mean: https://github.com/TanStack/table/pull/5943
IMHO, trying to teach people this level of idiosyncrasy is a bit silly, and regardless of theoretical benefit, seems unlikely to work long term. It feels like there is not enough compiler help here to make it feel really magical, though at a glance it looks like their good be. I hope they adjust this.
I also agree the community is frustrating to deal with a not insignificant amount of time. There are lots of good people, mind you, but also lots of "you are holding it wrong", etc. I reported what is a blazingly clear bug (once you know it exists):
Svelte5 ships two incompatible Snippet types because of the use of unique symbols for SnippetReturn. Different unique symbols are never compatible in TS.
So these two SnippetReturn types (which are then used in the Snippet type in each file):
rg "SnippetReturn.*unique symbol"
types/index.d.ts
268: const SnippetReturn: unique symbol;
src/index.d.ts
271:declare const SnippetReturn: unique symbol
The error message you get if you trigger this is .. hilarious and hurts your brain (the two syntax highlighted types in this picture that look 100% identical are not compatible, one is from types/index.d.ts, one is from src/index.d.ts) - http://tiny.cc/wnkc001
I also reported a bug to the typescript folks about the error message.
The difference in how the triagers handled it were night and day. Amusingly, the svelte side has a bog simple and obvious fix - share the (typeof'd) unique symbol type between the two files so there are not two unique symbols. 5-10 line fix, at most. You just have to decide how much to share (IE just SnippetReturn or the whole Snippet type, or what). In the vast majority of projects i work on, someone would look at this, go "oh shit yeah we fucked that up whoops", fix it with the 10 line fix, and move on. There is absolutely zero reason or advantage to have the code like this. It is an obvious bug, it should be fixed, it's not worth a lot of time. But after many messages, I actually gave up on the svelte bug. To be fair i clearly got frustrated but man not a great experience ....
Compare to typescript - the typescript side requires work to issue a good error message here, and more thought.
Yet I'm in the midst of finishing a changelist on the typescript side to improve the compiler error message, because the experience dealing with the community was so much better.
Plenty of people I talk with have some story like this with Svelte :(
I will say, some of the other complaints here seem weird. SVAR grid works fine for tables. It supports variable heights and widths for columns. Maybe they specifically want unstyled tables? I dunno.
The usual ui complaint for svelte is not grid, but good tree components. They also pick a few things they admit are not unique to svelte, and exist in other popular frameworks. Seems like a weird shot
Also, complaining about file naming and "unpleasant code infection" is also weird.
The other arguments seem much stronger - the lawyer in me wants to yell "put your arguments in order of strength, and remove the weakest ones. Quality wins over volume, and most people are not going to read the whole thing". If i'm really trying to make an effective argument, i make short ones, not long ones. On HN i'll do longform because i don't care enough most of the time to spend the time editing to make it effective. But if i was really trying to be convincing i would make much shorter ones.
In any case, i think some of this is reasonable. But having spent lots of time with frameworks, i'll keep using Svelte5, but I do hope things improve. I feel like i'd spend the same amount of time with other idiosyncrasies if i moved to Solid.
Yes, when I posted this content on Reddit, someone immediately brought up "Svelte's reactivity doesn't exist at runtime" to refute me, which isn't even a valid argument in Svelte 5. https://www.reddit.com/r/sveltejs/comments/1j6ayaf/comment/m...
> put your arguments in order of strength, and remove the weakest ones. Quality wins over volume, and most people are not going to read the whole thing
I did remove some of them, such as the issue of "data ownership," which is the first time I've heard this term outside of Rust's web framework, but it was just a warning, not a blocking issue, so I deleted it. https://svelte.dev/docs/svelte/runtime-warnings#Client-warni...
> In any case, i think some of this is reasonable. But having spent lots of time with frameworks, i'll keep using Svelte5, but I do hope things improve. I feel like i'd spend the same amount of time with other idiosyncrasies if i moved to Solid.
Yes, the current project has been underway for 3 months, and I won't replace the entire web framework now, but I will definitely consider whether there are better options for the next project.