Why not use HTMX?

The HTMX hype is real. And I’m in on it. Mainly because I believe it could safe a lot of applications that are written in React or Vue from a lot of state management sync bugs. HTMX removes the need for frontend state management, validation and in some cases even business logic code duplication. Less code, less bugs. And that is where I think HTMX shines over existing frontend frameworks (or “libraries” - looking at you React).

As long as we are in a browser, there is only 1 state: the HTML that you are rendering. And HTMX reduces a tremendous amount of duplicated code to achieve almost similar levels of intereactivity as something like React. I believe it’s a great trade off.

There are already so many, great articles focussing the good stuff about HTMX, that I don’t think my word is much worth here. However, usually when I try to figure out if I should use some technology or not, I try to figure out why I should not use it. That makes the trade off I’m tryin to make more tangible. The good parts are usually over promoted and make it hard to compare with other technologies, it’s a lot of times comparing apples with oranges. The bad parts put things in the right perspective for me.

So, why (or when) shouldn’t you use HTMX? Some thoughts about the bad parts of HTMX.

1. Even simple interactivity require latency

If you don’t use any other Javascript aside from HTMX and want to toggle a form, for example, you need to make a request to the server. In HTMX everything is a request to the server. Off course, you can sprinkle some vanilla Javascript or use an framework to enrich your application or page with interactive behavior that doesn’t require state.

2. Your backend stack becomes more important

Quit obviously, since you move a lot of logic to the backend, the technology you use there determines for a greater deal the developer experience and reliability. For example, when using Golang templates incorrect passing of arguments will fail render, but when using EJS with Node.js you can easily pass a non-existing variable to the template, and it will just render an empty string.

3. Silent errors due to incorrect selector ID’s

At the heart of HTMX’s interactivity is its reliance on HTML ID selectors, the hx-target attribute. Typo’s in any of the ID selectors can lead to silent failures, meaning parts of your interface won’t render anymore as intended, potentially leaving users frustrated. Things might especially get frustrating when you decide to change the ID of an element, and forget to update the ID selector in the HTMX attribute.

4. HTMX drives the design of the backend

HTMX drives the design of the backend, it’s not something you use to progressively enhance your app. When using HTMX you need a ton more endpoints compared to your MPA setup. There was a single page using 1, 2 endpoints at most.

So, all this considered, I obviously chose HTMX part of my stack when I decided to build Lastmark.