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.)
LOL
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…
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>
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.
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.
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.
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;
}
}
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.
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.
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.
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.
Well that's just development right there! Sucking for a long period of time is 'The Way', the path to greatness, which devs (IMHO) over-rely on LLM to shortcut.
However I get your point. lol
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.
> 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'm an experienced React dev and thought I'd try something new for a side project. I tried and liked SolidJS (and agree with a lot of the positive comments here) and Ryan seems super knowledgeably about everything front end. (It was a close second).
However I wanted to give Sveltekit a shot as it's so different to React (and SolidJS is not).
For me it seems to put me back to those good olde days (insert rose tinted glasses and violin music), where web dev was just html, css and js/jquery (yes, it was hard for it not to turn into spaghetti). However I coded like I was being chased by demons and loved every minute of it.
I don't get that with React. Having to fix stupid race conditions and constant rendering glitches gets to become grating.
Sveltekit (with it's signals approach, like SolidJS) sort of puts me back there. It's all just html, css (or tailwind), simple js and event driven.
You set up some state at the top <script> block and have loaders/actions (superforms is great) in external files. To me it all seems super intuitive.