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