Htmx and the Rule of Least Power

Original Article ↗ Hacker News Discussion ↗

Advocates of HTMX argue that enhancing server‑rendered HTML with small, declarative attributes can replace much of the complexity of modern JavaScript SPAs, aligning with Tim Berners‑Lee’s “rule of least power.” Commenters compare HTMX to React, Next.js, Blazor, Unpoly, and plain jQuery, weighing trade‑offs in maintainability, performance, long‑term stability, and developer experience, especially for CRUD‑style internal tools. Critics warn about potential template sprawl and limited guarantees versus “no‑JS” setups, while supporters counter that careful componentization, minimal JavaScript for edge cases, and simpler backend‑centric architectures can significantly reduce cognitive and operational overhead.

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.