As somebody using Svelte for a real production application, I can only 100% agree with their recommendations regarding Svelte because of the overall dev experience is unmatched. It just feels right. Easy. Simple. And I'm not even considering performance here as another benefit.
I usually make the analogy of a video game, where you can pick the difficulty. Svelte/SvelteKit is working in the "easy" difficulty level. You can achieve the same end result and keep your sanity (and your hair).
Ugh. That thinking is what gets you things like mandatory login via apps for your desktop. And not every application makes sense on a phone. And some Web Applications just require low latency high bandwidth internet to work properly.
(I'll be that guy since the article emphasizes a good mobile web experience so hard)
You might want to fix your horizontal scroll on mobile. I should basically never have a full page horizontal scrollbar on a page that is mostly just text.
All of them can, but you get most benefit of a full-stack javascript framework if you are indeed running server js. But you can build statically in any of them (assuming you are not using any server-only features) and deploy as plain html/js.
Ignoring the content of the post for a second (which IMO was excellent), the quality of the writing here is remarkable. This is a dry technical topic at heart and yet i enjoyed reading that entire report. It was as informative as i could hope for whilst still being engaging.
It’s 10,000 words and a curious mixture of dense and sparse. There’s quite a bit of duplication (especially of figures), a fair bit of circumlocution in the narrative sections, and a lot of meaninglessly precise figures, half of which should have been omitted altogether. I am confident it could be significantly improved by a hard cap of 5,000 words, and suspect even 2,000 words could still be better (though 1,000 would definitely be too short to convey it all). Even apart from that, it definitely needed a table of contents, to set expectations.
As a general challenge to people: write your article, then see if you can halve its length without losing much. If it felt too easy, repeat the process! There’s a family of well-known quotes that amount to “sorry for writing a long letter, I didn’t have time to write a short letter”. Concise expression is not the easiest, but very valuable. Many a 100-page technical book can be improved by reduction to a one-page non-prose overview/cheat sheet (perhaps using diagrams and tables, but consider going more freeform like you might on a whiteboard) plus a ten page abridged version.
Thanks for posting, a lot of effort went into that and I think the quality shines through in the write up.
I write pretty lean HTML/vanilla JS apps on the front end & C#/SQL on the backend; and have had great customer success on mobiles with a focus on a lot of the metrics the author hammers home.
I am the only one shocked that no comparison or test or thinking of native development? Web dev are this closed to other languages? I came here for this kind of comparison because of the article. headline
Interesting to see Marko and Solid topping the performance metrics. Ryan Carniato* was a core team member of Marko and started Solid. I wouldn't be surprised if SolidStart can eventually lower its bundle size further.
The article is a bit disappointing in that it focuses too much on bundle size. Bundle size is important for sure, especially in rural areas with poor mobile signal, but time-to-interactive is imho more important, and that's where resumable frameworks like qwik and marko6 shine
Solid is great for raw rendering speed, but it hydrates just like react (unless you use an islands framework on top like astro which has its own limitations), while qwik and marko are resumable out of the box
> This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence, complex state management, and the kind of interactions you’d actually build for a real product.
Can you also tell ChatGPT to fix the layout so the table just above this message is fully visible without horizontal scrolling?
Comparing something like next.js to other frameworks doesn’t make much sense anymore given that most webdevs choose DX and easy deployment above anything else. Vercel’s growth is proof of that.
I prefer to use whatever I'm more comfortable with than something that is measurably the fastest horse in the stable. Trading dev time, skill and comfort for few kb of memory and few ms of speed seems pointless to me.
By the way, my "horse" of choice is Quasar(based on Vue) and has been for years now.
In our small firm, we did a review of the usual suspects when deciding which of the big players would be the right horse to bet on for the future when planing to rewrite our core application.
We ended up with Vue vs. Svelte and landed on Vue/Nuxt since we agreed they have the most intuitive syntax for us, and it seemed like the one with the best trajectory, technologically speaking.
That was one year ago. It's not moving as fast as I would hope, but I still think Vue/Nuxt is a better choice than React at least. This article seems to support this somewhat.
Also, I did a review (with the help of all the big LLMs), and they seem to agree that Vue has the syntax and patterns that are best suited for agentic coding assistance.
The wins with regards to "First Contentful Paint" and "size" is not the most important. We just trust the Vue community more. React seems like a recipe for a bloated bureaucratic mess. Svelte still looks like a strong contender, but we liked the core team of Vue a lot, and most of us just enjoy Vue/Nuxt syntax/patterns better.
This is great write up. I especially appreciate the focus on mobile, because I find it's often overlooked, even though it's dominant device to access the web. The reality of phones is brutal and delivering a good experience for most users in SPA-style archictecture is pretty hard.
"Slowness poisons everything."
Exactly. There's nothing more revealing than seeing your users struggle to use your system, waiting for the content to load, rage clicking while waiting for buttons to react, waiting for the animations to deliver 3 frames in 5 seconds.
Engineering for P75 or P90 device takes a lot of effort, way beyond what frameworks offer you by default. I hope we'll see some more focus on this from the framework side, because I often feel like I have to fight the framework to get decent results - even for something like Vue, which looks pretty great in this comparison.
150kb downloads almost instantly, even on 3G. Most websites have an image bigger than that somewhere on their homepage. It's not worth changing how I work.
I particularly like that (JSX aside) it's just JavaScript, not a separate language with its own compiler like Svelte (and by the sounds of it Marko, which I hadn't heard of before). You can split your app into JS modules, and those can all use Solid signals, even the internal bits that don't have their own UI.
This is a really good article. It’s not my bailiwick, but it must be extremely useful for folks that work in this space.
> When someone’s standing in front of a potential buyer trying to look professional, a slow-loading app isn’t just an annoyance. It’s a liability.
I liked reading that. It’s actually surprising how few developers think that way.
> Mobile is the web
That’s why.
I know many people that don’t own a computer, at all, but have large, expensive phones. This means that I can’t count on a large PC display, but I also can reasonably expect a decent-sized smaller screen.
I’ve learned to make sure that my apps and sites work well on high-quality small screens (which is different from working on really small screens).
The main caveat, is the quality of the network connection. I find that I need to work OK, if the connection is dicey.
Before starting new projects I would always do research like this and try new things. But I’ve stopped looking at what is out there. I have landed on Django/React(vite). I have mastered this and can go from idea to app running in production in a matter of hours. I know there are better, faster, and more modern alternatives. But I just don’t care anymore. Maybe I’m just web framework jaded. I rather learn something else than look through the docs of yet another web framework.
This is a great comparison, but it depends so much on what sort of website or web app you are building. If you are building a content site, with the majority of visitors arriving without a hot cache bundle size is obviously massively important. But for a web app, with users regularly visiting, it's somewhat less important.
As ever on mobile it's latency, not bandwidth, that's the issue. You can very happily transfer a lot of data, but if that network is in your interactive hot path then you will always have a significant delay.
You should optimise to use the available bandwidth to solve the latency issues, after FCP. Preload as much data as possible such that navigations are instant.
71 comments
[ 3.4 ms ] story [ 85.2 ms ] threadI usually make the analogy of a video game, where you can pick the difficulty. Svelte/SvelteKit is working in the "easy" difficulty level. You can achieve the same end result and keep your sanity (and your hair).
Ugh. That thinking is what gets you things like mandatory login via apps for your desktop. And not every application makes sense on a phone. And some Web Applications just require low latency high bandwidth internet to work properly.
I'm not overly familiar with it, but we use it at work. I've no idea if I should expect it to be quicker or slower than something like Next.
You might want to fix your horizontal scroll on mobile. I should basically never have a full page horizontal scrollbar on a page that is mostly just text.
What a joy to read.
As a general challenge to people: write your article, then see if you can halve its length without losing much. If it felt too easy, repeat the process! There’s a family of well-known quotes that amount to “sorry for writing a long letter, I didn’t have time to write a short letter”. Concise expression is not the easiest, but very valuable. Many a 100-page technical book can be improved by reduction to a one-page non-prose overview/cheat sheet (perhaps using diagrams and tables, but consider going more freeform like you might on a whiteboard) plus a ten page abridged version.
I write pretty lean HTML/vanilla JS apps on the front end & C#/SQL on the backend; and have had great customer success on mobiles with a focus on a lot of the metrics the author hammers home.
*) https://github.com/ryansolid
Solid is great for raw rendering speed, but it hydrates just like react (unless you use an islands framework on top like astro which has its own limitations), while qwik and marko are resumable out of the box
Can you also tell ChatGPT to fix the layout so the table just above this message is fully visible without horizontal scrolling?
By the way, my "horse" of choice is Quasar(based on Vue) and has been for years now.
We ended up with Vue vs. Svelte and landed on Vue/Nuxt since we agreed they have the most intuitive syntax for us, and it seemed like the one with the best trajectory, technologically speaking.
That was one year ago. It's not moving as fast as I would hope, but I still think Vue/Nuxt is a better choice than React at least. This article seems to support this somewhat.
Also, I did a review (with the help of all the big LLMs), and they seem to agree that Vue has the syntax and patterns that are best suited for agentic coding assistance.
The wins with regards to "First Contentful Paint" and "size" is not the most important. We just trust the Vue community more. React seems like a recipe for a bloated bureaucratic mess. Svelte still looks like a strong contender, but we liked the core team of Vue a lot, and most of us just enjoy Vue/Nuxt syntax/patterns better.
"Slowness poisons everything."
Exactly. There's nothing more revealing than seeing your users struggle to use your system, waiting for the content to load, rage clicking while waiting for buttons to react, waiting for the animations to deliver 3 frames in 5 seconds.
Engineering for P75 or P90 device takes a lot of effort, way beyond what frameworks offer you by default. I hope we'll see some more focus on this from the framework side, because I often feel like I have to fight the framework to get decent results - even for something like Vue, which looks pretty great in this comparison.
I particularly like that (JSX aside) it's just JavaScript, not a separate language with its own compiler like Svelte (and by the sounds of it Marko, which I hadn't heard of before). You can split your app into JS modules, and those can all use Solid signals, even the internal bits that don't have their own UI.
> When someone’s standing in front of a potential buyer trying to look professional, a slow-loading app isn’t just an annoyance. It’s a liability.
I liked reading that. It’s actually surprising how few developers think that way.
> Mobile is the web
That’s why.
I know many people that don’t own a computer, at all, but have large, expensive phones. This means that I can’t count on a large PC display, but I also can reasonably expect a decent-sized smaller screen.
I’ve learned to make sure that my apps and sites work well on high-quality small screens (which is different from working on really small screens).
The main caveat, is the quality of the network connection. I find that I need to work OK, if the connection is dicey.
> This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence (appears twice)
this article was written by ChatGPT. I'm tired
As ever on mobile it's latency, not bandwidth, that's the issue. You can very happily transfer a lot of data, but if that network is in your interactive hot path then you will always have a significant delay.
You should optimise to use the available bandwidth to solve the latency issues, after FCP. Preload as much data as possible such that navigations are instant.