Why I use htmx

I recently introduced this notion of the “AHA Stack” - a set of tools I’ve been using with great satisfaction to create things on the Web.

A big, probably the most novel, thing in the AHA Stack is the H part: htmx.

htmx is a super interesting library.

Indie (not provided to you by a FAANG), simple, written in a single JavaScript file in ~3800 lines with no build step, htmx defines itself as an “extension of HTML”.

It brings a few brilliant ideas.

In particular I can mention it makes it possible that:

• any HTML element can initiate an HTTP request (not just forms or links)
• any event can trigger an HTTP request
• you can use all HTTP methods (PUT, DELETE, PATCH) declaratively in addition to GET (forms and links) and POST (available only to forms in HTML)

Those 3 ideas alone are genius.

Plus, we have the biggest change in thinking compared to traditional JS frameworks: you ship HTML over the wire.

Using those ideas I can create interactions and experiences that would otherwise require me to write a ton of JavaScript, depend on a big pile of JavaScript dependencies and hundreds of npm packages, to execute a ton of JavaScript on the client side.

It’s a brilliant little library, with no dependencies, that you install through a script tag. It’s backend-agnostic.

We use htmx to handle client-server HTTP communication once the page is loaded.

So for example the user clicks a link, and we load some data from the server, which we get back as HTML, and we add it to the page dynamically.

And we do this in a way that’s declarative.

Not imperatively writing JavaScript to tell the page what to do, instead, we go up a level of abstraction, and declare what we want it to do.

I’ve written extensively about htmx on The Valley of Code and you should check that out if you want to learn more.