It's worth pointing out this article is discussing Svelte 3.x when the current version is Svelte 5.x and has some significant departures from previous versions (i.e. the introduction of runes)
I haven't finished reading the article yet. I am a fan of Svelte, though, and have switched to using it by default for new projects - coming from a React background.
I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.
Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.
The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.
I'm no longer a fan of using any front-end libraries at all en lieu of just using standard event listeners and web components, but in their defense, by the time that you're creating or updating that many elements, most developers are backing out of the framework anyway.
It's the primary reason virtual table libraries exist.
Did Svelte gain the adoption like React and Vue ? I am not sure how mature the ecosystem is. I am always wary of using things in production that have not gained significant adoption.
At least anecdotally I see job listings mostly for React, with some for Vue and Angular, with almost no Svelte. I think I did see one company mention Svelte, so at least someone is building on it, but to a much lesser degree than any of the major players.
I love Svelte. When I first used it, it was like using a framework for the first time: Wow, everything is namespaced to the component, even CSS! Wow, just putting $ in front makes it update automatically! etc, etc
> Because WebAssembly modules lack direct access to the DOM, they rely on an additional JavaScript interoperability layer, which can introduce extra overhead.
The fact this is already outdated by more recent Svelte releases which changed things drastically is exactly my problem with the modern JS space. So fast moving and most of it is still doing JQuery like reactivity.
I am probably just not smart enough to get it, but it reminds me of the constant seemingly pointless rewrites I see in companies. Figure out what works and keep it, is that so hard? Why can other languages do that. Is this just the nature of web dev?
> Figure out what works and keep it, is that so hard?
Well, short answer is that it's been in the "figure out what works" phase for many years now. The developer experience has improved a lot over the years, but it's at the expense of constant breaking changes and dependency hell if you want to upgrade existing code.
My VanillaTS project has been working well for the last six years. The most painful part was when I moved everything to esbuild w/ async imports (and ES2017 modules) but now I don't even think about it. npm audit gets kinda mad though.
If you write your stuff in a web framework, the rewrites aren't pointless. Well, they are, of course, but you can't really avoid them, because the old stuff stops getting updates within a year, so you either rewrite or can't update the framework, security updates included.
Made me just give up on web development.
I think React has an at least somewhat reasonable track record in terms of backwards compatibility? Still not perfect but much better than all the other frameworks.
Tbf, the versions used in this are all roughly 5 yrs old.
And svelte was pretty new at that time, hence it would make sense that it was figuring stuff out, I think.
Though angular has gone through multiple concepts during this time between version 11 (as used in this article) and the current 20 - and especially signals and zoneless would have also massively impacted performance.
The core technology behind Svelte remains the same, and the performance results are still valid. There is no code or feature comparison happening here, so I don't see how this is relevant to the article. Before Svelte 5, it has been by far the most stable framework of the big four.
> Figure out what works and keep it, is that so hard?
Yes, very. Perfect design upfront can eliminate the need to change it later, but you never get it perfect, so you continue to "figure it out" for many years with many failed attempts in the process.
Every Svelte enthusiast I have spoken to tends to lean towards the esoteric Elm and other such technologies.
They don’t really understand that software isn’t about “my framework can render 1000 elements 500ms faster” but rather my organization of hundreds or thousands of front end engineers (mix of employees and contractors both of whom usually don’t give a fuck) across the WORLD need to be able to work together on a significant product and ship constantly without breaking things.
And customers don’t give a fuck otherwise they wouldn’t be paying six figures or more for literally shit software.
That said I have tried it a couple times over the years. Not sure I like the latest direction they’ve gone though.
Svelte is definitely still my favorite way to build web apps in 2025.
I wasn't (and still am not) the biggest fan of the new Runes syntax, but I've gotten used to it, and it doesn't really hurt my productivity or get in my way that much.
There's definitely an ecosystem gap compared to React, but there are still lots of really good components and frameworks out there. For example, there's a native Svelte version of IBM's Carbon Design[1] which I've used and found to be very high-quality.
And as for arguments that React will keep winning due to LLMs not having enough corpus to learn less-popular frameworks, I've anecdotally had good success with using LLMs to edit and generate Svelte code. There are occasionally some issues (like it generating pre-runes syntax or using deprecated stuff like stores) but it works well enough to be useful, and definitely better than I expected.
It's that fast because it uses a declarative model and this ends up being very efficient for a variety of use-cases
(I say this speaking from a NixOS laptop; Nix operations are invariably much faster than alternatives, like Docker, assuming you have the technical chops to get them to work)
React also uses a declarative model, in fact React might be more declarative because it's still declarative at runtime, whereas Svelte et al. do a lot of static analysis to turn declarative UI into imperative targeted dom updates.
Good point. I guess Svelte then takes advantage of both models; a declarative content change might by default result in a large update but the diff is ultimately the only thing that gets applied imperatively; I'm not sure how else React would do it though since the only natively-declarative browser technology is HTML and CSS; as soon as you touch JS, things start being imperative
It's just a new way of using reactive vars, which you have to get used to a bit, and which people that don't like change are annoyed about. But it's ultimately a more consistent and flexible way which actually makes a lot of sense once you're used to it.
I was struggling with this too - maybe it means that at compile time, it just flags those nodes in the tree that might become dirty due to state changes, and ignores the rest.
Svelte version 3 used to statically analyze at compile time which things could change which things and it would build a "direct" reactivity system from that. So kinda both compile time and runtime.
But Svelte 5 changed to use a signals based approach just like Vue and Solidjs, which is runtime based and more flexible. Svelte chose to add some compile time syntax sprinkles on top that they call "runes", because they like a simpler syntax. But signals are fundamentally a runtime concept.
As someone who has been doing frontend dev since "AJAX" was the hot new stuff...
I am deeply, deeply disappointed in the field. It simultaneously has an extremely high rate of churn and an extremely low rate of actual innovation.
After observing the discipline for nearly two decades, I am concluding that almost all the "progress" really starts to look like we're just rearranging the furniture endlessly without substantive improvements in developer velocity or end user experience.
Any given "progress" looks reasonable for a moment but is ultimately circular. We've been playing rock/paper/scissors with "better" techniques for a long time now.
I'm on a project now that requires using Svelte in an enterprise setting. I've used all the big 3 (Angular, React, Vue) and then some (Ember, AngularJS) and I can say without a doubt, Svelte is my least favorite of them all by far. To say it has encouraged designing an unreadable mess in the code-base is an understatement. It seems to have taken the worst aspects of the big 3 and ran with it. I'm utterly confused why people enjoy this wild west hodgepodge of framework mistakes. I'd argue the improved speed is not worth sacrificing readability and lower cognitive load. This is designed for tinkerers and hobbyists. I say this with confidence of nearly 20 years experience building enterprise web applications (including in FAANG): Svelte is another fad library that has no place in a professional setting.
48 comments
[ 2.7 ms ] story [ 57.6 ms ] threadObligatory: sad state of web where React is so popular.
I haven't finished reading the article yet. I am a fan of Svelte, though, and have switched to using it by default for new projects - coming from a React background.
Angular has OnPush change detection strategy and can even be free of zone.js now, so this isn't necessarily true.
Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.
The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.
It's the primary reason virtual table libraries exist.
Blazor is slow for other reasons. You can make wasm web frameworks fast (see leptos and dioxus). It can be as fast as vanilla js. Sledgehammer on this benchmark is wasm: https://krausest.github.io/js-framework-benchmark/2023/table...
I am probably just not smart enough to get it, but it reminds me of the constant seemingly pointless rewrites I see in companies. Figure out what works and keep it, is that so hard? Why can other languages do that. Is this just the nature of web dev?
Well, short answer is that it's been in the "figure out what works" phase for many years now. The developer experience has improved a lot over the years, but it's at the expense of constant breaking changes and dependency hell if you want to upgrade existing code.
Vue 3.4 (2023) rewrote their template rendering engine to be 2x as fast as well.
Made me just give up on web development.
I think React has an at least somewhat reasonable track record in terms of backwards compatibility? Still not perfect but much better than all the other frameworks.
And svelte was pretty new at that time, hence it would make sense that it was figuring stuff out, I think.
Though angular has gone through multiple concepts during this time between version 11 (as used in this article) and the current 20 - and especially signals and zoneless would have also massively impacted performance.
Yes, very. Perfect design upfront can eliminate the need to change it later, but you never get it perfect, so you continue to "figure it out" for many years with many failed attempts in the process.
They don’t really understand that software isn’t about “my framework can render 1000 elements 500ms faster” but rather my organization of hundreds or thousands of front end engineers (mix of employees and contractors both of whom usually don’t give a fuck) across the WORLD need to be able to work together on a significant product and ship constantly without breaking things.
And customers don’t give a fuck otherwise they wouldn’t be paying six figures or more for literally shit software.
That said I have tried it a couple times over the years. Not sure I like the latest direction they’ve gone though.
(2022 paper https://helda.helsinki.fi/server/api/core/bitstreams/a301a02...)
I wasn't (and still am not) the biggest fan of the new Runes syntax, but I've gotten used to it, and it doesn't really hurt my productivity or get in my way that much.
There's definitely an ecosystem gap compared to React, but there are still lots of really good components and frameworks out there. For example, there's a native Svelte version of IBM's Carbon Design[1] which I've used and found to be very high-quality.
And as for arguments that React will keep winning due to LLMs not having enough corpus to learn less-popular frameworks, I've anecdotally had good success with using LLMs to edit and generate Svelte code. There are occasionally some issues (like it generating pre-runes syntax or using deprecated stuff like stores) but it works well enough to be useful, and definitely better than I expected.
[1] https://svelte.carbondesignsystem.com/
(I say this speaking from a NixOS laptop; Nix operations are invariably much faster than alternatives, like Docker, assuming you have the technical chops to get them to work)
Also the article is commenting on this other article from 2022 which is severely outdated by now.
https://journals.riverpublishers.com/index.php/JWE/article/v...
Also no Solid.js?
> This requires the framework to track which components are dirty. Vue does this at runtime, Svelte handles it at compile time.
How can it possibly track this at compile time? Best I could see if tracking where those bits could be set, but not actually setting them.
But Svelte 5 changed to use a signals based approach just like Vue and Solidjs, which is runtime based and more flexible. Svelte chose to add some compile time syntax sprinkles on top that they call "runes", because they like a simpler syntax. But signals are fundamentally a runtime concept.
I am deeply, deeply disappointed in the field. It simultaneously has an extremely high rate of churn and an extremely low rate of actual innovation.
After observing the discipline for nearly two decades, I am concluding that almost all the "progress" really starts to look like we're just rearranging the furniture endlessly without substantive improvements in developer velocity or end user experience.
Any given "progress" looks reasonable for a moment but is ultimately circular. We've been playing rock/paper/scissors with "better" techniques for a long time now.