On Bloat

Open Source and “Accept Everything”

• Strong disagreement with the slide’s “true open source way: accept everything that comes.”
• Maintainers argue that accepting all contributions leads to scope creep, maintenance burden, and burnout.
• Others interpret it as tongue‑in‑cheek or as “accept PRs in principle, but help contributors fix them” rather than literal blind merging.
• Discussion clarifies that neither “cathedral” nor “bazaar” (e.g., Linux) actually means “merge everything”; real projects sit on a spectrum of review strictness.

What Counts as Bloat?

• Multiple notions:
  • Performance (slow UIs, long bank logins, FPS obsession).
  • Code/asset size (MBs of JS/CSS/HTML for simple pages).
  • Structural complexity (layers of indirection, over‑abstracted configs).
  • Feature bloat (high size‑to‑feature ratio, unnecessary options).
• Anecdote about needing half a day to change a button color due to cascading overrides is used as a vivid example of “bloat as indirection.”

Frameworks, Dependencies, and Transitive Complexity

• Heavy frameworks (web and otherwise) seen as major bloat drivers; you inherit authors’ bloat tolerance.
• Some developers avoid frameworks and stick to standard libraries, especially in languages already geared toward web backends.
• Others note business pressure and deadlines effectively force framework use (e.g., swapping a lean custom site for WordPress due to editors and marketing needs).
• Dependencies are defended as sometimes the only way to ship at all; alternative is “never ship” or needing “100 programmer‑years.”
• Tools like deps.dev and better dependency/performance analysis are welcomed and requested.

Is Web/Bank Bloat Economically Important?

• One side: banks and corporate sites are “good enough,” not losing meaningful business over latency; obsessing over FPS is seen as developer OCD.
• Opposing view: sluggish banking UIs and “enshittified” apps do cause user churn and frustration; fast, simple interfaces can be a competitive factor, even if not primary.

Human, Organizational, and Market Causes

• Claimed root cause: many developers prioritize tech toys (Kubernetes, microservices, flashy stacks) over understanding the business domain.
• Management and marketing are blamed for demanding “modern” architectures and long feature checklists to impress stakeholders, rewarding complexity over simplicity.
• Inside large companies, features may be built mainly to fuel promotions, then later quietly sunsetted as unused maintenance burdens.

Complexity Beyond Software

• Several comments link software bloat to broader societal complexity (tax code as analogy: layers added to fix issues, almost never removed, with opaque side‑effects).
• Some argue this path‑of‑least‑resistance—adding instead of simplifying—is a general human and institutional pattern.

Diagnoses and Proposed Remedies

• “Lack of vigilance and discipline” is seen by some as accurate but too abstract; others say naming the problem is still useful, culture has to change first.
• Suggestions include:
  • Being much stricter about features whose cost/benefit is unclear.
  • Avoiding unnecessary dependencies and monitoring dependency trees over time.
  • Better static/dynamic tools to highlight dependency bloat and performance hot spots.
  • Languages/runtimes that constrain what libraries can do (effect systems, sandboxing), so dependency compromise is less catastrophic.

Reception of the Talk

• Several readers found the content basic, aimed at juniors, or lacking in concrete solutions.
• Others appreciated it as a clear restatement of often‑ignored fundamentals and a prompt for discussion, even if not groundbreaking.
• Some critique the aesthetics of the simple slide deck; others argue that plain, fast, content‑focused slides themselves reinforce the anti‑bloat message.