Htmx and the Rule of Least Power

Original Article ↗ Hacker News Discussion ↗

Adoption Experiences and Use Cases

  • Many back-end-focused developers report success using HTMX for internal tools (admin, CRUD, reporting, PR dashboards).
  • Common pattern: keep existing full-page server endpoints, use hx-select / out-of-band swaps to update only parts of the DOM. Backend often “doesn’t know” about HTMX.
  • Some use it alongside Tailwind (including via standalone CLI) without issue; JSX-style component reuse requires server-side rendering solutions.
  • Others choose alternatives in the same space: Unpoly, LiveView-like approaches (Blazor server-side), or minimalist HTMZ.

Pros Highlighted

  • Simpler mental model: “server does the thinking,” browser stays dumb; avoids complex SPA state management and npm build pipelines.
  • Easy incremental adoption: can add attributes to existing HTML, no need to build a full JSON API.
  • Fits well with traditional server frameworks (Django, Rails-like stacks, Flask, Ktor, Rust+templating).
  • Can implement patterns like infinite scroll, tabular data loading, multi-step forms, and validation via HTML + server responses.
  • Some argue it aligns with “rule of least power”: limited client-side capabilities, more predictable interactions, easier reasoning.

Concerns and Critiques

  • Worry about proliferation of endpoints/partials and “spaghetti” templates; others counter that careful componentization and returning full templates mitigate this.
  • Skepticism that complexity is merely shifted from client JS to server templates and routing.
  • For long-lived, evolving products, some argue SPAs (React, etc.) offer more flexibility and a larger hiring pool, especially for complex front-end state.
  • Some feel HTMX’s attribute syntax (especially event hooks) is “ugly” and can devolve into embedded logic in HTML.
  • GitHub issue responsiveness and small core team raise mild worries, though the codebase is described as relatively simple.

Testing and Tooling

  • For Django, opinions split between:
    • Using Playwright/Cypress-style end-to-end tests (heavier but realistic).
    • Relying on fast server-side tests that inspect HTML and headers (e.g., HX-Redirect) without a browser.
  • Suggestions include template-fragment tools (e.g., Jinja2 fragments) to avoid exploding partial files.

Performance and Scope

  • HTMX initialization via attribute scanning is reported fast except on very large pages.
  • Acknowledgment that HTMX suits CRUD-like, server-centric apps; high-frequency, client-heavy interactions (e.g., canvas apps, web3 UIs) may still favor SPAs.