Did we lose our way in making efficient software?

Original Article ↗ Hacker News Discussion ↗

Complaints about a 30 MB Word document choking Google Docs while opening instantly in native editors have reignited concerns over software “bloat” and declining efficiency. Commenters point to web stacks, heavy frameworks, containerized deployments and business incentives that prioritize developer speed, features and SaaS models over performance and resource use, even as hardware has grown vastly more powerful. Some argue modern functionality, graphics and convenience justify the trade‑offs; others see a systemic tragedy of the commons where the cost of inefficiency is pushed onto users and the environment.

Perceived Software Bloat & Regression

  • Many compare 90s-era apps (Word on a 386, QNX demo floppies, early Macs) to today’s gigabyte‑scale software and feel we’ve lost efficiency without proportional benefit.
  • Users report modern machines with 8–32 GB RAM feeling as “slow” as older systems once did, especially with browsers, Electron apps, Slack, Google Docs, etc.
  • Others argue that relative to hardware growth, current apps are not more bloated than in the past.

What We Gained

  • Cited gains: rich graphics, Unicode and internationalization, high‑DPI UIs, composited desktops, crash handling, collaboration, track changes, spell/grammar checking, global fonts, complex document formats, cross‑platform frameworks.
  • Some note many of these could be implemented far more efficiently; the current cost is mostly due to choices and shortcuts, not hard technical limits.

Root Causes & Incentives

  • Common theme: business incentives favor developer time, time‑to‑market, frameworks, and SaaS revenue over runtime efficiency.
  • “Hardware is cheap” mentality and containers (e.g., 6+ GB Docker images) exemplify trading resource use for simpler builds and distribution.
  • Bloat is described as an “externality”: developers don’t directly pay for wasted CPU/RAM/energy; users and the planet do.

Web vs Native

  • Browsers, JS, DOM, and frameworks are widely blamed for sluggishness, especially on large documents or long comment threads.
  • Some argue high‑performance web apps are possible but require discipline and careful architecture that are rare under current pressures.
  • Others point out native isn’t automatically better; poor algorithms and data structures can make native apps just as slow.

Platforms, Lock‑In & Distribution

  • Friction around native apps: paid dev accounts, mandatory signing/notarization, app‑store fees, code‑signing certs, and platform‑specific UI stacks push many toward web apps.
  • There is debate over whether store cuts (15–30%) and tax/chargeback handling are “worth it” versus payments via Stripe or similar.
  • Cross‑platform UI remains fragmented; lack of a common native API and heavy frameworks (Qt, Electron, Java UIs) push some developers to the browser.

Attitudes & Culture

  • Many blame current engineering culture: “premature optimization is evil,” resume‑driven framework choices, and feature‑count metrics.
  • Others stress that the real missing piece is incentives and process: high‑quality, efficient code takes time that organizations rarely reward.