A 2024 plea for lean software

Original Article ↗ Hacker News Discussion ↗

Calls for “lean software” highlight growing unease with the complexity, size, and fragility of modern systems, from Electron desktop apps and cloud microservices to JavaScript projects pulling in thousands of npm packages. Commenters argue that deep dependency trees, feature bloat, and a culture of gluing libraries together expand attack surfaces and obscure code auditability, even as they accelerate development. Some see hope in richer standard libraries, better OS‑level abstractions, and cultural shifts toward fewer, more carefully designed dependencies, but note that current incentives, education, and economics still reward shipping fast over building small and robust.

Microservices and architectural bloat

  • Splitting monoliths into “hundreds/thousands of ultra-slim services” is seen by many as swapping code bloat for distributed-systems bloat.
  • Critics note added network complexity, latency, and a larger attack surface from many networked components.
  • Supporters mainly value enforced API boundaries and organizational scaling, but concede it’s no silver bullet.
  • Thread leans toward skepticism of ultra-fine-grained services and “function-as-a-service for trivial functions”.

Dependencies, package ecosystems, and “3‑line” libraries

  • Heavy criticism of npm/RoR/Node cultures where tiny conveniences pull in huge dependency trees.
  • Complaints that libraries try to “do everything” (I/O, networking, CLIs) instead of one thing well.
  • Others argue few fat, well-maintained, low-dependency libraries are preferable to many tiny ones.
  • Tree-shaking and tooling help, but don’t fully solve transitive bloat or supply-chain risk.
  • Some praise ecosystems with strong stdlibs (Python, Java, .NET, Kotlin), and Go’s stdlib-with-DIY style; others say Go omits too many everyday abstractions.

Rust, safety, and dependency surface area

  • One view: if Rust projects pull in far more code, non–memory-safety bugs and supply-chain risk may outweigh safety gains.
  • Counterpoint: many crates are split-out modules from one codebase, and a large share contain no unsafe code.
  • Debate over whether counting crates meaningfully reflects risk; interface and logic bugs can still dominate.
  • Consensus: memory safety is valuable, but deep, opaque dependency graphs still hurt auditability.

Electron, webviews, and app packaging

  • Electron criticized as archetypal bloat; alternatives like system webviews (Tauri, WebView bindings) discussed.
  • Tradeoffs: smaller downloads vs more syscalls, startup latency, and platform-specific quirks.
  • PWAs and Home Assistant–style local control are floated as leaner options, but gaps remain (APIs, storage, tooling).

Cloud, SaaS, and security/compliance

  • Some see “X as a Service” as marketing; others note real value in offloading CVE management and compliance pressure.
  • For nontechnical users, cloud backups may be safer than fragile local setups, though trust and education are recurring concerns.

Economics, incentives, and culture

  • Promotions and consulting incentives favor adding features, frameworks, and logos on architecture diagrams, not removing code.
  • Time-to-market and developer convenience routinely trump lean design, especially when hardware is cheap.
  • Some argue lean, maintainable systems are uneconomical against low-bid “glue everything together” solutions.

OS/stdlib design and long-term trends

  • Several argue that only richer, well-designed OS and standard library abstractions can truly reduce application complexity.
  • Examples: strong stdlibs reduce dependence on random packages; web components could have obviated large frontend frameworks but didn’t.
  • Others see containers as evidence we’ve “given up” on fighting complexity by just shipping bigger opaque bundles.

Nostalgia and attitudes toward bloat

  • Many reminisce about older systems (Win98/NT-era PCs, Apollo-era software, early Unix) feeling faster, simpler, and more understandable.
  • Some participants are tired of “size nostalgia,” arguing real-world impact on most users is small given SSDs and RAM.
  • Security-focused commenters counter that both attack surface and general defect surface scale with code size and layering, keeping lean concerns relevant.