The core idea of htmx is to replace the approach commonly used by modern Web Applications these days that talk to a server using JSON (primarily) and then build the user interface client-side.

Instead of sending JSON from the server to the client, we send HTML.

Imagine you want to get some users data to embed in a list. You ask this data to a /api/users endpoint. It sends you this:

{
  "users": [
    { "name": "First user" },
    { "name": "Second user" },
    { "name": "Third user" },
  ]
}

Now you (the client) must render this data to the user, building the HTML (that is what the browser can interpret) client-side.

With HTMX, you’d see a list like this coming from the server, returned as an HTML partial (not a full HTML page, just some HTML tags):

<ul>
  <li>First user</li>
  <li>Second user</li>
</ul>

and this reply is automatically shown on the page by htmx, you just describe where you want to show it, and it’s all automatic.

This is a simple example, but you can already see how mind-shifting htmx can be if you’re used to passing JSON around, like we’ve been doing for years and years.

With htmx, API endpoints are more UI-aware. They’re not pure isolated data-spitting HTTP routes. They become active parts of the application.

This was one big idea of htmx: JSON -> HTML.

Another big idea is that we can fully use all the HTTP verbs from HTML (which is otherwise limited to GET and POST) and also send PUT, PATCH and DELETE requests.

And, we can send those requests from any HTML element, not just forms (and links, for GET request).

Those requests can be triggered by any event we want, and we describe (using special htmx attributes) what should happen.

We’ll see this soon in practice.

One important thing to note is that htmx is backend agnostic, we can use any backend that can render an HTML partial (basically, any backend).

Lessons in this unit: