Currently one question is asked every day. From the community, from customers, via email, over the phone, on Discord, in comments and in personal conversations, to name a few. Since my recently published article Vanilla Web: The Frontend Trend 2024? Interest increased significantly again. The question is: “What do you think about HTMLX?”
advertisement
Golo Roden is the founder and CTO of Native web GmbH. He is involved in the design and development of web and cloud applications and APIs, with a focus on event- and service-driven distributed architectures. The guiding principle is that software development is not an end in itself, but must always follow basic professionalism.
I try to answer this question comprehensively and based on solid foundations from my personal point of view. And if – unlikely but possible – you've never heard of HTML: 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 HTMLX is about, and maybe have one or two arguments ready, I recommend reading the following lines.
What is HTML anyway?
HTMLX is a built-in library for web user interfaces and was originally named HTMLX Intercooler.js. With the introduction of version 2 the name was changed to HTMX, so HTMX 1.0 is basically the same as Intercooler 2.0. The main difference is that HTMLX can be viewed as a new development that – unlike Intercooler – is not based on jQuery. HTMLX takes a new approach in this regard.
At npm, HTMLX currently has about 50,000 downloads per week. To put it in perspective: Svelte has nearly one million downloads, Vue has nearly five million, and React has more than 20 million. We'll explain later why HTMLMX is not a niche technology. Until then, some caution is advised when interpreting HTML download statistics on npm.
HTMLX mentality
What makes HTMLX stand out compared to other technologies like React? The main difference is in the approach: HTML is based on continuing to define web user interfaces in HTML rather than JavaScript, as is the case with React, for example. HTML follows an HTML-centric structure, unlike many other JavaScript-centric libraries and frameworks. So, you work with regular HTML and extend it with special attributes defined by HTMLX. In this way, many standard tasks that require JavaScript can be implemented entirely declaratively in HTML.
Recommended editorial content
With your consent, an external YouTube (Google Ireland Limited) video will be uploaded here.
Always upload a YouTube video
Some developers see this approach as something completely new. But in reality this concept is not new. There have already been similar approaches 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, a precursor to HTMX, is also making a comeback Until 2013. Thus, HTML adopts a way of thinking that is about a decade old. Since many developers have either not experienced this stage themselves or have simply forgotten about it, the approach of bringing HTML to the fore and extending it declaratively now seems to some to be radically different and new, even though in reality it is not.
Custom HTML attributes
At its core, HTMLX works by using user-defined attributes. To give a simple example: discipline yourself div
-The element you want the attribute in front of hx-post
Add specifically hx-post="/articles"
. The browser usually ignores this attribute because it usually ignores unknown HTML elements and attributes. However, HTML revives this attribute: if you click div
Click, thanks to HTMX, an HTTP POST request is sent to the URL in the background /Articles to publish. This way, any HTML element can trigger a POST request, usually via a click. For forms, the request is usually triggered by submitting it. This means that each 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 each HTML element can initiate any type of HTTP request.
Now the question that arises is what happens to the result, i.e. the response sent by the server. HTML intercepts this and flags it accordingly div
-Example of survival, result as new content this div
-Elements. This means that the server response is displayed directly. Optionally, the result can also be displayed in another item. The theme is also used for this purpose hx-target
It specifies as the value a CSS selector that specifies the element in which the result should appear. In other words, HTMLX allows an AJAX request to be executed using just two attributes without having to write a single line of JavaScript.
It is also possible to replace the entire item: just write that hx-swap
Describe. This lets you choose how to display the result: as internal or external HTML, before existing content, after existing content, not at all, etc. These few attributes alone make HTMLX very flexible to use.
Loading indicators and animations…
It would of course be practical if the charging indicator was displayed during the charging process. In fact, HTMLX allows any element to be defined as a loading indicator. Would you like an animation when new content is displayed? This is not a problem with HTML either, because it supports corresponding animations. Should the connection not be made via a one-time HTTP request, but rather periodically, for example to update data, i.e. via polling? This can also be done using HTMLX by specifying a time interval. Do you prefer to communicate by paying? HTML also allows you to use WebSockets. Alternatively, you can use Server-Sent Events (SSE), which were introduced with HTML5. This is just a selection of possibilities. For many standard applications, you no longer need to write JavaScript, just add some attributes to your HTML and HTML will do the rest in the background.
By the way, HTML also works perfectly without npm. It is enough to insert the script tag into your HTML and load the HTML from the Content Delivery Network (CDN). The size is only about 14 KB. The system is also compatible with Internet Explorer, to name a few advantages. So it becomes easier for you to use HTMLX. The fact that HTMX is easy to integrate via CDN is also the reason why I mentioned earlier that npm download statistics should be viewed with caution. This only reflects the number of times HTMX has been downloaded via npm, not the number of times it has been uploaded from a CDN or perhaps embedded directly into websites – as was common ten years ago. Therefore, it is difficult to determine the true distribution of HTMX.
Hype – but for how long?
However, the outbreak may not be as widespread as the number of questions I currently receive about this topic suggests. There is a certain amount of hype surrounding HTMX, but it will likely remain short and manageable. It remains to be seen how long it will last and how sustainable it will be.
If the result of an HTTP request is displayed directly in internal HTML, what about the APIs? Ultimately, the JSON, XML, or other data format provided by the API must be converted into something that can be represented in HTML. So there must be some kind of template or something similar, right? But this is not the intended path. In fact, the server must deliver the final HTML fragments. Admittedly, there are HTMX plugins to be able to process JSON, among other things, but the documentation makes clear the importance given to this approach – which is very low.
“Certified tv guru. Reader. Professional writer. Avid introvert. Extreme pop culture buff.”
More Stories
Remotely controlled cargo ships coming soon on the Elbe Canal?
Siemens technology makes Baden Canton Hospital smart
Discovering an ancient Mayan city – what do the rainforests hide?