Can you also tell ChatGPT to fix the layout so the table just above this message is fully visible without horizontal scrolling?
> 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
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.
"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
Maybe years ago. Now it's a bloated beast.
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.
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.
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.
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.
Web deployment is easier, faster and cheaper.
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.
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.
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.
There are also other solutions if you need to preserve the url that are cleaner than appending a query string, like etags
These are expensive hacks to work around a lack of basic functionality.
It reminds me of one kid taking something from another and refusing to give it back because they are larger.
People make websites, they think they control what goes on on the page. This isn't unreasonable to think. In fact, everything should be made to preserve that idea.
A situation where they just can't change the page shouldn't exist. Abstracting it away or otherwise working around it doesn't make it any less wrong.
Some browsers have a magic key combo to force reload. I suppose the solution is to put up a modal and ask the user to "reinstall" the web page.
I have a lot of static pages with minimal html/css that thanks to lazy loading and caching consume very little bandwidth. The technology is truly wonderful, clicking around feels like a desktop application.
Vite gives you that behaviour out of the box.
Can someone explain why ? What precisely would make React sooo slow and big compared to other abstractions ?
But this mostly applies to subsequent re-renders, while things mentioned in the article are more about initial render, and I'm not exactly sure why does React suffer there. I believe React can't skip VDOM on the server, while Vue or Solid use compiled templates that allow them to skip that and render directly to string, so maybe it's partially that?
however, React didn't copy from others, so it got slower than "competition"
As to why it is slow, my knowledge is super up-to-date (haven't kept up that well with recent updates), but in general the idea is:
- The React runtime itself is 40 kB so before doing anything (before rendering in CSR or before hydrating in SSR) you need to download the runtime first.
- Most frameworks have moved on to use signals to manage state updates. When state change, observers of that state will be notified and the least amount of code will be run before updating the DOM surgically. React instead re-executes the code of entire component trees, compares the result with the current DOM and then applies changes. This is a lot more work and a lot slower. Over time techniques have been developed in React to mitigate this (Memoization, React Compiler, etc.), but it still does a lot more work than it needs to, and these techniques are often not needed in other frameworks because they do a lot less work by default.
The js-framework-benchmark [1] publishes benchmarks testing hundreds of frameworks for every Chrome release if you're interested in that.
[1]: https://krausest.github.io/js-framework-benchmark/2025/table...
You're not answering my question, just adding some more feelings.
> The React runtime itself is 40 kB
React is < 10 kb compressed https://bundlephobia.com/package/react@19.2.0 (add react-dom to it). That's not really significative according to the author's figures, the header speaks about up "to 176.3 kB compressed".
> Most frameworks have moved on to use signals to manage state updates. When state change
This is not kilobytes or initial render times, but performance in rendering in a highly interactive application. They would not impact rendering a blog post, but rendering a complex app's UI. The original blog post does not measure this, it's out of scope.
The other thing is that React is too big in terms of kBs of JavaScript you have to download and then parse (and often, thanks to great React ecosystem, you use many other libraries). But that's just another trade-off: it's the price you pay for great backwards compatibility (e.g. you can still use React Class components, you don't have to use hooks, etc.).
That being said React is slow. That is why you need useTransition, which is essentially manual scheduling (letting React know some state update isn't very important so it can prioritise other things) which you don't need to do in other frameworks.
useOptimistic does not improve performance, but perceived performance. It lets you show a placeholder of a value while waiting for the real computation to happen. Which is good, you want to improve perceived performance and make interactions feel instant. But it technically does not improve React's performance.
so React has a performance issue in most places it is used. And probably in every project that lives long enough.
Now, let's talk about the comments, particularly the top comment. I have to say I find the kneejerk backlash against "AI style" incredibly counter-productive. These comments are creating noise on HN that greatly degrades the reading experience, and, in my humble opinion, these comments are in direct violation of all of the "In Comments" guidelines for HN: https://news.ycombinator.com/newsguidelines.html#comments
Happy to change my mind on this if anyone can explain to me why these comments are useful or informative at all.
So here some obscure Next.js issues magically become fundamental React architecture issues. What are these? Skill issues?
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.
In that case how can you possibly get 35ms FCP? Am I missing something?
No, it is excuse not to invest money in places where users won't pay.
For questions about mobile - yeah we get requests for showing it on mobile but app in app store is hard requirement, because of discoverability. People know how to install app from app store and then they have icon. Making PWA icon is still too much work for normal people.
I would need "add to home screen" button in my website that I could have user making icon with single click, then I could go with PWA.
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.
> 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
> Here’s where this gets bigger than framework choice. When you ship a native app to the App Store or Google Play instead of building a web app, you’re not just making a technical decision. You’re accepting a deal that would’ve been unthinkable twenty years ago. Apple and Google each take up to 30% of every transaction (with exceptions depending on program and category). They set rules. They decide what you can ship. They can revoke your access tomorrow with no recourse. You have no alternative market. You can’t even compete on price because the fee is baked into many transactions.
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.
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.
Even a php app without decorations would be faster and better for most applications.
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.
"the web is mobile" = strictly "apps" ?
Thanks ChatGPT for your valuable slop. Next article.
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
dist/assets/app.css 98.33 kB │ gzip: 17.69 kB
dist/assets/app.js 1,050.14 kB │ gzip: 244.88 kB
built in 15.41s
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.
.. creating a maintenance issue right now.
If so, you have the extra cost, effort and bureaucracy of building and deploying to all the different app stores. Apple's App Store and Google Play each have various annoyances and limitations, and depending on your market there are plenty of other stores you might need to be in.
Sometimes you do need a native or native-feeling app, in which case a native wrapper for JS probably is a good idea, other times you want something lightweight that works everywhere with no deployment headaches.
UX matters, and user does not care if the native wrapper or 500kB of js is there or not, as long as the job is done conveniently and fast.