I am currently asked one question every day. From the community, from customers, by email, by phone, on Discord, in the comments and in personal conversations, to name just a few examples. Since my recently published post Vanilla Web: The Frontend Trend 2024? interest has noticeably increased again. The question is: “What is your opinion about HTMX?”
Advertisement
Golo Roden is the founder and CTO of the native web GmbH. He is engaged in the conception and development of web and cloud applications and APIs, with a focus on event-driven and service-based distributed architectures. His guiding principle is that software development is not an end in itself, but must always follow an underlying professionalism.
I try to answer this question comprehensively and well-founded from my personal perspective. And if – which is unlikely but possible – you have never heard of HTMX: read this blog entry anyway. I am convinced that sooner or later the question will arise in your team: “Shouldn’t we take a closer look at HTMX?” So that you are not completely unprepared, but already have a rough idea of what HTMX is about, and perhaps have one or two arguments ready, I recommend that you read the following lines.
What is HTMX anyway?
HTMX is a compact library for web user interfaces and was originally named Intercooler.js. With the introduction of version 2, the name was changed to HTMX, so that HTMX 1.0 is basically the same as Intercooler 2.0. The main difference is that HTMX can be viewed as a new development that – unlike Intercooler – is not based on jQuery. HTMX takes a new approach in this regard.
On npm, HTMX currently has around 50,000 downloads per week. To put it into perspective: Svelte reaches almost a million downloads, Vue almost five million and React over 20 million. We will explain later why HTMX is not a niche technology. Until then, it is advisable to exercise some caution when interpreting HTMX download statistics on npm.
The mindset of HTMX
What makes HTMX stand out compared to other technologies such as React? The fundamental difference lies in the approach: HTMX relies on continuing to define web user interfaces in HTML instead of JavaScript, as is the case with React, for example. HTMX follows an HTML-centric architecture, unlike many other libraries and frameworks that focus on JavaScript. So you work with regular HTML and extend it with special attributes defined by HTMX. In this way, many standard tasks that would otherwise require JavaScript can be implemented completely declaratively in HTML.
Recommended editorial content
With your consent, an external YouTube video (Google Ireland Limited) will be loaded here.
Always load YouTube video Load YouTube video now
Some developers see this approach as something completely new. But in reality the concept is not new. Similar approaches have already existed in the past, such as with Knockout.js in 2010. Angular 1, the original version of Angular, also followed this principle in 2013. Interestingly, Intercooler, the precursor to HTMX, also dates back to that year 2013. Thus, HTMX adopts a way of thinking that is about a decade old. Since many developers either did not experience this phase themselves or simply forgot about it, the approach of bringing HTML to the fore and expanding it declaratively now appears to some as radically different and new, although in fact it is not.
Custom HTML attributes
At its core, HTMX works through the use of user-defined attributes. To give a simple example: imagine a div element to which you add the hx-post attribute, specifically hx-post=”/articles”. Normally the browser would ignore this attribute because it usually ignores unknown HTML elements and attributes. HTMX, however, revives this attribute: when you click on the div, thanks to HTMX, an HTTP POST request is made to the URL in the background /articles Posted. In this way, any HTML element can trigger a POST request, usually by clicking. For forms, a request is usually triggered by submitting it. This means that every element can be used to interact with the network. This functionality is not limited to POST requests, but also includes GET, PUT and DELETE. This means that every HTML element can initiate any type of HTTP request.
Now the question arises as to what happens to the result, i.e. the response sent back by the server. HTMX intercepts this and, sticking with the div example, sets the result as the new content of this div element. This means that the server response is displayed directly. Optionally, the result can also be displayed in another element. To do this, you also use the hx-target attribute and specify a CSS selector as the value, which determines the element in which the result should appear. In other words, HTMX makes it possible to execute an AJAX request using just two attributes without having to write a single line of JavaScript.
It is also possible to completely replace the entire element: just specify the hx-swap attribute. This allows you to choose how the result should be rendered: as inner or outer HTML, before the existing content, after the existing content, not at all, and so on. These few attributes alone make HTMX extremely flexible to use.
Loading indicators, animations…
It would of course be practical to have a charging indicator displayed during the charging process. In fact, HTMX allows any element to be defined as a loading indicator. Would you like an animation when the new content is displayed? This isn’t a problem with HTMX either, as it supports corresponding animations. Should communication not take place via a one-time HTTP request, but rather periodically, for example to update data, i.e. via polling? This can also be done with HTMX by setting a time interval. Do you prefer push communication? HTMX also allows you to use WebSockets. Alternatively, you can use Server-Sent Events (SSE), which was introduced with HTML5. And that is just a selection of the possibilities. For many standard applications, you no longer need to write JavaScript, just add a few attributes to your HTML and HTMX does the rest in the background.
By the way, HTMX also works completely without npm. It is enough to insert a script tag into your HTML and load HTMX from a Content Delivery Network (CDN). The size is only around 14 Kbytes. The system is even compatible with Internet Explorer, to name just a few advantages. So it is made really easy for you to use HTMX. The fact that HTMX is easy to integrate over a CDN is also why I mentioned earlier that npm’s download statistics should be viewed with caution. This only reflects how often HTMX was downloaded via npm, not how often it is loaded from a CDN or perhaps embedded directly into web pages – as was common ten years ago. Therefore, it is difficult to determine the true distribution of HTMX.
A hype – but for how long?
However, the prevalence is probably not nearly as widespread as the number of questions I am currently receiving about it suggests. There is a certain amount of hype surrounding HTMX, but it is likely to remain short and manageable. How long it will last and how sustainable it will be remains to be seen.
If the result of an HTTP request is rendered directly as inner HTML, what about APIs? Ultimately, the JSON, XML, or other data format that an API provides must be turned into something that can be represented in HTML. So there would have to be some kind of templating or something similar, right? But that is not the intended path. In fact, the server has to deliver finished HTML fragments. Admittedly, there are plug-ins for HTMX to be able to process JSON, among other things, but the documentation makes it clear what importance is given to this approach – namely an extremely low one.
To home page