HTMX is the opposite of React
and other JavaScript frameworks. What do I mean by that? We’ll be covering what HTMX is, when it
is useful, what its limits are, and more. But First: what is HTMX? HTMLX was created by a guy called Carson Gross, and it stands for **HTML extension**,
as he explains on the website. The "extension" of HTML happens on two levels.
The most obvious one you see in the code: HTMX
extends the HTML attributes, adding `hx-`. For example in this code where
we define the on click behavior. 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: Here we have three attributes on the button: `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-select`, that is to say
the element with the ‘info-details” id. Then, because `hx-swap`is set to “outerHTML”, HTMX will swap out the entire selected element
with the HTML received from the server. 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.
HTMLX 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, even though I'm not
going to be changing all my APIs any time soon. 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. HTMLX 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? What is the point of communicating HTML
responses rather than something like JSON? The beauty of HTMX is that by taking the
HTML response 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. Or what if
you are wary of JavaScript’s quirks and weirdness? Or what if you're just in a context where
you're programming in PHP, or Ruby, or Python? The beauty of HTMX is that it
doesn’t restrict your choices. It jokingly refers to itself as the “HOWL” stack, H.O.W.L., 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, on the other end of the spectrum, 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. (And I have
videos to help you out with that.) 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, moving to HTML might be a big ask. But whatever path you choose,
I’ll see you in the next video.
