When to Use htmx (and When Not)

htmx is a great fit for

• Server-rendered apps: admin panels, dashboards, CRUD apps, e-commerce, content sites, internal tools.
• Teams whose strength is a backend language (Python, PHP, Go, Ruby, Java, C#) and who don't want to maintain a separate JavaScript front end and JSON API.
• Adding interactivity to existing pages gradually, one attribute at a time.
• Projects where long-term simplicity matters: no build step and very few dependencies.

A JavaScript framework fits better for

• Highly interactive interfaces where the UI changes on every mouse movement: design tools, spreadsheets, maps, games, rich text editors.
• Offline-first apps, where the browser must work without the server.
• Products that already have a JSON API shared by mobile apps and a team skilled in React or Vue.

Many apps mix both: htmx for most pages, a React or Vue "island" for the one complex widget.

Client-side behaviour without a server round trip

Things like opening a dropdown or toggling a menu shouldn't need the server. Use:

• Plain HTML where it exists: <details>, <dialog>, the popover attribute.
• hx-on for one-liners.
• Alpine.js or hyperscript (made by the htmx authors) for small, declarative client state.

<details>
  <summary>Show filters (plain HTML, no request)</summary>
  <label><input type="checkbox" name="open" hx-get="/issues" hx-include="closest details" hx-target="#issues"> Open only</label>
</details>
<ul id="issues"><li>#12 Login bug (open)</li><li>#9 Typo (closed)</li></ul>

<!-- The pretend server: on a real site this part is your backend (Python, PHP, Node, Go...) -->
<script>
  server.get("/issues", (req) => req.query.open
    ? "<li>#12 Login bug (open)</li>"
    : "<li>#12 Login bug (open)</li><li>#9 Typo (closed)</li>");
</script>

Further reading

• htmx documentation
• Hypermedia Systems, a free book by the htmx authors
• htmx examples