Dependency management fatigue, or why I ditched React for Go+HTMX+Templ

Original Article ↗ Hacker News Discussion ↗

React, NPM, and Dependency Fatigue

  • Many commenters resonate with “dependency management fatigue” in the JS/React ecosystem: constant minor/major bumps, peer-dependency conflicts, and tooling churn (webpack → Vite, CJS → ESM, eslint config changes, etc.).
  • People note that even “simple” frontends quickly accrete routers, state managers, query clients, form libs, CSS systems, and build tooling, each with its own breaking changes.
  • Some say things are better than ~10 years ago, but still feel like “climbing out of hell a few circles.”

Is React Itself the Problem?

  • One camp: React core is small, relatively stable, and not the main issue; the real problem is the surrounding culture of adding many third‑party packages and updating them aggressively.
  • Others argue React’s “just a library” positioning forces you into the wider NPM ecosystem, unlike batteries‑included frameworks (Rails, Angular, Next) that centralize decisions and updates.
  • There’s debate over how often React and major React libs truly introduce “Python 2→3 scale” breaks; some report few issues, others describe constant migration work.

Alternatives: HTMX, Go, Rust, Rails, etc.

  • Many share positive experiences replacing SPAs with:
    • Go + HTMX + templ (or Go templates),
    • Rust (Actix/Axum) + Tera/Askama/Maud + HTMX,
    • Django/Rails/Laravel + HTMX/Hotwire/Alpine,
    • PHP APIs + HTMX, or Elm/ClojureScript on the front.
  • Claimed benefits: fewer dependencies, strong standard libraries, stable APIs, SSR by default, simpler mental model (URLs and HTML as the main state), single-binary deployment in some stacks.
  • Some emphasize that learning a stable stack deeply over years is only possible when churn is low.

HTMX and SSR Tradeoffs

  • Supporters say HTMX/SSR collapses an entire SPA layer (client routing, heavy state), leverages mature server frameworks for routing/auth, and can still handle moderately interactive UIs.
  • Skeptics argue complexity is merely shifted: templates get hairy, complex widgets still need JS, and HTMX itself has versions and migration guides.
  • Consensus: HTMX shines for “normal” apps and internal tools; highly interactive apps (e.g., spreadsheet‑like UIs, map canvases) still favor SPA-style frameworks.

Versioning, Security, and Process

  • Some advocate pinning deps and only upgrading for real security issues or needed features; others warn that deferring upgrades leads to painful multi‑year jumps.
  • There’s tension between wanting API evolution and valuing long‑term backwards compatibility; several contrast JS culture with ecosystems that treat breaking changes as a last resort.
  • Many conclude the root solution is cultural: add fewer deps, vet them carefully, and accept that every dependency is long‑term maintenance cost.