htmx lets you build interactive UI by returning HTML from your existing backend, not JSON that a frontend framework turns into HTML. If you already have server-rendered templates and don’t want to stand up a separate SPA build pipeline, this is the shortest path to interactivity.

The core idea

Instead of a REST endpoint returning JSON and a JS framework rendering it, your endpoint returns an HTML fragment, and htmx swaps it into the page.

<button hx-post="/like" hx-target="#like-count" hx-swap="innerHTML">
  Like
</button>
<span id="like-count">42</span>

Your server handler for /like:

@app.route("/like", methods=["POST"])
def like():
    count = increment_like_count()
    return f"<span id='like-count'>{count}</span>"

Click the button, htmx sends a POST, your server returns a fragment of HTML, htmx swaps it into #like-count. No client-side state management, no JSON serialization layer, no separate render logic on the frontend.

What you don’t need anymore

• A separate API layer. Your endpoints return HTML your templates already know how to generate — same templating engine you use for full pages, just rendering partials.
• A frontend build step. htmx is a single script tag, no bundler, no JSX compilation.
• Client-side state syncing. The DOM is the state. There’s no client store that can drift out of sync with the server, because the server is the one producing the markup.

Common attributes you’ll actually use

A debounced live search, no JS written:

<input
  type="text"
  name="q"
  hx-get="/search"
  hx-trigger="keyup changed delay:300ms"
  hx-target="#results"
/>
<div id="results"></div>

Where it breaks down

• Complex client-only state. A multi-step wizard with client-side validation before any server round trip, or a drag-and-drop board reordering optimistically — htmx can do parts of this, but you’re fighting the tool past a certain complexity. That’s a sign you want real client-side state, not more hx-* attributes.
• Offline-first or heavily optimistic UI. htmx’s model is request-then-swap. If your UI needs to update instantly before the server confirms (optimistic updates with rollback), you’re back to writing JS state management.
• You already have a JSON API you can’t change. htmx wants HTML back. If your backend is committed to JSON responses for other clients (mobile apps, third parties), you either add HTML-returning endpoints alongside the JSON ones, or htmx isn’t the right fit here.

The honest tradeoff

You trade a large, well-understood ecosystem (React’s tooling, component libraries, state management patterns) for a much smaller surface area and a return to server-rendered thinking. For CRUD-heavy internal tools, admin panels, and content sites with sprinkles of interactivity, that trade is a clear win — less code, one less build pipeline, and your existing backend skills carry the whole feature. For a real single-page application with heavy client state, it isn’t the right tool, and reaching for it there just means reimplementing a state manager one hx-swap at a time.