Some software bloat is OK

The article is kind of right about legitimate bloat, but "premature optimization is evil" has become an excuse to stop thinking about efficiency entirely. When we choose Electron for a simple app or pull in 200 dependencies for basic tasks, we're not being pragmatic, we're creating complexity debt that often takes more time to debug than writing leaner code would have. But somehow here we are, so...

The "development time is more important than performance" motto treats bad performance as the problem with software, when in reality poor performance is a symptom of growing software complexity. I'm sure that each individual coder who has contributed to software bloat believed that their addition was reasonable. I'm sure everyone who has advocated for microservices fully believes they are solving a real-world problem. The issue is that we don't treat complexity as a problem in-and-of-itself.

In physical disciplines, like mechanical engineering, civil engineering, or even industrial design, there is a natural push towards simplicity. Each new revision is slimmer & more unified–more beautiful because it gets closer to being a perfect object that does exactly what it needs to do, and nothing extra. But in software, possibly because it's difficult to see into a computer, we don't have the drive for simplicity. Each new LLVM binary is bigger than the last, each new HTML spec longer, each new JavaScript framework more abstract, each new Windows revision more bloated.

The result is that it's hard to do basic things. It's hard to draw to the screen manually because the graphics standards have grown so complicated & splintered. So you build a web app, but it's hard to do that from scratch because the pure JS DOM APIs aren't designed for app design. So you adopt a framework, which itself is buried under years of cruft and legacy decisions. This is the situation in many areas of computer science–abstractions on top of abstractions and within abstractions, like some complexity fractal from hell. Yes, each layer fixes a problem. But all together, they create a new problem. Some software bloat is OK, but all software bloat is bad.

Security, accessibility, and robustness are great goals, but if we want to build great software, we can't just tack these features on. We need to solve the difficult problem of fitting in these requirements without making the software much more complex. As engineers, we need to build a culture around being disciplined about simplicity. As humans, we need to support engineering efforts that aren't bogged down by corporate politics.

> There are still highly demanded optimized programs or parts of such programs which won't disappear any time soon. Here is a small fraction of such software: > ... > Such software will always exist, it just moved to some niche or became a lower level "backbone" of other higher level software.

Yes. I’ve been working for years on building a GPU-based scientific visualization library entirely in C, [1] carefully minimizing heap allocations, optimizing tight loops and data structures, shaving off bytes of memory and microseconds of runtime wherever possible. Meanwhile, everyone else seems content with Electron-style bloat weighing hundreds of megabytes, with multi-second lags and 5-FPS interfaces. Sometimes I wonder if I’m just a relic from another era. But comments like this remind me that I’m simply working in a niche where these optimizations still matter.

[1] https://datoviz.org/

The question is of course always where someone draws the line, and thats part of the problem.

Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.

And while they might be right concerning small stuff, this often piles up and in the end, because you choose several times not to optimize, your technology choices and architecture decisions add up to a bloated mess anyway that can't be salvaged.

Like, when you choose a web framework for a desktop app, install size, memory footprint, slower performance etc. might not matter looked at individually, but in the end it all might easily add up and your solution might just suck without much benefit to you. Pragmatism seems to be the hardest to learn for most developers and so many solutions get blown out of proportion instantly.

> A significant part of this bloat is actually a tradeoff

Or actually not, and the list doesn't help go beyond "users have more resources, so it's just easier to waste more resources"

> Layers & frameworks

There are a million of these, with performance difference of orders of magnitude. So an empty reference explains nothing re bloat

But also

> localization, input, vector icons, theming, high-DPI

It's not bloat if it allows users to read text in an app! Or read one that's not blurry! Or one that doesn't "burn his eyes"

> Robustness & error handling / reporting.

Same thing, are you talking about a washing machine sending gigabytes of data per day for no improvement whatsoever "in robustness"? Or are you taking about some virtualized development environment with perfect time travel/reproduction, where whatever hardware "bloat" is needed wouldn't even affect the user? What is the actual difference between error handling in the past besides easy sending of your crash dumps?

> Engineering trade-offs. We accept a larger baseline to ship faster, safer code across many devices.

But we do not do that! The code is too often slower precisely because people have a ready list of empty statements like this

> Hardware grew ~three orders of magnitude. Developer time is often more valuable than RAM or CPU cycles

What about the value of time/resources of your users ? Why ignore reality outside of this simplistic dichotomy. Or will the devs not even see the suffering because the "robust error handling and reporting" is nothing of the sort, it mostly /dev/nulls a lot of user experience?

I work in enterprise, B2C software, lots of single page apps / self service portals, that kind of thing. I don't think our software is bloated per se; sure it could be faster, but for example when it comes to mobile apps, it's a tradeoff between having the best and fastest apps, being able to hire people, development speed, and non-functional requirements.

It's good enough, and for example React Native is spending years and millions in more optimizations to make their good enough faster, the work they do is well beyond my pay grade. (https://reactnative.dev/blog/2025/10/08/react-native-0.82#ex...)

When I click on some of stuff on the page Im getting redirected to spammy opera download pages

The performance of a web service is largely dependant on how many calls and how quickly it can make calls to external services. If a given system is making 2 DB calls when it could instead make one, then that should be the initial focus for optimisation.

Indeed, if a language and framework has slow code execution, but facilitates efficient querying, then it can still perform relatively well.

Sometimes bloat is forced on you.

I had to write Android app recently. I don't like bloat. So I disabled all libraries. Well, I did it, but I was jumping over many hoops. Android Development presumes that you're using appcompat libraries and some others. In the end my APK was 30 KB and worked on every smartphone I was interested (from Android 8 to Android 16). Android Studio Hello World APK is about 2 MB, if I remember correctly. This is truly madness.

Sometimes I feel the biggest contribution React made to the world isn't it speeded up frontend dev or something. It's showing how much discussion about performance is pure paranoid.

Bloat is OK when the alternative is worse. But have you really done the analyzes on how bad and how bigger the bloat is going to get? But it's still justified if the alternative is worse.

If I could make one law related to software, it would be to ban React and React-like frameworks (includes Vue and Svelte I believe): if you have to put more than one line of HTML in your JavaScript, if you have VDOM, if you have a build step - I want this to be illegal. It is entirely possible to write a js-framework that attaches itself to DOM from the top, without any kind of expensive hydration steps or VDOM or templating (I've built one). React is a horrible complex monster that wastes developers time, heats up users' CPUs and generally feels super slow and laggy. 99% percent of websites would work a lot better with SSR and a few lines of JavaScript here and there and there is zero reason to bring anything like React to the table. React is the most tasteless thing ever invented in software.