HN Reader

No software bloat isn't ok. Tech debt can be ok, and software bloat can be the consequence of tech debt taken on with eyes open. But to say that (some) software bloat without considerations is ok is how we have the fastest machines imaginable and still end up with UI that can't keep up visually with keystrokes.

Quoting Knuth without the entire context is also contributing to bloat.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

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.

I want to benchmark how much battery life Electron apps drain from my computer compared to the equivalent native apps. Then, we can talk about if bloat is OK.

P.S. Does someone know anyone who tested this?

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.

> 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?

Tangent, but software bloat always leaves me wondering what hardware/software could be if we had different engineering goals.

If we worked hard to keep OS requirements to a minimum- could we be looking at unimaginably improved battery life? Hyper reliable technology that lasts many years? Significantly more affordable hardware?

We know that software bloat wastes RAM and CPU, but we can't know what alternatives we could have if he hadn't spent our metaphorical budget on bloat already.

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...

One thing that bothers me about extreme bloat is that I do not want every app to push against the limit of what my computer can handle. It's fine if some game or compiler or such complex software do that every now and then. A common pro-bloat argument is that software should make use of all the hardware instead of leaving it idle, and that makes sense in some contexts. But 99% of the time I would prefer smaller things that I could have lots of and never have to worry about disk or RAM use.

Bloat mostly reflects Conway's law, with the outcome of it being that you're building towards the people you're talking to.

If you build towards everyone, you end up with a large standard like Unicode or IEEE 754. You don't need everything those standards have for your own messages or computations, sometimes you find them counter to your goal in fact, and they end up wasting transistors, but they are convenient enough to be useful defaults, convenient enough to store data that is going to be reused for something else later, and therefore they are ubiquitous in modern computing machines.

And when you have the specific computation in mind - an application like plotting pixels or ballistic trajectories - you can optimize the heck out of it and use exactly the format and features needed and get tight code and tight hardware.

But when you're in the "muddled middle" of trying to model information and maybe it uses some standard stuff but your system is doing something else with it and the business requirements are changing and the standards are changing too and you want it to scale, then you end up with bloat. Trying to be flexible and break up the system into modular bits doesn't really stave this off so much as it creates a Whack-a-Mole of displaced complexity. Trying to use the latest tools and languages and frameworks doesn't solve this either, except where they drag you into a standard that can successfully accommodate the problem. Many languages find their industry adoption case when a "really good library" comes out for it, and that's a kind of informal standardizing.

When you have a bloat problem, try to make a gigantic table of possibilities and accept that it's gonna take a while to fill it in. Sometimes along the way you can discover what you don't need and make it smaller, but it's a code/docs maturity thing. You don't know without the experience.

Bloat is always bad.

That said, all of engineering is a tradeoff, and tradeoffs mean accepting some amount of bad in exchange for some amount of good.

In these times, though, companies seem to be very willing to accept bloat for marginal or nonexistent returns, and this is one of the reasons why, in my opinion, so much of the software being released these days is poor.

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.

unfortunately the article is very offensive to anyone living outside of major urban centers, it presumes that along with our daily cake, that unlimited data and means to aquire it are only to be mentioned as trivialitys, if at all. rural devitalization is accelerating, with another article here describing how unreliable electrical power is in Calfornias country side I wont get into the details, but please imagine all the fun to be had attempting to turn off a win11 laptop, with hyper low speed and bandwidth internet, in order to try and save some battery in case the power does not come back on, which is the reality on most of our planets surface.

This article is awesome - I love the meme

As a former CS major (30 years ago) that went into IT for my first career, I've wondered about bloat and this article gave me the layman explanation.

I am still blown away by the comparison of pointing out that the WEBP image of SuperMario is larger in size than the Super Mario game itself!

There’re 2 constraints at work here- any piece of software only needs go as fast people will put up with.

The subtler one is that if interactive software goes too fast, people get suspicious.

These are human constraints, which means they’ll tend to eat up every tech improvement, dragging things back to just as slow as before.

But I think they’re cultural - not innate. Better education can lead the market to demand better.

> Layers & frameworks. Modern software tends to be more complicated. Most of the time people don't write software from scratch, they usually use some library or framework.

Some. But when some reaches the value of more than 80 (i did today an ldd in /usr/bin and i puked), something must be really, really wrong (hello KDE).

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...)

