Less Htmx Is More

Original Article ↗ Hacker News Discussion ↗

Plain HTML, Simplicity, and Longevity

  • Many comments echo the article’s theme: lean on plain HTML + CSS (with minimal JS) for resilient, long-lived sites.
  • People report that simple, multi-page sites without heavy frameworks are fast, robust, easy to archive, and keep working years later.
  • Concern that frameworks teach abstractions instead of HTTP/HTML fundamentals; some devs reportedly can’t explain basic form submissions.
  • Inline HTML event handlers are defended as often more reliable than modern “best practices” that require extra JS files and network requests.

What htmx Is (and Isn’t) Good For

  • Strong agreement that htmx shines for “MPA with sprinkles”: traditional server-rendered pages with partial updates and small interactive widgets.
  • Several argue htmx is not for SPA-like, heavy client-side apps; other tools (React, Gmail-style apps) fit that better.
  • Some see htmx as just one “frontend tech” among many, not a revolution; others like it precisely because it extends HTML semantics with little learning curve.
  • Examples: using htmx for inline forms, reactive table updates, dashboards where state lives on the server.

Turbo / Hotwire and Alternative Approaches

  • Some prefer Turbo/Hotwire’s philosophy: build fully functional no-JS pages first, then progressively enhance.
  • Turbo is seen as having navigation/“boost” behavior as a core, polished feature; htmx’s hx-boost is described even by fans as an “afterthought” mainly useful for fragment updates.
  • Debate over whether relying on future browser view-transition APIs is acceptable in serious products.

Navigation, History, and Back-Button Breakage

  • Many complaints about SPAs and JS routers mishandling the History API: broken back buttons, redirect loops, middle-click failing, internal navigation not restoring state.
  • Some blame frameworks; others blame app developers misusing redirects and routing primitives.
  • Suggestion that browsers could detect repeated back-click loops and auto-skip redirect entries, though feasibility is unclear.

SPA vs MPA, Latency, and Performance

  • One side: dynamic apps should push as much logic to the client as possible because users are more latency-limited than compute-limited.
  • Counterpoint: heavy JS bundles and client-side state duplication hurt users on slow devices and networks; server-rendered HTML (sometimes with htmx) has been faster in practice for some.
  • Disagreement over whether server-side interaction inherently means worse UX due to round-trip latency; some claim preloading, keydown-triggered requests, and HTML fragments mitigate this effectively.

Flicker, View Transitions, and UX

  • Some insist modern browsers already make full-page navigation nearly flicker-free for reasonably sized pages.
  • Others dislike SPA-style spinners and large JS payloads more than a 500 ms page reload.
  • The View Transition API intrigues some as a way to smooth navigation and table updates, but early experiences are mixed: limitations around animating real DOM elements and integrating with libraries like htmx are noted.

Tool Longevity and “Shiny Toys”

  • Skepticism that htmx will still matter in five years; suggestion to avoid new dependencies altogether.
  • Others point out htmx’s lineage (from Intercooler.js) and argue every stack is transient, so the “shiny toy” critique applies equally to React and friends.

Where htmx Fits Best (Consensus)

  • Good fit: server-owned state, mostly page-based apps, need for incremental interactivity without a full SPA stack.
  • Poor fit: highly interactive, desktop-like apps where complex client-side state and offline-ish behavior dominate.