Posted by 0xblinq 1 day ago
Can you also tell ChatGPT to fix the layout so the table just above this message is fully visible without horizontal scrolling?
Edit: Related post on the front page: https://news.ycombinator.com/item?id=45722069
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.
On first glance it seems very legit and personally I would be very hesistant judging something GPT slop based on some writing style.
>> 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.
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.
Websites taking seconds to load in bad mobile reception is usually down to latency and handshaking, not raw bandwidth.
Show me a real world example of a single payload 500kB taking seconds longer than 13kB. It's not realistic.
I can also show you how slow it is when I visit the countryside and the connection is not good.
Or when I take a very crowded train to another city/country and have to share the wi-fi while traveling in a non-metropolitan area.
Or when I run out of pre-paid credits and I get bumped into low speed mode and the provider's page takes several minutes to load.
I don't even know why I answer to this. Because for sure this is all my fault and I'm the one "holding it wrong".
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.
Yeah but a couple seconds I can wait. A few minutes not realistically unless it’s something really important.
"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, ..
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.
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.
> 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
- 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.
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. :)
"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 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).
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.
I wonder how anyone gets any work done when they have to wait 10 seconds on every page load on a M3 Macbook Air
Back in 1999 - 2001, every time I wanted to do a make clean; make all in a C based product (actuall TCL with lots of C extensions), it took at least one hour build time.
Maybe years ago. Now it's a bloated beast.
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.
official documentation, otherwise you'll be creating a NextJS app and get recommended to deploy to Vercel.
Saying React is a "bloated monster" and then not being able to provide a single example of ways it has bloated is a joke. The article we're looking at shows that the bundle size can be a bit bigger but the speed to render is equivalent to all these other frameworks.
If you really love minimal bundle sizes, go off, but bundle size is not how I would define bloat in a framework
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.
React 19 required almost no code changes in my multiple production apps so unless I missed something, I would say the API surface was virtually unchanged by it
> The article seems to make the bloat self-evident by comparing the load times of identical apps and finding React magnitudes slower.
What are you talking about? Next.js != React, that's your own fault if you bought into their marketing. TanStack / React looks to be a slightly larger bundle size but I'm seeing FCP differences from 35ms to 43ms (React being 43ms), how is that orders of magnitude slower?
Bad faith or bad reading, I can't help you either way here
> asking engineers to tell me about useCallback, useEffect, useMemo, and memo and how they're used
What are you even trying to say? Are you implying that other web frameworks don't come with any state management, or that they are reactive, or that you don't need the concepts from React in them?
"People got confused sometimes" isn't really a defense when the alternative is a framework you only ever use on solo greenfield projects that you've never talked to another engineer about their core concepts.
Seriously, you are just peddling groupthink, there isn't a single legit criticism of React.
Next.js, on the flip side, we should all go off on those clowns, but I wouldn't touch that with a 10 foot pole so I don't see how it's even relevant.
"use no memo"
react now needs you to declare what you are not using, using a language "feature" that does not exist. It is crazy how people keep denying reality wrt React.
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.
Now with Laravel, Blade and JQuery the IDE support is low but everything is easy enough and we work as a team and do merge requests and it's a chill job even if it's full stack.
>I liked being a solo React Typescript developer.
Being a solo FE rocks. Everyone thinks you're a magician. The worst is FE-by-committee where you get 'full-stack' devs but really they're 99% postgres and 1% html.
Congrats, it's the most popular framework, no doubt there are abuses out there.
I highly doubt raw juniors are actually writing beautiful vue/svelte code, if obviously emotionally charged anecdotes are your only arguments here, I think you can just admit you see "Facebook" and crash out...
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.
> 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.
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.
Some of the most challenging code that I write, is about caches.
Writing good cache support is hard.
But in cases as grandparent describes, you do have significant wiggle room.
It's fairly difficult, for me. The app can do a lot, but sometimes, the data needs to be fresh. Making the decision to run an update can be difficult.
Also, I write free software, for nonprofits, so the hosting can sometimes be a bit dodgy.
At the end of the day there have been a lot of new things in web development but none of them are of such a significance that you’re missing out on anything by sticking with what works. I personally just like to go with a mature backend framework (usually Laravel or Django) and minimal JS on the frontend. I’ve tried many of the shiny new libraries but have not seen much reason to switch over.
You’ve stopped caring because it. never. ends. Really.
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.
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.
Also, performing well in a prototype scenario is very different than performing well in production-ready scenario with a non-trivial amount of templates and complex operations. Even the slowest SSGs perform fast when you put three Markdown posts and one layout in them, but then after a few years of real-world usage you end up in a scenario where the full build takes about half an hour.
Kinda cool that you can do that in an afternoon, but absolutely useless as a benchmark of anything.
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.
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
By the way, my "horse" of choice is Quasar(based on Vue) and has been for years now.