> 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?
The user who posted that also post this thread's link yesterday, as well as many others. The account seems to be karma farming with AI-generated articles.
>> Marko delivers 12.6 kB raw (6.8 kB compressed). Next.js ships 497.8 kB raw (154.5 kB compressed). That’s a 39x difference in raw size that translates to real seconds on cellular networks.
Sorry, it isn't 2006, cellular networks aren't spending "seconds" in the difference between 13kB and 500kB.
Payload size can matter, but it's complete nonsense that 500kB would translate to "real seconds".
Just spotted this section:
>> The real-world cost: A 113 kB difference at 3G speeds (750 kbps) means 1.2 seconds for download plus 500ms to 1s for parse/execution on mobile CPUs. Total: 1.5 to 2 seconds slower between frameworks.
3G is literally being decommissioned, and 3G isn't 750kbps, it's significantly faster than that.
> On first glance it seems very legit
Yes, that's exactly the danger of AI slop. It's very plausible, very slick and very easy to digest. It also frequently contains unchecked errors without any strong signals that would traditionally go along with that.
In the summary at the top they also use a different smallest compressed size: "The real differentiator? Bundle sizes range from 28.8 kB to 176.3 kB compressed."
That's why I stopped reading at your first quote, it didn't fit with the summary and there's no point reading a bunch of numbers and wondering which are made up.
It's a tell, a common language quirk of LLMs especially ChatGPT.
- a slow-loading app isn’t just an annoyance. It’s a liability.
- The real performance story isn’t splitting hairs over 3ms differences, it’s the massive gap between next-gen and React/Angular
- The difference [...] isn’t academic. It’s the difference between an app that feels professional and one that makes our users look bad in front of clients.
- This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence.
- This isn’t just an inconvenience. It’s technofeudalism.
- “We only know React” isn’t a technical constraint, it’s a learning investment decision.
- The real difficulty isn’t learning curve, it’s creating a engineering culture.
- This isn’t some toy todo list. It’s a solid mid-complexity app with real database persistence using SQLite.
- The App Store isn’t a marketplace, it’s a fiefdom.
For better or worse, this type of writing (and coding, and ...) is here to stay.
We can dismiss it on the basis of "slop", but that would be throwing out the baby with the bath water. The reality is that pretty much everyone will rely on these tools, and it would be more beneficial for the audience to discern good content vs bad content, over whether it was machine-generated or not.
In fact, playing devil's advocate, it may have some benefits as well. For many people the content might not be in their first language, so the tools help with improving grammar, fixing typos, etc. They're the same assistive writing tools we've had for decades, but far, far, better. This makes the content much clearer and easier to read. The style of the content can always be changed in seconds, so if a certain cadence bothers the author, that can be easily changed. And, personally, I enjoy the privacy aspect. It's long been possible to identify the author of written text simply by their language, style, etc. These tools can make this more difficult, preserving the anonimity of the author. Or they can mimic the author's style, if instructed to do so. These are all powerful features.
To be clear: I can't stand "AI slop" either. I don't like that it replaces the humanity and personality of the author with something that tries to mimic it. But we should learn to accept it and see beyond it.
So the main question is: is the content of this article worthless? Or is it worth reading despite of it being machine-generated?
Hell, if it bothers you that much, ask your favorite LLM to summarize it for you, or rewrite it in any style you like. :)
At best it's merely robbing the author of their voice.
At worst, it's slowly nudging us all towards a future where the machine is a constant discriminator in our lives. A future where adherence to LLM-style becomes mandatory for effective communication. A future where LLMs can invisibly steer us without our realising.
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.
A big advantage with Vue is also that it has options and composition API, so if one feels janky you can still try the other.
I've tried moving away from Vue just to test some other frameworks but none have given me such an easy way to manage state, reactivity, modularity... I always come back to it.
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.
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.
> 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've been there myself as a Dev and later on as a manager. You have to really watch out not getting locked into local minima here. In most cases its not bundle size that wins this but engineering an app that can gracefully work offline, either by having the user manually pre-load data or by falling back to good caches.
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.
To be honest, as long as your app isn’t doing something crazy complex, it’s going to be fast enough for most people even on the slowest stack. I wouldn’t worry about it, personal efficiency is way more important most of the time I’d say.
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).
I've been using Svelte's custom elements (web components) to make components that slot into pages on an existing .net / alpine.js site. It's been a great dev experience and results in really portable components. Each component is it's own bundle (achieved via separate vite configs - you can also organise to bundle groups of components work together). Each of the tools in the tools section is a svelte custom element https://www.appsoftware.com/tools/utilities/calculators
I would choose vue because you can still get paid for it but react is king by jobs. If you're playing in the hobby space then between liveview, datastar etc, there is plenty of cool stuff moving the needle. React is nice and simple IMHO which is why average devs like me enjoy it.
Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?
I think this is the reason why React feels normal to you. But as someone coming into it fresh, React felt like there were always 4 different ways to do the same thing and 3 of them are wrong because they built a new API/there are more idiomatic ways to accomplish the same thing now. If you have a decade of experience, then you probably do most things the right/obvious way so don't even notice all the incorrect ways/footguns that React gives you.
If you're coming into it in 2025, it's even simpler. Just ignore the SSR stuff which Vercel are pushing and you're good. A lot of the path has been smoothed out over the years to make it an ideal place to start today.
I feel like the introduction of React Compiler was a pretty big change, too?
The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
To be fair, I haven't written in React for a few years now. I reached for Svelte with the last two apps I built after using React professionally for 4 years. I was expecting there to be a learning curve and there just... wasn't? It was staggering how little I had to think about. Even something as small as not having to write in JSX (however normalized I was to writing in it) really felt meaningful once I took a step back and saw the forest for the trees.
I dunno. I just remember being on the interview circuit and asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used, how something like console.log would fair in relation to them, when to include/exclude arguments from memoization arrays, etc.. and it was pretty easy to trip a lot of people up. I think the introduction of the compiler is an attempt to mitigate a lot of those pains, but newer frameworks designed with those headaches in mind from the start rather than mitigating much later and you can feel it.
I rolled my eyes when hooks came out and never used it again besides for work, so not really. All the frameworks on the planet and facebook is still a heaping pile of dog shit. I was spoiled by Vue's lifecycle methods and then Svelte and it was impossible to go back.
Maybe hooks are cool but the same code written in react vs vue vs svelte or something else is always easier on the eyes and more readable. Dependency arrays and stale closures are super annoying.
Sorry but I really hate React. I've dealt with way too many shit codebases. Meanwhile working in vue/svelte is a garden of roses even if written by raw juniors.
> when I built the first implementations and started measuring, something became clear: the issues I was seeing with Next.js weren’t specific to Next.js. They were fundamental to React’s architecture.
So here some obscure Next.js issues magically become fundamental React architecture issues. What are these? Skill issues?
I believe the biggest performance hit lives in je inability to force reload a cached file with js (or even html(!)).
Setting a header only works if you know exactly when you are going to update the file. Except from highly dynamic or sensitive things this is never correct.
You can add ?v=2 to each and every instance of an url on your website. Then you update all pages which is preposterous and exactly what we didn't want. As a bonus ?v=1 is not erased which might also be just what you didn't want.
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.
This isn't just poor writing, it's ChatGPT-padded slop.
But the same is true for the content itself, no business is paying you to actually build the same app 10x, especially so if it's something as trivial as a kanban board.
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.
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
It's not about being closed to other languages, it's about being economically pragmatic in many, many cases.
As shown in the article, you can build ONCE an app that loads in milliseconds by just providing an url to any potential customer. It works on mobile and on desktop, on any operating system.
The native alternative requires:
- Multiple development for any platform you target (to be widely used you need *at least* ios, android, macOS and windows.)
- Customers are required to download and install something before using your platform, creating additional friction.
And all of this to obtain at most 20-30ms better loading times?
There are plenty of cases where native makes sense and is necessary, but most apps have very little to gain at the cost of a massive increase in development resources.
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.
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.
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.
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.
JS can be 100x or even 1000x times more expensive to process than images. JS also blocks the main thread, while images can be processed in the background (and on GPU).
Your attitude is exactly why our supercomputers struggle to display even the simplest things with any kind of performance, and why pure text takes multiple seconds to appear
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.
The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.
(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.
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.
> some Web Applications just require low latency high bandwidth internet to work properly.
But the vast majority do not. And this haranguing is an opportunity / defensible position to put more efforts and resources into performances. If nothing else, think of it as a Trojan horse to make software suck less.
>If nothing else, think of it as a Trojan horse to make software suck less.
My experience has been that the proliferation of mobile devices has made my desktop experience consistently worse and I struggle to come up with an example where it didn't.
Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.
> 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?
Also
> This isn’t just an inconvenience. It’s technofeudalism.
There are so many of these in the article. It's like a spit to the face
Come full circle by feeding the article back to your favorite LLM and ask it to TL;DR it for you.
Yeah the writing is obvious ChatGPT-slop sadly.
Edit: Related post on the front page: https://news.ycombinator.com/item?id=45722069
The user who posted that also post this thread's link yesterday, as well as many others. The account seems to be karma farming with AI-generated articles.
https://news.ycombinator.com/item?id=45724022
Can you guys share actual errors in the article, that indicate real slop?
On first glance it seems very legit and personally I would be very hesistant judging something GPT slop based on some writing style.
How about this?
>> Marko delivers 12.6 kB raw (6.8 kB compressed). Next.js ships 497.8 kB raw (154.5 kB compressed). That’s a 39x difference in raw size that translates to real seconds on cellular networks.
Sorry, it isn't 2006, cellular networks aren't spending "seconds" in the difference between 13kB and 500kB.
Payload size can matter, but it's complete nonsense that 500kB would translate to "real seconds".
Just spotted this section:
>> The real-world cost: A 113 kB difference at 3G speeds (750 kbps) means 1.2 seconds for download plus 500ms to 1s for parse/execution on mobile CPUs. Total: 1.5 to 2 seconds slower between frameworks.
3G is literally being decommissioned, and 3G isn't 750kbps, it's significantly faster than that.
> On first glance it seems very legit
Yes, that's exactly the danger of AI slop. It's very plausible, very slick and very easy to digest. It also frequently contains unchecked errors without any strong signals that would traditionally go along with that.
In the summary at the top they also use a different smallest compressed size: "The real differentiator? Bundle sizes range from 28.8 kB to 176.3 kB compressed."
That's why I stopped reading at your first quote, it didn't fit with the summary and there's no point reading a bunch of numbers and wondering which are made up.
[flagged]
English is not my native language, and I fail to understand what you mean. What's wrong, or even special, about the sentence you're quoting?
It's a tell, a common language quirk of LLMs especially ChatGPT.
- a slow-loading app isn’t just an annoyance. It’s a liability. - The real performance story isn’t splitting hairs over 3ms differences, it’s the massive gap between next-gen and React/Angular - The difference [...] isn’t academic. It’s the difference between an app that feels professional and one that makes our users look bad in front of clients. - This isn’t a todo list with hardcoded arrays. It’s a real app with database persistence. - This isn’t just an inconvenience. It’s technofeudalism. - “We only know React” isn’t a technical constraint, it’s a learning investment decision. - The real difficulty isn’t learning curve, it’s creating a engineering culture. - This isn’t some toy todo list. It’s a solid mid-complexity app with real database persistence using SQLite. - The App Store isn’t a marketplace, it’s a fiefdom.
That sentence structure is something that LLMs seem to have converged on, so the comment you're replying to thinks this article is written by an LLM.
For better or worse, this type of writing (and coding, and ...) is here to stay.
We can dismiss it on the basis of "slop", but that would be throwing out the baby with the bath water. The reality is that pretty much everyone will rely on these tools, and it would be more beneficial for the audience to discern good content vs bad content, over whether it was machine-generated or not.
In fact, playing devil's advocate, it may have some benefits as well. For many people the content might not be in their first language, so the tools help with improving grammar, fixing typos, etc. They're the same assistive writing tools we've had for decades, but far, far, better. This makes the content much clearer and easier to read. The style of the content can always be changed in seconds, so if a certain cadence bothers the author, that can be easily changed. And, personally, I enjoy the privacy aspect. It's long been possible to identify the author of written text simply by their language, style, etc. These tools can make this more difficult, preserving the anonimity of the author. Or they can mimic the author's style, if instructed to do so. These are all powerful features.
To be clear: I can't stand "AI slop" either. I don't like that it replaces the humanity and personality of the author with something that tries to mimic it. But we should learn to accept it and see beyond it.
So the main question is: is the content of this article worthless? Or is it worth reading despite of it being machine-generated?
Hell, if it bothers you that much, ask your favorite LLM to summarize it for you, or rewrite it in any style you like. :)
At best it's merely robbing the author of their voice.
At worst, it's slowly nudging us all towards a future where the machine is a constant discriminator in our lives. A future where adherence to LLM-style becomes mandatory for effective communication. A future where LLMs can invisibly steer us without our realising.
[flagged]
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.
A big advantage with Vue is also that it has options and composition API, so if one feels janky you can still try the other. I've tried moving away from Vue just to test some other frameworks but none have given me such an easy way to manage state, reactivity, modularity... I always come back to it.
vue is better, the problem is it's been dead for more than 3 years now.
What do you mean? Vue is perfectly capable and mature
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.
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.
> 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've been there myself as a Dev and later on as a manager. You have to really watch out not getting locked into local minima here. In most cases its not bundle size that wins this but engineering an app that can gracefully work offline, either by having the user manually pre-load data or by falling back to good caches.
> good caches
Some of the most challenging code that I write, is about caches.
Writing good cache support is hard.
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.
To be honest, as long as your app isn’t doing something crazy complex, it’s going to be fast enough for most people even on the slowest stack. I wouldn’t worry about it, personal efficiency is way more important most of the time I’d say.
I’ll speak for you:
You’ve stopped caring because it. never. ends. Really.
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).
I've been using Svelte's custom elements (web components) to make components that slot into pages on an existing .net / alpine.js site. It's been a great dev experience and results in really portable components. Each component is it's own bundle (achieved via separate vite configs - you can also organise to bundle groups of components work together). Each of the tools in the tools section is a svelte custom element https://www.appsoftware.com/tools/utilities/calculators
Can we build the elements as part of light dom? Do they call their destructor when we navigate away?
I will keep using Next.js, because that is what SaaS vendors support on their extension SDKs, and I have better things to do than build an ecosystem.
Alternatives are great for those without these kinds of constraints.
In which case, I rather use traditional Java and .NET frameworks with minimal JavaScript, if at all.
How do you deal with the horrendously slow on-the-fly compile times in dev mode?
I wonder how anyone gets any work done when they have to wait 10 seconds on every page load on a M3 Macbook Air
I would choose vue because you can still get paid for it but react is king by jobs. If you're playing in the hobby space then between liveview, datastar etc, there is plenty of cool stuff moving the needle. React is nice and simple IMHO which is why average devs like me enjoy it.
>React is nice and simple IMHO which is why average devs like me enjoy it.
Maybe years ago. Now it's a bloated beast.
Can you give some examples? I feel like React is still pretty much just React, having developed with it for a decade now. Hooks was the only meaningful API (surface) change, no?
> having developed with it for a decade now
I think this is the reason why React feels normal to you. But as someone coming into it fresh, React felt like there were always 4 different ways to do the same thing and 3 of them are wrong because they built a new API/there are more idiomatic ways to accomplish the same thing now. If you have a decade of experience, then you probably do most things the right/obvious way so don't even notice all the incorrect ways/footguns that React gives you.
If you're coming into it in 2025, it's even simpler. Just ignore the SSR stuff which Vercel are pushing and you're good. A lot of the path has been smoothed out over the years to make it an ideal place to start today.
I feel like the introduction of React Compiler was a pretty big change, too?
The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
To be fair, I haven't written in React for a few years now. I reached for Svelte with the last two apps I built after using React professionally for 4 years. I was expecting there to be a learning curve and there just... wasn't? It was staggering how little I had to think about. Even something as small as not having to write in JSX (however normalized I was to writing in it) really felt meaningful once I took a step back and saw the forest for the trees.
I dunno. I just remember being on the interview circuit and asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used, how something like console.log would fair in relation to them, when to include/exclude arguments from memoization arrays, etc.. and it was pretty easy to trip a lot of people up. I think the introduction of the compiler is an attempt to mitigate a lot of those pains, but newer frameworks designed with those headaches in mind from the start rather than mitigating much later and you can feel it.
I rolled my eyes when hooks came out and never used it again besides for work, so not really. All the frameworks on the planet and facebook is still a heaping pile of dog shit. I was spoiled by Vue's lifecycle methods and then Svelte and it was impossible to go back.
Maybe hooks are cool but the same code written in react vs vue vs svelte or something else is always easier on the eyes and more readable. Dependency arrays and stale closures are super annoying.
Sorry but I really hate React. I've dealt with way too many shit codebases. Meanwhile working in vue/svelte is a garden of roses even if written by raw juniors.
> when I built the first implementations and started measuring, something became clear: the issues I was seeing with Next.js weren’t specific to Next.js. They were fundamental to React’s architecture.
So here some obscure Next.js issues magically become fundamental React architecture issues. What are these? Skill issues?
The author noted that Solid is very similar to React but with a simpler mental model. This has been my experience as well. And its faster too.
How would you compare it to Preact?
I believe the biggest performance hit lives in je inability to force reload a cached file with js (or even html(!)).
Setting a header only works if you know exactly when you are going to update the file. Except from highly dynamic or sensitive things this is never correct.
You can add ?v=2 to each and every instance of an url on your website. Then you update all pages which is preposterous and exactly what we didn't want. As a bonus ?v=1 is not erased which might also be just what you didn't want.
I never want to reload something until I do.
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.
What a joy to read.
This isn't just poor writing, it's ChatGPT-padded slop.
But the same is true for the content itself, no business is paying you to actually build the same app 10x, especially so if it's something as trivial as a kanban board.
Mhh, I found it repeated sentences again and again. It was kinda odd to read at times.
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.
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
It's not about being closed to other languages, it's about being economically pragmatic in many, many cases.
As shown in the article, you can build ONCE an app that loads in milliseconds by just providing an url to any potential customer. It works on mobile and on desktop, on any operating system.
The native alternative requires:
- Multiple development for any platform you target (to be widely used you need *at least* ios, android, macOS and windows.) - Customers are required to download and install something before using your platform, creating additional friction.
And all of this to obtain at most 20-30ms better loading times?
There are plenty of cases where native makes sense and is necessary, but most apps have very little to gain at the cost of a massive increase in development resources.
Native to the web like web components or a native platform?
The problem of native apps isn't the language but the app stores.
Web deployment is easier, faster and cheaper.
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.
*) https://github.com/ryansolid
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.
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.
> 40ms round-trip time
In that case how can you possibly get 35ms FCP? Am I missing something?
Seems overly concerned with bundle size which I'm not sure really ever matters? Certainly smaller is better but is it that big of an impact?
Yes, it matters a lot, especially on mid/low end devices.
This post made me open up the Svelte docs again.
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.
If it was only 150kB for most sites. Usually that's followed up with multiple assets, API calls, often chained. Making the site slow.
JS can be 100x or even 1000x times more expensive to process than images. JS also blocks the main thread, while images can be processed in the background (and on GPU).
See Performance Inequality Gap https://infrequently.org/2024/01/performance-inequality-gap-...
Your attitude is exactly why our supercomputers struggle to display even the simplest things with any kind of performance, and why pure text takes multiple seconds to appear
Any reason to not include native application given how important mobile experience was.
Appstores complicate lifecycles by orders of magnitude.
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.
The guy is such a web zealot that he refuses to make the sensible engineering tradeoff that favors speed and offline capabilities over platform ubiquity. Most sane people would write a native app for this sort of thing if money was on the line.
it doesn't matter. in 10 years, few people will access websites directly.
Excellent work, I love experiments like these. Unsurprisingly the site is also lightning fast to load.
I'd be interested in seeing React Native in this comparison.
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.
What do you hope to see from the result of that comparison?
To gauge where RN sits on the spectrum of fast to slow.
> ... all deliver instant 35-39ms performance. The real differentiator? ...
Thanks ChatGPT for your valuable slop. Next article.
> This isn’t just an inconvenience. It’s technofeudalism.
> 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
Can Marko run static without a server? Can any of these?
Nuxt can too
Yeah, Svelte can.
Can’t most of them? Certainly React and Angular can as well.
(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.
Great post. Im moderately annoyed that on Safari mobile it has an incorrect and super annoying horizontal scroll.
> The web is mobile. Build for that reality.
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.
> some Web Applications just require low latency high bandwidth internet to work properly.
But the vast majority do not. And this haranguing is an opportunity / defensible position to put more efforts and resources into performances. If nothing else, think of it as a Trojan horse to make software suck less.
>If nothing else, think of it as a Trojan horse to make software suck less.
My experience has been that the proliferation of mobile devices has made my desktop experience consistently worse and I struggle to come up with an example where it didn't.
> But the vast majority do not. yeah and that's why they are shit and barely work.
Even a php app without decorations would be faster and better for most applications.
> That thinking is what gets you things like mandatory login via apps for your desktop.
"the web is mobile" = strictly "apps" ?
[dead]
[dead]
Am I missing something here? The mobile SPA app can be deployed using tools like capacitor to a device and the framework along with all static content is loaded into the app bundle. In such case it makes no (realistic) difference which framework is selected and it matters more how the background/slow transfers are handled with data-only API requests, possibly with hosted images. With the background workers PWA can be built as well, streamlining installation even more.