Some software bloat is OK

Interpreting “Premature Optimization”

• Many argue the famous Knuth line is widely abused: people hear “don’t optimize” instead of “don’t optimize before profiling / identifying critical paths.”
• Several commenters stress:
  • Always think about performance while designing.
  • Optimize only once correctness and requirements are stable.
  • Avoid “stupid slow” patterns when a faster alternative is equally clear and simple.
• Others note that business pressure often ships products after “make it work,” skipping “make it right” and “make it fast” entirely.

Bloat, Complexity, and Maintainability

• One camp: layers, frameworks, and abstraction can improve modularity, extensibility, and maintainability.
• Counterpoint: those layers also create “unknowable” systems — too many indirections, dependencies, and frameworks make debugging into archaeology.
• Several argue bloat and complexity are intertwined: complexity is not treated as a first-class problem, so each “reasonable” local decision leads to globally bloated systems.

Web, Electron, and Frontend Frameworks

• Strong debate around Electron and web stacks:
  • Pro: Electron/React/etc. ship faster, enable cross-platform UI, and are “good enough” for many CRUD‑style apps and internal tools.
  • Con: large installers, RAM use, sluggish UIs, and battery drain are seen as unjustified for simple apps; many cite Teams, Firefox-as-snap, etc. as horror stories.
• Some advocate native webviews or Tauri as a more size‑efficient middle ground, while others note memory use is still dominated by browser engines.
• React and similar frameworks are heavily criticized by some as overcomplex, wasteful, and unnecessary for most sites; they advocate SSR + light JS or DOM‑attached components instead.
• Others defend Vue/Svelte as distinct from React and argue that once you have real client-side logic, bare DOM APIs are painful.

Context and Lifecycle Matter

• Several emphasize that “some bloat is OK” only relative to:
  • App lifecycle (quick POC vs. core OS component).
  • Usage pattern (niche scientific visualization vs. casual portal).
  • User base (internal enterprise vs. billions of end users).
• Bloat is seen as more acceptable when alternatives are clearly worse or development speed is critical; less so when it becomes a permanent dependency or core system tool.

User Experience, Hardware, and Environment

• Many resent that everyday tools feel slower than decades-old games/OSes despite vastly better hardware.
• Concerns include: UIs lagging behind keystrokes, battery life (especially for Electron apps), bandwidth and storage assumptions that ignore rural/low‑resource users.
• Some note that “using all resources” is not inherently good: users may prefer many lightweight apps over a few heavyweight ones.

“Bloat Needs Bloat” and System-Level Effects

• Commenters point out that:
  • Security, containers, and elaborate error reporting are partly reactions to existing bloat and dependency sprawl.
  • Frameworks that ship their own stacks duplicate what OS/toolkits once shared.
• There is nostalgia for earlier Android and desktop eras where modest hardware still felt fast; today’s resource gains are perceived as mostly soaked up by layered abstractions.

Philosophical Takes

• Some argue all bloat is bad, but tradeoffs sometimes justify accepting it knowingly (like tech debt).
• Others link bloat to Conway’s law and standardization: general-purpose standards and libraries are inevitably heavier but convenient and reusable.
• There’s a recurring call for a culture that prizes simplicity, negative lines of code, and deep understanding over stacking abstractions “because developer time is expensive.”