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 :
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
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.
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.
HTMX relies almost exclusively on the server to update the state.
// START CUT IN VIDEO 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. // END CUT IN VIDEO 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.
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).
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?
But whatever path you choose, I’ll see you in the next video.