The Future of Htmx

Original Article ↗ Hacker News Discussion ↗

Adoption and Team Dynamics

  • Many report resistance in larger orgs: “why not React/Angular, everyone knows it” and staffing concerns for a non‑mainstream tool.
  • Some use it in experiments or internal projects; production adoption is still tentative in many places.
  • Hiring, training, and long‑term maintenance weigh heavily in tech stack decisions, often favoring React.

Philosophy and Goals

  • Strong appreciation for “stability as a feature” and “no new features as a feature” amid JS ecosystem churn.
  • Emphasis on keeping logic on the server in “better-designed” languages and minimizing JS and NPM dependency bloat (e.g., SBOM/regulatory concerns).

When HTMX Fits vs. When It Hurts

  • Seen as very effective for simple to medium CRUD apps, forms, dashboards, and “boring” back‑office software.
  • Multiple reports that complexity shifts to HTML and backend for rich interactions (multi-area updates, complex forms, advanced error handling, carousels, virtualized lists), where SPA frameworks or Hotwire-style stacks can be a better fit.
  • Some explicitly treat it as a tool for server-driven UIs, not a React replacement for highly interactive apps.

Comparisons with Other Approaches

  • Back-end devs praise HTMX (and Hotwire/Turbo, Unpoly, Alpine, etc.) as a way to avoid full SPA stacks.
  • Front-end‑oriented commenters highlight React/Vue/Svelte as better for modularity, components, state management, and testing.
  • Debate over jQuery and vanilla JS: jQuery still widely deployed, but many see modern JS as “good enough”; others find jQuery’s API more pleasant.

DX, Testing, and Implementation Concerns

  • Some highlight simpler testing: mostly backend HTML fragment tests + a thin E2E layer.
  • Others argue HTML-output testing is brittle and miss frontend behavior; they miss Jest/Vitest-style component tests.
  • A few report real bugs (e.g., relative links, events) and find the single ~5k‑line htmx.js file hard to modify or reason about, though maintainers defend the “no build step, one file” design.

Accessibility and ARIA

  • Several question how dynamic partial updates affect screen readers.
  • Consensus: HTMX doesn’t handle ARIA automatically; developers must manage live regions, focus, and roles, ideally guided by better documentation and examples.
  • There’s a call for more explicit, tested a11y guidance in HTMX docs and examples.

Ecosystem, Tooling, and Future

  • Integrations like django-htmx, turbo-rails, templ, Vapor/Swift, and FastHTML are mentioned as important for making HTMX a “complete” solution.
  • Complex client components (datepickers, carousels, comboboxes) remain a weak spot due to lack of good vanilla JS libraries.
  • Triptych and standards work are seen as promising: long-term hope is for HTMX-like behavior to become part of the web platform itself.