HTMX is awesome and here's why

What if you could supercharge your HTML with AJAX requests, CSS transitions, and web socket capabilities directly from HTML attributes? That's what HTMX can do for you. We're discussing its benefits and drawbacks in this episode.

Highlights
00:00 Introduction to HTMX
01:16 Triggers and Functionality
02:06 Benefits and Use Cases
03:26 Making static WordPress interactive
04:19 Modern JavaScript Frameworks vs HTMX
05:25 Areas for Improvement
08:15 Final Thoughts

Links
- HTMX Official Website: https://htmx.org/
- Alpine.js: https://alpinejs.dev/
- Tailwind CSS: https://tailwindcss.com/
- Mutation Observer: https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

Steffen: 0:00

Hey Dominik, what do you know about HTMX?

Dominik: 0:07

Yeah, htmx is a library that has gained some traction lately again. That allows you to do like AJAX stuff, css transitions, web sockets, server-side events directly in your HTML using attributes like basically these kind of directives, and if you go to their website you will have some basic examples that you can basically add these HX-minus or HX-directives anywhere in your code and it will like do some interactive stuff. For example, if you click a button here, it will issue actually a post request via AJAX and replace the outer HTML of this given document, the response that you get. And, yeah, you can like on the website. There are a couple of more examples that you can go into, like, for example, edit stuff, where you use it to post like a form with the put request to a given URL or to a provided URL and it says like it should use the current or this as a current target and swap the outer HTML with the response, and then you have like this document here. So it basically extends the functionality of the browser from just like making simple get and post requests to a lot more like dynamic stuff that you can do, and even like you can with the response.

Dominik: 1:29

You can do is like a lot of things like select certain elements from it that you want to replace. You can replace the element that you currently clicked on or that was triggered somehow and then, or you can replace any other element on the page. You have different triggers. It doesn't need to be a click. It can be also a scheduled like polling thing where you say every two seconds you want to trigger something, or on mouse enter or on like key presses and so on. So it actually gives you a lot of functionality where you would usually write a lot of JavaScript out of the box just with like HTML attributes.

Steffen: 2:06

Yeah, and I really love this approach just because it reduces the complexity so much, especially with things like state handling.

Steffen: 2:16

One example, like when we create a post archive in WordPress where you want to filter certain posts like by category, but then also by tags, and I have multiple buttons and things. Then when you want to do that in a dynamic way with JavaScript, with Ajax request, the state handling can get very, very complex very quickly, whereas with the HTML approach you don't need to write much complex code because you can quickly go from a static version that you have created anyways already, kind of with a static code that you generated on the server side, to a very interactive version by just defining this relationship of the interactive buttons and drop downs and the container of the post that you want to replace when you filter things. So it really offloads a lot of work in terms of the workload from the client side to the server side, but also a lot of the thinking, I feel like from complex react components and stuff like that to a rather simple HTML directive that is easy to work with.

Dominik: 3:26

Yeah, this is actually what we have been teaching also developers that come to us and work with us a lot of the times. Right, because, like WordPress, out of the box gives you a lot of stuff with like rendered HTML pages but like static or like real routes, like you have the archive pages, you have pagination, you can already query or filter by categories through, like you are parameters, like query parameters and so on, and this is already there and now you just have to make it interactive. And this is where actually this shines. Right, because, like before, we actually wrote a lot of like JavaScript to do that, like custom JavaScript, but now you can just do that with attributes and you also don't need to add like WP rest API endpoints or something like that get like a different data source, but you can actually work with the existing HTML pages that you already have, right, and just like a progressively sort of enhance them to be more interactive, also can be used with like any back end language, right?

Dominik: 4:21

So nowadays, a lot of talk is going on, like in these modern JavaScript frameworks, where you want to have like server side rendering and client side rendering and you want to like make the best experience possible with that, but not everyone can actually switch their entire stack to just JavaScript only and not everyone wants to do that.

Dominik: 4:39

So for people that are stuck with like a different back end language kind of, or want to use a different back end language, that's a great way to integrate easily some interactivity to the side. Also, you don't really need a build process right, because you just write stuff in your HTML and you include, like the, the library by a script tag and basically in in in the same like vein of like Alpine JS or Tailwind JS, where you use HTML like your component code or whatever, or your HTML code as like you add everything that is related to this code inside of a single file and you don't have to go out and like create a separate CSS file, a separate JavaScript file, to add like this stuff. And this is also what I really like about it.

Steffen: 5:25

So that's all great, but what are the things that you would like to see improved actually?

Dominik: 5:31

Well, there's always something right that you can improve, but for me, what actually also prevents me from adding that to all of our projects? It's like it's a monolith file and it is like 14 kilobytes of minified and G zipped JavaScript. This doesn't sound like a lot, but I feel it quite is a lot, especially if you look at the size of the JavaScript that normally our websites have. It's actually quite big. Then it's not possible to code split it or to lazy load it, and I would really like to see like these kind of things, especially like the lazy loading to me, and it feels like there is a lot of like as in stuff going on, or basically the main thing that happens is you attach event listeners right, and only when something is triggered you need to load the JavaScript or evaluated or whatever. So this is something that I would really like to see improved. It also still supports I 11.

Dominik: 6:22

While that's a good thing for some people, it also prevents the library from using modern browser features, although you could, of course, set that up in the build process and like polyfill them or whatever. But, for example, there's like no mutation observer used when you add like new elements to the dorm manually, like. I kind of feel like also because we are working with custom elements quite often that I really like this behavior, that when you add something to the dorm it's automatically hooked up right and you don't need to manually call like a function to analyze the dorm and then do this, for example, and then like some other. Downside is, like some people say, that it might be insecure because it replaces like HTML and you could also like inject scripts with that. But I think this is like true for any technology that renders some HTML and if you have user input to data, you just have to make sure that it gets sanitized correctly, right?

Dominik: 7:19

I think especially this sizing and the the architecture of the library, it could need like a modern, a facelift, and I see that a lot of the times. I think they are also like other libraries that use these directives, like Alpine, and I already had the idea that there should be like a common, like a library that they all build upon on, like handling these attributes or like directives and lazy loading code from different areas so that you can have, like, if you in your entire code base only use like the normal click trigger and only use get requests, then you should only need to load the code for this and not like for anything else. Right, that's it, I think. In general, it is an awesome library, like HTML looks really great, but currently we're not using it with with flint, right, we could maybe use it in some components where we heavily depend on it. Yeah, we'll see what the future brings.

Steffen: 8:15

Absolutely. Yeah, that was what I was about to say as well. Like bottom line HTML is awesome. It's not a code library of flint that will work per starter theme yet we might use it in the future, maybe not as part of the core, but still I'm thinking even regarding the comparatively large size. We could load it with our JavaScript island architecture, right, and then at least, like it doesn't interfere as much with the initial page load, so you can still get quite some nice performance from it and so on, and I'm very curious about trying this out and seeing seeing the benefits in our projects.

Dominik: 8:48

Me too.

Siegfried, deploy!

HTMX is awesome and here's why

Listen to this podcast on