A 2024 Plea for Lean Software

Original Article ↗ Hacker News Discussion ↗

Software has grown increasingly bloated, with even simple tools bundling huge dependency trees, heavyweight runtimes like Electron, and gigabyte-scale installers, raising concerns about security, performance, and waste. Commenters contrast this with leaner past and present alternatives, arguing that market incentives, developer skill sets, and cross‑platform demands push teams toward convenience over efficiency. Proposed remedies range from cultural change and better tooling to regulation and open APIs, though many doubt bloat can be meaningfully reversed.

Simple/self‑hosted vs user‑friendly services

  • Several comments note you can build extremely lean tools (e.g., basic image/paste sharing via web server + SSH/FTP/NFS + tiny scripts).
  • Others counter that non‑technical users live almost entirely in the browser; asking them to learn FTP/SFTP or mounts is a real barrier.
  • For self‑hosted family/friends, some argue you can just teach or pre‑install tools like FileZilla, SFTP filesystems, or sync tools instead of building custom upload frontends.

Image‑sharing example, performance, and privacy

  • Some criticize the article’s demo app for not resizing or optimizing images and serving full‑size thumbnails, calling this “optimizing the wrong thing” (binary size vs bandwidth).
  • Debate over EXIF: one side says failing to strip metadata is a serious privacy/security risk in many contexts; others say this is more about user responsibility or may be a feature for private sharing.
  • There’s disagreement over whether this makes the article “hypocritical” or just “unfinished.”

Incentives and causes of bloat

  • Multiple comments blame organizational incentives: shipping fast wins promotions; careful, lean engineering looks “unproductive.”
  • Bloat also results from safety/portability choices: shipping everything (drivers, runtimes, debug maps) is easier than trimming per‑platform.
  • Some argue bloat is inevitable as capabilities grow; others think it’s mostly developer culture and priorities.

Electron, web stacks, and GUI toolkits

  • Many see Electron and “web in a box” as emblematic of bloat (huge downloads, high RAM/CPU for simple apps).
  • Defenders note Electron dramatically lowers cross‑platform dev cost, leverages abundant web developers, and speeds UI iteration.
  • Alternatives mentioned: Qt, JavaFX, Avalonia, Tauri, Slint, native “heavyweight” apps like Telegram. Trade‑offs include licensing (Qt), tooling maturity, and hiring difficulty.
  • Some think without Electron, many desktop apps (especially on Linux) might not exist; others say native stacks are perfectly viable.

Libraries, packaging, and shared vs static

  • Discussion around Mesa’s size and where to “draw the line” between necessary complexity and over‑shipping.
  • Arguments for shared libraries (centralized, leaner on disk/RAM) vs static binaries (simpler deployment, fewer hidden dependencies).
  • Package managers can hide real complexity: apt install gives no clue whether you’re pulling in a full browser engine or a tiny static binary.

Is software quality getting worse?

  • One camp says modern apps (especially Electron) are clearly worse: trivial tools using hundreds of MBs of RAM/CPU and poor UX patterns compared to older native UIs.
  • Another camp says past software (e.g., 90s desktop) was also notoriously buggy and insecure; nostalgia may be bias.
  • A more nuanced view: there was a “golden period” (~2003–2013) with solid native toolkits and better engineering practices, followed by regression driven by web/mobile cross‑platform pressures.

Examples of bloat vs leanness

  • Reported bloat:
    • Notion Calendar ~84 MB.
    • Firefox as a Snap consuming hundreds of MB per version.
    • ClickHouse “client” binary ~900 MB because it bundles server/tools.
    • QGIS Windows installers around 1 GB and growing.
  • Leaner counterexamples:
    • Old Ventrilo client at a few MB and minimal RAM.
    • Some Qt/JavaFX desktop apps kept under ~30–140 MB and tens of MB of RAM with care.
    • A tool slimmed from 33 MB to 1.4 MB by removing unnecessary parts (details not fully described).

Regulation, supply chain, and APIs

  • New security legislation and long‑term update obligations are already pushing some organizations to rethink dependency sprawl.
  • Some suggest better tooling and lightweight formal methods for reasoning about huge dependency graphs, rather than expecting bloat to disappear.
  • Others argue for open APIs so users can choose lean alternative clients instead of being forced into official bloated ones.

Operating systems and security model

  • One line of discussion blames OS security models: past systems (e.g., floppy‑based setups) implicitly enforced simple capability boundaries, whereas modern OSes allow arbitrary code with broad access, making today’s massive dependency trees more dangerous.