What HTMX adds to HTML

HTML already has a useful application model. A link or form sends an HTTP request, and the server returns the next document. HTMX extends that model. It does not replace it.

With HTMX you answer five questions directly in markup:

<button
  hx-post="/tasks/42/complete"
  hx-trigger="click"
  hx-target="closest li"
  hx-swap="outerHTML">
  Complete
</button>

• which event starts the interaction?
• which HTTP method and URL should be used?
• which element receives the response?
• how is the returned HTML placed there?

The server handles the request and returns HTML representing the new task state. HTMX swaps that fragment into the list. There is no JSON response followed by a second template in the browser.

That is the whole idea. The server owns validation, authorization, and rendering. The browser asks for the next useful HTML and puts it in the right place.

This works especially well when the server is already the source of truth. I reach for HTMX on admin panels, task lists, and forms where the backend already knows the rules. It is less suitable when a feature must manipulate large amounts of local state without contacting the server. A canvas editor or offline-first spreadsheet is a different tool choice.

Keep this cycle in mind for the whole course: event → HTTP request → HTML response → DOM swap. Every HTMX attribute changes one part of that cycle. When something breaks, walk the cycle left to right and you will find the step that went wrong.

Try this on your own project: pick one button that currently loads JSON and renders it in JavaScript. Sketch how the same interaction would look if the server returned finished HTML instead.