Getting Started with htmx: Interactive UIs Without a Framework

Not every interactive page needs a single-page-app framework, a build pipeline, and a few hundred kilobytes of JavaScript. htmx makes that case forcefully: it lets you build modern, dynamic interfaces using plain HTML attributes, where the server sends back HTML and htmx swaps it into the page. No client-side state to manage, no build step, no npm install required.

The core idea: HTML as the engine

A normal hyperlink or form can only do two things: GET a new page or POST and navigate away. htmx generalizes that. Any element can make any kind of HTTP request, and put the response anywhere on the page — without a full reload.

You drive it with a handful of attributes:

• hx-get / hx-post — the request to make (and the URL).
• hx-target — which element to update with the response.
• hx-swap — how to put the response in (replace the inner HTML, the whole element, append, etc.).
• hx-trigger — what event fires the request (a click, a keystroke, on load, on a timer).

The mental model is the opposite of a SPA. Instead of shipping JSON to the browser and rendering it with client-side templates, your server renders HTML fragments and htmx stitches them in. This is the hypermedia approach — the philosophy is laid out in depth in the free book Hypermedia Systems.

Install it

There’s no toolchain. Drop in one script tag:

<script src="https://unpkg.com/htmx.org@2"></script>

That’s the whole setup. (For production, pin a full version and add an integrity hash.)

A working example: live search

Here’s the canonical demo — a search box that queries the server as you type and drops results into a list, with no page reload:

<input
  type="search"
  name="q"
  placeholder="Search…"
  hx-get="/search"
  hx-trigger="input changed delay:300ms"
  hx-target="#results"
  hx-swap="innerHTML"
/>

<ul id="results"></ul>

Read it like a sentence: on input, once the value has changed, wait 300ms (debounce), then GET /search, and replace the innerHTML of #results with whatever comes back. Your /search endpoint just returns an HTML fragment:

<li>First match</li>
<li>Second match</li>

That’s a debounced, server-driven typeahead in a dozen lines, with zero custom JavaScript. Doing the same thing by hand means wiring up event listeners, managing the debounce timer, calling fetch, parsing JSON, and rendering the DOM yourself.

Swaps and triggers worth knowing

The power is in hx-swap and hx-trigger:

• Swap strategies — innerHTML (default), outerHTML (replace the element itself), beforeend (append, great for infinite scroll or chat messages), and delete.
• Triggers — click, submit, load, every 2s (polling), and modifiers like delay:, throttle:, and changed.

Combine them and a lot of “I need a framework for this” features — inline editing, lazy-loaded panels, infinite scroll, active search — become a couple of attributes.

When to reach for htmx (and when not to)

htmx is a great fit when your app is fundamentally server-rendered and you want islands of interactivity without the SPA tax. It pairs especially well with a backend that’s already producing HTML. If you’ve been following the industry’s swing back toward the server — the same instinct behind React Server Components — htmx is the minimalist take on that idea.

It’s not the right tool for genuinely app-like, highly stateful client experiences — think a collaborative editor or a complex dashboard with lots of interdependent local state. There, a reactive model built on signals earns its weight.

Either way, learning htmx is worth it: it sharpens your sense of what actually needs client-side state versus what you reached for a framework out of habit. To go deeper, the official htmx docs are concise and example-driven — and a refresher on how the DOM works will make every swap make more sense.