JavaScript-heavy approaches are not compatible with long-term performance goals
sgom.es46 points by luu 7 hours ago
46 points by luu 7 hours ago
This title is very misleading, it should be "Why React is not compatible with long-term performance goals"
And I do agree generally. React uses an outdated rendering method that has now been surpassed by many better frameworks. Svelte/Sveltekit, Vue, and Qwik are the best examples.
People relying on bloated React packages is obviously not great but that is nothing to do with javascript itself.
The JS engines are all relatively fast now. And the document model of the current web provides major accessibility to both humans and search tools like SEO and GEO. JS is not my favorite language. I would rather the web was based on a statically typed language that had better error handling practices like Go. But this will most likely not happen any time soon as it would require every level of the ecosystem to adapt. Browsers, Frameworks, Developers etc.
Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.
If you want faster webapps just switch to sveltekit or vue or qwik. But often the ones choosing the framework for the project have not written much code in years, they know react is as safe option and used by everyone else so they follow along, if it gets slow its a "bug" causing it as they built apps that were "good enough" before using it.
> Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.
They already tried. It was called Dart and for a while there was an experimental flag to enable it directly in Chrome. It was cancelled and Dart was relegated to transpiling to JS/WASM.
The reason I'm a backend dev at the moment is that I looked at the React model and decided I didn't want anything to do with this insanity.
I've been appalled by how long and how broadly the mass hysteria lasted.
And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years.
It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?"
In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct.
I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app.
A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.
I managed to avoid learning React long enough to become a manager.
I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.
Do you consider Angular to have a better rendering system? Or is it similar to React?
Asking because I use Angular and want to learn other frameworks in case Angular is just as bad for long term.
I analyzed all the major frameworks years ago and went with Svelte when svelte 5 came out. It is all I use now, the development team is highly responsive and cooperative with the community, the founder Rich Harris has a pragmatic approach and tries to keep it as compatible with html/js while still providing great DX and massive efficiency. It natively supports serverside rendering that turns into a SPA once it hits the browser.
Angular is probably more efficient than react but The DX is going to be worse than svelte or vue.
If you want the fastest apps in environments with low ping then use Qwik.
If you want the best overall experience, great customizability, compatability with any js package, great efficiency in most situations, and a great developer experience just go with Svelte (or vue maybe).
Angular might be fine, I don't know. I never used it extensively. But I do know that svelte is the only framework that I like using now.
A cogent article. But I think the biggest problem is that the DOM was built for documents, not apps. We know how to build a performant UI architecture: Qt, Java/Swing, Cocoa all have pretty similar architectures and they all ran fine on much poorer hardware than a modern browser on an M1. But unless you use WebAssembly, you can't actually use them on the browser.
When the industry shoehorns something into a tool designed for something else, yeah, performance suffers and you get a lot of framework churn with people trying to figure out how to elegantly cut steaks with spoons.
But most apps are documents, they are built to render data and text fields in a nice way for the consumer to use.
You most certainly shouldn't be building graphs with table elements but JS has canvas and svg which make vectors pretty efficient to render.
The document model provides good accessibility and the ability for things like SEO and GEO to exist.
If you are making a racing simulator, then using HTML in no way makes sense, but for the apps that most of us use documents make sense.
It would be nice if browsers implemented a new interpreted statically typed language with direct canvas/viewport rendering that was more efficient than javascript, but chrome would need to adopt it, then developers would need to actually build things with it. It seems like it would currently have to come from within the chrome team directly and they are the only ones that can control something like this.
The irony is that CSS works fairly okay for the small number of UI elements and web games that are decidedly not documents. Or perhaps that's not so much irony as filling in the gaps.
fairy okay is the key word.
Everything works fairly okay on modern hardware. I'm sure someone could build a 3d rendering engine using only table elements and css and it would run decently well.
There are hundreds of tools in the belt, people can use any of them to tighten down the screw, but it doesn't mean that they are the most efficient or best to use.
I would also say that a lot of web games are closer to documents than you think. A chess board could be seen as a document, it has tables and rows, the characters are just shaped different than the characters we write with.
Something like a racing sim again could be implemented in css but someone who actually understands how to use canvas is going to have a more efficient way to represent it.
It very possible to make lightning-fast React web UIs. DOM sucks, but modern computers are insanely fast, and browsers, insanely optimized. It is also very possible to make sluggish-feeling Qt or Swing applications; I've seen a number.
It mostly takes some thinking about immediate reaction, about "negligibly short" operations introducing non-negligible, noticeable delays. Anything not related to rendering should be made async, and even that should be made as fast as possible. This is to say nothing of avoiding reflows, repeated redraws, etc.
In short, sloppy GUI code feels sluggish, no matter what tools you use.
> but modern computers are insanely fast, and browsers, insanely optimized
I think these facts have been used as excuses to shit up the app layer with slow mal-optimized js code.
An example of a recent high performance app is figma, which blows normal js only apps out of the water. And it does so by using c++ wasm/webGPU for its more domanding parts, which is most of it
I think we have to let go of the "just get more ram" approach and start optimizing webapp code like figma does
> Anything not related to rendering should be made async,
The thing with DOM interaction is that if you try to make it synchronous then it gets really fucking slow (reflow and friends). So you want it linearized for sanity reasons, but probably not sync.
> the biggest problem is that the DOM was built for documents, not apps
I don't see the difference. They're both text and graphics laid out in a variable-sized nested containers.
And apps today make use all the same fancy stuff documents do. Fonts, vector icons, graphics, rounded corners, multilingual text including RTL, drop shadows, layers, transparency, and so forth.
Maybe you think they shouldn't. But they do. Of all the problems with apps in web pages, the DOM feels like the least of it.
While I don't have the performance bottleneck numbers of React, I don't think it's about Javascript vs. WASM here.
I've seen/built some large Qt/QML applications with so much javascript and they all performed much better than your average React webapp. In fact the V8 / other browser Javascript engines also have JIT while the QML engine didn't.
Comparing QtQuick/QML + JS to HTML + JS - both GPU accelerated scenegraphs, you should get similar performance in both. But in reality it is rarely the case. I suspect it might be the whole document oriented text layout and css rules, along with React using a virtual DOM and a lot of other dependencies to give us an abstraction layer.
I'd love to know more about this from someone who did an in depth profiling of the same/similar apps on something like QtQuick vs. React.
It's not about Javascript vs. WASM; it's the DOM. DOMless apps like Figma are much faster.
The slowness in a React app is not the DOM. Typical apps spend most of their time running component code long before any DOM mutations are committed.
If you look at DOM benchmarks it's extremely fast. Slow web pages come from slow layers on top.
They mentioned React is missing timing information in the devtools profiler. This was actually added in React 19.2 which should be helpful for debugging.
https://react.dev/blog/2025/10/01/react-19-2#performance-tra...
> I’ll focus on React and Redux in some of my examples since that is what I have the most experience with, but much of this applies to other frameworks and to JS-heavy approaches in general.
That's not a fair assumption. Frameworks like Svelte, Solid, Vue etc have smaller bundle sizes and rendering speeds that approach the baseline vanilla-js cost.
I'm all for criticising Javascript, but moving everything to the server isn't a real solution either. Instead of slow React renders (50ms?), every interaction is a client-server round trip. The user pays the cost of the paradigm on each interaction instead of upfront with an initial JS payload. Etc.
Yeah this article is only about React. But it makes sense that someone would think this way because many dev's think JS web apps==react only.
The problem is react is "good enough" for most cases and the performance degradations happen slow enough that the devs/project leads don't see it until it's too late and they are already overly invested in there project and switching would be too compliated/costly for them.
Svelte/kit and properly optimized packages solve almost all of the "problems" this article tries to bring up.
Plus Redux is horrible for performance, slows things down and overcomplicates everything.
I never understood why state management is overcomplicated in React. For some reason most people use something like Redux which has a very unintuitive API. There are other state management packages available that are so much easier to use and understand, like MobX.
agree w the long-term perf point, and i'd add: js-heavy apps also tend to hide the 'true' critical path (hydration + data + layout) so teams ship regressions without noticing. do you have a rule of thumb for when a page has crossed the line (tti/cls budgets, max js kB, etc)? and do you see islands/partial hydration as a real middle ground or just a temporary patch?
Github was usable and fast, now it is slow. Guess what changed...
It was re-written in React and performance was annihilated. The React Virus annexed another victim and we have one more zombie web-site.
I am so grateful to the author for writing this article. For years I've been fighting a series of small battles with my peers who seem hell-bent on "upgrading" our e-commerce websites by rewriting them in React or another modern framework.
I've held the line, firm in my belief that there is truly no compelling reason for a shopping website to be turned into an SPA.
It's been difficult at times. The hype of new and shiny tools is real. Like the article mentions, a lot of devs don't even know that there is another way to build things for the web. They don't understand that it's not normal to push megabytes of JavaScript to users' browsers, or that displaying some text on a page doesn't have to start with `<React><App/></React>`.
That's terrifying to me.
Articles like this give me hope that no, I'm not losing my mind. Once the current framework fads eventually die out - as they always do - the core web technologies will remain.
I think shopping gets this in spades too because not all shopping sites are meant to be particularly sticky.
It's one thing to browse the catalog at my leisure on gigabit networking, a 5k display and 16 CPU cores. It's another thing when I'm standing in Macy's or Home Depot and they don't quite have the thing I thought they have and I'm on my phone trying to figure out if I can drive half a mile to your store and get it. If you want to poach that sale your site better be fast, rather than sticky.
"Now’s a good time to figure out whether your client-side application should have a server-side aspect to it, to speed up initial renders."
My how the tables have turned!
Only a single passing mention of web components?
In other news: water is wet. I genuinely don't understand how anyone is still pretending otherwise. Server-side rendering is so much easier to deliver in a performant way, yet it feels like it's being increasingly forgotten — or worse, actively dismissed as outdated. Out of convenience, more and more developers keep pushing logic and rendering onto the client, as if the browser were an infinitely capable runtime. The result is exactly what this article describes: bloated bundles, fragile performance, and an endless cycle of optimization that never quite sticks.
Pure client side rendering is the only way to get max speed with lowest latency possible. With ssr you always have bigger payloads or double network rounds.
Try this: https://mapjoy.app/, username and pass johnsmith.
All of JS with client side routing, blazing fast.
React is utterly amazing.
Eh, this argument falls apart for many reasons:
- His main example of bloated client-side dependencies is moment.js, which has been deprecated for five years in favor of smaller libraries and native APIs, and whose principal functionality (the manipulation and display of the user's date/time) isn't possible on the server anyway.
- There's an underlying assumption that server-side code is inherently good, performant, and well crafted. There are footguns in every single language and framework and library ever (he works for WordPress, he should know).
- He's right to point out the pain of React memoization, but the Compiler now does this for you and better than you ever could manually
- Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes, especially if poorly optimized, which easily and immediately dwarf bundle downloads; and slow database queries, which affect server-side code just as much as browser-side code.
> There's an underlying assumption that server-side code is inherently good, performant, and well crafted
To me it’s an assumption that server side code is going to be running on a server. Which is a known quantity and can be profiled to the nth degree. It’s extremely difficult to profile every possible device your site will run on, which is crucial with low powered mobile devices.
> Larger bundle sizes are unfortunate, but they're not the main cause of performance issues. That'd be images and video sizes
Not really, no. Large bundle sizes prevent the initialisation of the app, which means the user can’t do anything. By comparison images and videos download asynchronously and get processed on a separate thread. JS bundles also need to be parsed after being downloaded, if you pair a crappy Android phone with an 5G connection the parsing can literally take longer than the download.
I’m still baffled why this language is the universal browser standard. There should be hundreds competing.
I'm still baffled why you don't see JavaScript is fast, but how page rendered is the issue.
I’m baffled you don’t believe in benchmarks, but, uh.
Speaking about benchmark.
Node vs Lua shows Node faster than Lua. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Node vs C, only 4 to 5 times slower. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Looking at its root, it is not too bad as a JIT compiled language.