Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > 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?
by eviks - 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.
by crq-yml - 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.
by liampulles - 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.by 1313ed01
- I hate that argument too. The computer is there to serve ME, not to serve the software it runs. Each application should be using as little of the hardware as possible, to make it possible for ME to make use of all the software.by vrighter
- 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...by SurceBeats
- The sad reality is that easy tech explores solution space fasterby eitau_1
- I'd argue that the insane complexity of fast apps/APIs pushes many devs towards super slow but easy apps/APIs. There needs to be a middle ground, something that's easy to use and fast-enough, rather than trying to squeeze every last bit of perf while completely sacrificing usability.by m-schuetz
- What is often missing from the discussion is the expected lifecycle of the product. Using Electron for a simple app might be a good idea, if it is a proof-of-concept, or an app that will be used sparsely by few people. But if you use it for the built-in calculator in your OS, the trade-offs are suddenly completely different.by matusp
- Fortunately many apps seem to be moving to native webviews now instead of shipping electronby nly
- On the flip side, what you're saying is also an overused excuse to dismiss web apps and promote something else that's probably a lot worse for everyone.
I've never seen a real world Electron app with a large userbase that actually has that many dependencies or performance issues that would be resolved by writing it as a native app. It's baffling to me how many developers don't realize how much latency is added and memory is used by requiring many concurrent HTTP requests. If you have a counterexample I'd love to see it.
by sublinear - Yes. Too many people seem to forget the word "premature." This quote has been grossly misused to justify the most egregious cases of bloat and unoptimized software.by rossant
- Thinking is hard, so any product that gives people an excuse to stop doing it will do quite well, even if it creates more inconveniences like framework bloat or dependency rot. This is why shoehorning AI into everything is so wildly successful; it gives people the okay to stop thinking.by 0xEF
- 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.
by benrutter - Screens and radios do a lot to limit battery life on most modern devices even if the energy use running the OS and user software was free.
If with a reasonable battery standby mode can only last a few weeks and active use is at best a few days then you might as well add a fairly beefy CPU and with a beefy CPU OS optimizations only go so far. This is why eInk devices can end up with such a noticeably longer lifespan, they now have a reason to put in a weak CPU and do some optimization because the possibility of a long lifespan is a huge potential selling point.
by Retric - "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?"
Volunteer-supported UNIX-like OS, e.g., NetBSD, represents the closest to this ideal for me
I am able to use an "old" operating system with new hardware. No forced "upgrades" or remotely-installed "updates". I decide when I want to upgrade software. No new software is pre-installed
This allows me to observe and enjoy the speed gains from upgrading hardware in a way I cannot with a corporate operating system. The later will usurp new hardware resources in large part for its own commercial purposes. It has business goals that may conflict with the non-commercial interests of the computer owner
It would be nice if software did not always grow in size. It happens to even the simplest of programs. Look at the growth of NetBSD's init over time for example
Why not shrink programs instead of growing them
Programmers who remove code may be the "heros", as McIlroy once suggested ("The hero is the negative coder")
- 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
- I mean there are different kinds of bloats. Some is justifiable, some is not and some is just a symptom of other problems (the last 2 are not mutually exclusive), like mismanagement, incompetence (from management, developers, team leads, etc). This is somewhat similar to cholesterol, there are different types of cholesterol, some might be really bad, some might be harmless, etc.
Bloat (you mean here code duplication?) can be both cause or a symptom of some maintainability problem. It's like a vicious cycle. A spaghetti code mess (not the same thing as bloat) will be prone to future bloat because developers don't know what they are doing. I mean in the bad sense. You can still be not familiar with the entire system but if the code is well organized, is reusable, modular, testable, you can still work relatively comfortably with such code and have little worries of introducing horrible regressions (in a case of a spaghetti code). You can also do refactors much easier. Meanwhile, a badly managed spaghetti code is much less testable, reusable, when developers work with such code, they often don't want to reuse an existing code, because the existing code is already fragile and not reusable. For each feature they prefer to create or duplicate a new function.
This is a vicious cycle, the code is starting to rot, becoming more and more unmaintainable, duplicated, fragile, and, very likely, inefficient. This is what I meant.
by senfiaj - > Stack enough layers - framework on library on abstraction on dependency - and nobody understands what the system does anymore.
This is specious reasoning, as "optimized" implementations typically resort to performance hacks that make code completely unreadable.
> 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.
I think you're confusing things. Bloat and lack of a clear software architecture are not the same thing. Your run-of-the-mill app developed around a low-level GUI framework like win32 API tends to be far more convoluted and worse to maintain than equivalent apps built around high-level frameworks, including electron apps. If you develop an app into a big ball of mud, you will have a bad time figuring it out regardless of what framework you're using (or not using)
- A well-optimized program is often a consequence of a deep understanding of the problem domain, good scoping, and mindfulness.
It often feels to me like we’ve gone far down the framework road, and frameworks create leaky abstractions. I think frameworks are often understood as saving time, simplifying, and offloading complexity. But they come with a commitment to align your program to the framework’s abstractions. That is a complicated commitment to make, with deep implications, that is hard to unwind.
Many frameworks can be made to solve any problem, which makes things worse. It invites the “when all you’ve got is a hammer, everything looks like a nail” mentality. The quickest route to a solution is no longer the straight path, but to make the appropriate incantations to direct the framework toward that solution, which necessarily becomes more abstract, more complex, and less efficient.
by frisbee6152 - 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.
by _dcez - Game carts also have much faster access times than just about anything else contemporary because they're just ROM. If Linux, OpenGL, Vulkan, etc. were in the ROM of your Steam Deck, and your games were on ROM (not flash) carts, that'd boot up instantly too.
Windows 2000 boots up fast on modern hardware. You're looking through rose-colored-ass glasses if you think it booted up that quick on the hardware available at the time of release. Windows NT was a pig in its day, but at least it was a clean pig, free of spyware and other unnecessary crapware (unless you were like a client site I visited, and just let Bonzi Buddy, Comet Cursor, and such run rampant across your sensitive corporate workstations).
by bitwize - A system like SteamOS can be made to boot within seconds - but it takes some effort to set it up like that and I don't think anybody there cares enough when most people would just put the Deck to sleep where it wakes up in a single second.by seba_dos1
- 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.
by Grumbledour - What I once said to a less experienced developer in a code review is:
> Don't write stupid slow code
The context was that they wrote a double-lookup in a dictionary, and I was encouraging them to get into the habit of only doing a single lookup.
Naively, one could argue that I was proposing a premature optimization; but the point was that we should develop habits where we choose the more efficient route when it adds no cost to our workflow and keeps code just as readable.
by gwbas1c - I've found that mentioning bloat is the fastest way to turn a technical conversation hostile.
Do we need a dozen components of half a million lines each maintained by a separate team for the hotdesk reservation page? I'm not sure, but I'm definitely not willing to endure the conversation that would follow from asking.
- It is forever baffling to me that so many devs don’t seem to appreciate that small performance issues compound, especially when they’re in a hot path, and have dependent calls.
Databases in particular, since that’s my job. “This query runs in 2 msec, it’s fast enough.” OK, but it gets called 10x per flow because the ORM is absurdly stupid; if you cut it down by 500 microseconds, you’d save 5 msec. Or if you’d make the ORM behave, you could save 18 msec, plus the RTT for each query you neglected to account for.
by sgarland - I've never interpreted "Premature optimization..." to mean don't think about performance, just that you don't have to actually implement mechanisms to increase performance until you actually have requirements to do so - you should always ask of a design "how could I make this perform better if I had to".by arethuza
- > 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.
Yeah I find it frustrating how many people interpret that quote as "don't bother optimizing your software". Here's the quote in context from the paper it comes from:
> 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 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.
Knuth isn't saying "don't bother optimizing", he's saying "don't bother optimizing before you profile your code". These are two very different points.
by ndiddy - > 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.
by rossant