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

Original Article ↗ Hacker News Discussion ↗

Growing frustration with JavaScript’s dependency-heavy ecosystem is pushing some web developers away from React-based SPAs toward simpler server‑rendered stacks like Go or Rust with HTMX and minimal JavaScript. Commenters argue that frequent breaking changes, sprawling npm trees, and security‑driven upgrade churn create “dependency fatigue,” especially when libraries like routers and query managers evolve aggressively. Others counter that React itself is relatively stable and that teams can avoid much of this pain by limiting third‑party packages, choosing batteries‑included frameworks (e.g., Rails, Next.js), or updating dependencies in smaller, continuous steps.

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.