HTMX, the anti JavaScript framework (vs React)

HTMX is the opposite of React and other JavaScript frameworks. What do I mean by that? And when would you want to use HTMX rather than a frontend framework? We’ll be covering what HTMX is, when it is useful, and its limits.

First: what is HTMX?

HTMX was created by a guy called Carson Gross, and it stands for HTML extension, as he explains on the website. Now the extension of HTML happens on two levels.

Extension 1 : HTML syntax

The most obvious one you see in the code: HTMX extends the HTML attributes, adding hx-, for example in this code :

<div hx-on:click="alert('Clicked!')">Click</div>

However, that example is an exception: most of the HTMX extensions are focused on communicating with the server and dealing with the response. For example, let’s take a look at the following code:

<div>
    <button hx-get="/info" 
            hx-target="#info-details" 
            hx-swap="outerHTML">
        Get Info!
    </button>
</div>

Here we have three attributes: hx-get describes the AJAX call that will be made to the server, namely the GET call to the /info route.

When the response is received, HTMX will then find the element in the DOM designated by hx-target, i.e. the element with the ‘info-details” id.

Then, because hx-swapis set to “outerHTML”, HTMX will swap out the entire selected element with the HTML received from the server.

Extension 2 : HTML as the message & the state

And that brings me to the second extension. In the React world, we use the HTML page as the “thing that hosts the application”.

But here, HTML is more than that. HTMX supposes the server will respond with HTML. HTML is also the message and the state holder.

Like me, you might find it weird to imagine an API responding in hypertext rather than say, JSON. The HTMX website points to a blog post by Roy Fielding, who came up with the idea of REST. That post is entitled “REST APIs must be hypertext driven”, which probably gives you a good idea of where he stands on the issue. And I kind of see the point.

Remember that REST means Representational State Transfer Application. JSON is excellent at serialising data in a human-friendly way. But you expect that data to follow a fixed shape.

This means the JSON won’t change shape based on the state. But then to what extent can it be the expression of the state in ReST, as opposed to just stateless data?

Carson uses the example of a bank account interface, where the “drawn money” action would be disabled based on how much money is in the account. Of course, you and I can easily imagine how we could wrangle the JSON to include that information.

But my default reflex would be to set up some logic in the interface to adapt to the data. And that’s fine, to my mind.

However it’s not the path HTMX has taken. HTMX doesn’t expect any client-side logic to update the interface state based on the JSON.

In fact, HTMX shies away from that responsibility.

It purposefully puts the responsibility of updating the display state squarely on the backend’s shoulders.

This is why you could say that although it is a JavaScript library, HTMX is (in fact) an “anti JavaScript Framework”. A JavaScript framework essentially manages the state on the client and updates the HTML based on that state.

HTMX relies almost exclusively on the server to update the state.

Now obviously, there is state that is completely specific to the interface — for example, is the interface in dark mode? Or is the dropdown menu open?

HTMX (and Carson) have no objection to that state being stored on the client side. However, it _is _ strongly opposed to more meaningful state being stored by the client.

And that naturally brings me to my next question: Why choose HTMX? Under what circumstance does it make sense to go with HTMX rather than a client-side framework, say, React?

Or, to phrase things slightly differently: what is the point of HTMX? What is the point of communicating HTML responses rather than something like JSON?

Second, Why choose HTMX?

The beauty of HTMX is that by taking the road, it is able to provide a “Single Page Application” like experience that is solely driven by the server.

Of course, you’re probably aware that React has started taking over server-side responsibilities. Theo makes the point that React and NextJS and other frameworks have expanded the domain of front-end developers. They have given front-end development state management powers. That started client-side with front end frameworks. And now, with NextJS and RSC leading the charge, that also includes the server.

And running on the server makes sense because that is where permanent data lives.

The beauty of this approach is that you don’t need to switch languages between the client and server-sides. Switching languages requires even more mental gymnastics than switching contexts, so I’m all for keeping things unified.

But server-side React keeps you firmly in the JavaScript and TypeScript world. What if you’re a backend developer who is wary of JavaScript’s quirks and weirdness?

The beauty of HTMX is that it doesn’t restrict your choices. It jokingly refers to itself as the “HOWL” stack, where HOWL stands for “Hypertext On Whatever you’d Like).

That means you can render that HTML content and provide an SPA experience with whatever server-side language you like without locking yourself into the JavaScript world.

This means HTMX is doing the opposite of what React does, and is another reason why HTMX is an “anti JS framework”. HTMX extends the domain of backend development into frontend territory.

And so to me, the fundamental question of who might profit from learning and using HTMX comes down to two things.

First, where should your state live, and how much do you trust your users? Web applications live on a spectrum, ranging from banks on one end all the way to arcade games on the other.

An arcade game’s state:

• is complex,
• it needs to change quickly
• and it has no real-world implications,

so it lives on the client. For applications with client-side state and client-side logic, it makes sense to use a client-side framework.

Conversely, Banks don’t trust their users, so all the state and all the logic lives on the server. And if you’re in that situation, you may be better off using HTMX rather than a front-end framework.

To frame things differently, the question is also: What kind of developer do you view yourself as?

Are you a front-end javascript developer who is server-side curious? You’re probably better served understanding how NextJS and React work.

Are you a server-side developer who doesn’t care for JavaScript? HTMX is probably a good fit for you, although it does require your client-side-facing APIs speak HTML. In my experience, that isn’t usually the case. If your APIs are already set up, getting them to accept HTML might be a big ask.