TFA lists maintainability as a benefit of bloat ("modularity, extensibility, code patterns make it easier to maintain"). Completely ignores how bloat harms maintainability by making code unknowable.

Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore. Can't hold it in your head. Debugging becomes archaeology through 17 layers of indirection. Features work. Nobody knows why. Nobody dares touch them.

TFA touches this when discussing complexity ("people don't understand how the entire system works"). But treats it as a separate issue. It's not. Bloat creates unknowable systems. Unknowable systems are unmaintainable by definition.

The "developer time is more valuable than CPU cycles" argument falls apart here. You're not saving time. You're moving the cost. The hours you "saved" pulling in that framework? You pay them back with interest every time someone debugs a problem spanning six layers of abstraction they don't understand

Back in the good old days, I used to play Quake 1 multiplayer (QuakeWorld) a lot on Internet servers. You could place an "autoexec.cfg" file in Quake folder, that automatically executed commands after launching the game, including /connect [IP Address]

The time needed from the moment you launched the game (clicked on the .exe) to the moment you entered the server (to the map view) with all assets 100% loaded was about 1 second. Literally! You click the icon on your desktop and BAM! you're already on the server and you can start shooting. But that was written by John Carmack in C :-)

From other examples - I have a "ModRetro Chromatic" at home which is simply an FPGA version of the Nintendo Game Boy. On this device, you don't see the falling "Nintendo" text with the iconic sound known from normal Game Boys. When I insert a cartridge and flip the Power switch, I'm in the game INSTANTLY. There's simply absolute zero delay here. You turn it on and you're in the game, literally just like with that Quake.

For comparison - I also have a Steam Deck, whose boot time is so long that I sometimes finish my business on the toilet before it even starts up. The difference is simply colossal between what I remember from the old days and what we have today. On old Windows 2000, everything seemed lighter than on modern machines. I really miss that.

> Thanks to Microsoft abusing their position with GitHub to perform the legally questionable act of stealing billions of lines of GPL code

I think this a strawman?

But it's pretty ridiculous if anyone believes this.

FOSS code can't be "stolen." The whole point of GPL and free software movement is that software should be free to use and modify.

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

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.

In the article, many tradeoffs are mentioned. The thing is, many of these tradeoffs are necessary to support the bloat, that is, bloat needs bloat.

- Layers & frameworks: We always had some layers and frameworks, the big one being the operating system. The problem is that now, instead of having these layers shared between applications (shared libraries, OS calls, etc...), every app wants to do their own thing and they all ship their own framework. For the calculator example, with the fonts, common controls, rendering code, etc... the global footprint was probably several MBs even in the early days, but the vast majority of it was shared with other applications and the OS shell itself, resulting in only a few extra kB for the calculator.

- Security & isolation: That's mostly the job of the OS and even the hardware. But the one reason why we need security so much is that the more bloated your code is, the more room there is for vulnerabilities. We don't need to isolate components that don't exist in the first place.

- Robustness & error handling / reporting: The less there is, the less can go wrong, so more robust and less errors to handle.

- Globalization & accessibility: That's true that it adds some bloat, however, that's something that the OS should take care of. If everyone uses the same shared GUI toolkit, only it has to deal with these issues. Note that many of these problems were addressed in the Windows 9x era.

- Containers & virtualization: Containerization is a solution to dependency hell and non-portable code, you carry your entire environment with you so you don't have to adjust to a new environment. The more dependencies you have, i.e. the most bloat, the more you need it. And going back to security and accessibility, since you are now shipping your environnement, you don't benefit from system-wide updates that address these issues.

- Engineering trade-offs: that is computers are cheap, developers are expensive. We are effectively trading time to hand-craft lightweight optimized software to keeping up with the bloat.

I get the author's point, but I believe that most of it is self-inflicted. I remember the early days of Android. I had a Nexus One, 512MB RAM / 1GHz single core CPU / 512MB Flash + 4GB MicroSD and it could do most of what I am doing now with a phone that is >10x more powerful in every aspect. And that's with internationalization, process isolation, the JVM, etc... Not only that but Google was much smaller back then, so much for lowering development costs.

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.

I'm curious, can you vibe code assembly? Perhaps the AI's havent been trained on much of it.. But in theory you could get amazing performance without all the work? .. The only downside is you would have zero idea how the code works and it would be entirely unmaintainable.

Some maybe, however we have moved away beyond it being ok.

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.