The Obesity Epidemic in Modern Software: Why 2026 Apps Eat Gigabytes for Breakfast
Looking back at Apollo's software efficiency compared to modern Electron-based apps that consume massive RAM and resources despite powerful hardware.
Stock photo for illustration only, not from the actual event
- The Apollo 11 computer guided humans to the moon using only 4 kilobytes of RAM.
- Modern desktop apps frequently run on isolated Chromium and Electron runtimes.
- Developer velocity is heavily prioritized over actual runtime efficiency.
- Operating systems and apps often function as active data extraction engines.
Niklaus Wirth famously stated back in 1995 that software is getting slower more rapidly than hardware becomes faster. In 1969, the Apollo 11 Guidance Computer navigated humans through 240,000 miles of space and landed them on the moon using just 4 kilobytes of RAM and 72 kilobytes of ROM.
Fast forward to today, opening a basic chat application on a $2,000 laptop requires wrestling with severe input latency and wasted hardware resources. Despite having multi-GHz CPUs with 16+ cores, NVMe SSDs transferring 7 GB per second, and dedicated Neural Processing Units, clicking a button in a desktop calendar app introduces 300ms of input latency, and typing in a web-based text editor regularly drops frames.
Modern software bloat isn't just about JavaScript web apps on the desktop. It is a systemic, multi-layered crisis spanning from the silicon up to the user interface, fueled by developer convenience, corporate surveillance, and economic traps that keep users locked in.
The most visible front of desktop bloat is the widespread adoption of web-runtimes-as-desktop-apps, spearheaded by Electron and similar execution environments. Historically, native applications compiled directly to machine code and linked against system dynamic libraries provided by the operating system. Today, almost every app running in your system tray bundles a Node.js runtime, a V8 Chromium engine, and heavy web assets.
"Software is getting slower more rapidly than hardware becomes faster."
Niklaus Wirth
If you run Slack, Discord, VS Code, Spotify, and Microsoft Teams simultaneously, you aren't running five native applications. You are running five separate, isolated web browsers, each consuming 500MB to 1.5GB of RAM to render what is essentially styled HTML and CSS.
Stock photo for illustration only, not from the actual event
Context and Analysis: The widespread resource inefficiency in modern software is largely driven by corporate pressures to maximize developer velocity and time-to-market. By relying on heavy framework abstractions rather than writing lean native code, companies trade off runtime efficiency for short-term economic gains, leaving powerful modern hardware to compensate for excessive software layers rather than serving the user directly.
Modern software development heavily prioritizes developer velocity over runtime efficiency. While this trade-off makes short-term economic sense for tech companies, it leads to staggering dependency chains. For instance, your 50 KB codebase might pull in a 2 MB dependency with dozens of sub-dependencies, alongside a 15 MB package and 1,400 deeper transitive dependencies just to pad a string or parse a date.
Furthermore, software today is rarely just a tool; it is an active data-extraction engine. When you launch a modern application, a significant portion of system resources is dedicated not to handling your input, but to measuring you through telemetry, serializing JSON, and transmitting user interactions to remote logging endpoints.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment