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.
Jeez! Y'all are quite harsh. I wrote this in sections and then tried to stitch it all together. I did my best to remove repetition, but overall it's my writing edited with the help of AI to moderate some of my personal biases. The value here is both checking out the code (written by me with the help of the maintainers of each framework) as well as tables for lighthouse scores and bundle sizes.
I personally think the most important parts of the post are these two related parts: (1) the technofeudalism section (2) developing lightweight apps so a business does not feel the need to have a separate native codebase along with a specialized native team ($$$). I was hoping this post was a gift to many people by doing all this work for y'all, or at least providing a foundation from which you can fork and modify for your own use.
It is an open question for everyone if start up time on cellular is something you need to worry about. All the other non-sense here misses the point.
>> 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.
I can attest to the differences mentioned, having visited in many cities around the world. Assuming your own local performance reflects that of the rest of the world is not accurate.
The article cites also the use case, real estate agents. They also struggle at times with bad connection issues it seems. And with a bad connection average websites do take seconds to load for me.
I question it, because I live somewhere rural with bad connection and travel frequently around europe, where I often experience bad connection outside of cities, so I do value lightweight pages like the article authors propose as a metric. Heavy weight pages I don't even bother trying to load in some areas.
"Show me a real world example of a single payload 500kB taking seconds longer than 13kB. It's not realistic."
And my only comment towards this is, please go out to see for yourself.
Also maybe take into account, the bloated website is not the only thing using the device connection. Messager messages syncing in the background, ..
I'm saying that the impact of dropped packets and poor latency falls much worse on sites that have multiple connections and dozens of files to download than a single bundle.
Also in those circumstances, the 13kB would also take "seconds".
The situation described, where the 13kB file takes milliseconds but the 500kB file takes seconds, is what is unrealistic. It's an invention of an LLM.
Chances are two different 13kB files would be far worse in those circumstances than a single 500kB file.
I don't know why I'm still answering this thread, because it's clear I'm not being understood, and this is all arguing over a flagged AI slop article that no-one wrote.
I don't really know what to say except that you're wrong here. There are many studies out there about loading time affecting conversions/sales. I link to the most recent study done by Speed Curve about the damage slow loading apps do to business metrics.
Not wanting to believe something is very different from the thing being untrue. The differences between 13kB and 500kB are quite real and quite measurable.
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.
https://news.ycombinator.com/item?id=45724022