Skip to content

HTMX: What’s Old is New Again

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


What’s old is new again, kind of. HTMX fits into that motto for me and it’s getting pretty popular, but at the same time It gets a lot of pushback. I’m going to take a step back and explain how we got to where we are in current web dev, which will explain what HTMX is.

YouTube

Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.

How did we get here?

So first, quickly, what is HTMX? If you’re unfamiliar with it, HTMX gives you access to AJAX, CSS transitions, WebSockets, and server-sent events directly in HTML using attributes. This allows you to build modern UIs with the simplicity and power of hypertext.

Let’s go back in time a little bit and think about traditional server-side rendering or even just static sites. When you navigate to a site, your browser hits the server, which could be serving server-side rendered HTML or a static file. That’s what you’re shipping back to the browser, and these could be full-page reloads.

Now, I have to say this because I’m an old guy: half of my career has revolved around server-side rendering. Whether it be PHP, Perl, ColdFusion, or other technologies, we were still rendering HTML and shipping that. Now, this payload could include JavaScript, which was ultimately rendered when the page loaded and executed, leading us to jQuery and beyond.

But once we got past that, where did we land? We ended up with the API of the XMLHTTPRequest, or what people call AJAX. For some reason, we decided to think of the browser not just as a rendering engine that executes and makes requests but rather to have pure JavaScript do everything for us. This allowed us to avoid full-page reloads and increase interactivity.

Instead of requesting HTML from the server, we started returning JSON or any structured data. Hence, it was called XMLHTTPRequest to begin with. We could take that JSON, mutate it, and transform it into something else we wanted to use within whatever framework or library we used on the client side, ultimately manipulating the DOM.

Resources != Database Records

One significant distinction was how we started treating resources as database records, whereas previously, we didn’t. A resource, some URI for some route, was ultimately what you were returning HTML for. When we began making actual HTTP calls via JavaScript, we treated those differently, thinking of them more as data and database records as entities in our system rather than as a composition of various things.

For example, if we’re returning JSON of an order, we might return something like this: an order with the order ID, when it was placed, the total amount, a status, and a customer ID that we relate to some other customer resource.

In HTML, we have the order number, when it was placed, the status, and the total. I’m also including the customer’s name and linking it with an anchor tag, allowing you to view that customer. Additionally, I included a form with a method of POST to actually cancel the order, where you select a reason and submit. While the data is the same, the representation is different.

There are two key differences when moving from server-side rendering to returning JSON. First, the data is essentially the same, but the representations differ; one is in HTML and the other in JSON. Secondly, in HTML, we’re using hypertext, which is a hypermedia format that includes hypermedia controls. The link tells your browser, “Here’s something else you can do,” allowing navigation via a GET request to the specified URI.

Similarly, with the form, we define the method as POST, indicating where the browser should send the request. This highlights the significant difference between JSON and HTML, where HTML provides additional controls and context.

A closer representation in JSON would also provide information for other actions and navigations.

This still requires your JavaScript client to understand this particular format, just as your browser understands HTML. It’s all about representations, and I’m demonstrating a simple example of showing order details.

HTMX

This is where HTMX comes in, stating that the primary representation you’re going to use is HTML, and we’re going to leverage that. Why? Because we can see the ideas of hypermedia controls. Let’s extend that further to return HTML while maintaining interactivity, similar to what we accomplish with JavaScript and JSON.

HTMX’s motivation is clear: why should only anchor tags and forms be able to make HTTP requests? Why should only click and submit events trigger those HTTP requests? Why should we limit ourselves to just GET and POST methods? HTMX leverages the ideas of hypermedia controls and extends what is available to you by default in the browser.

Here’s an example of HTMX in action. I won’t go into the specific details of how to use it, but I want to illustrate the flow and concepts involved.

In our original state, we display a “Click to Edit” form. When we click this button, HTMX makes an HTTP GET request to the specified URI and replaces the HTML returned with the inner HTML of the targeted div. This is the response from our server:

When we submit the form, HTMX performs an HTTP PUT request to the specified URI, passing all the data from the form just like a regular form. The server then returns back the initial HTML I illustrated above with the new values. If we click cancel, the button makes a GET request back to the server getting the original HTML.

This is why I say, “What’s old is new again.” We seem to have lost our way in leveraging HTML, relying too heavily on JSON and manipulating the DOM through libraries and frameworks.

You might wonder if you have to return JSON because other third-party consumers are using it. In that case, sure, nobody’s suggesting using HTMX for that purpose. However, if you’re leveraging HTML as your primary representation and want to use HTMX in your context, it could be entirely suitable. Many web applications are built returning JSON and performing unnecessary transformations when you really don’t need to.

Hopefully, this discussion about hypermedia and hypermedia formats, whether HTML or JSON, provides you with new ideas to explore.

Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.

Leave a Reply

Your email address will not be published. Required fields are marked *