Its a good tool for teams/individuals with a high proficiency in backend tooling, and doesn't want to learn another entire ecosystem for a project. Its not equivalent to a good frontend with modern tooling.
htmx is capable of SPA as well. What we must remember is that htmx is a javascript library. Its just htmx provides an extension to html attributes.
This does not mean we cannot add Javascript to solve problems... its just htmx eliminates the need of writing hundreds (or thousands) of javascript code to get things done.
I do not claim htmx to be the one-and-only solution to building web applications but it has DRASTICALLY cut many hours away from adding new features (and bug fixes) to our relatively complicated company portal.
We no longer have to write backend AND frontend code. Previously our website were using frontend libraries. Why? Because we are told this is how your are SUPPOSE to make them, now. However, when you are a small team without dedicated frontend developers (ie React devs, etc) you have to allows extra time to replicate/duplicate code on the frontend as well.
Yes, there have been trial-and-error issues with htmx where we had to stop and think how we would solve certain things. For the most part, it is accepting the "htmx way" of doing it and are now comftable with it. Its not perfect but we make it work well.
Point is - very little is done on the client side. It is easy to see whats going on, and which Views or Partial Views to amend, etc, on the serverside. I would even argue that if we hired a "front end" developer they would fit into our environment relatively easy, knowing where the HTML code is, how to test it, alongside CSS styling and, if needed, to write additional javascript. The only ones that wont are dedicated JS framework guys who refuse to see or understand our decision process. This is fine, of course. If they do not like our methods then they can reject the 2nd Interview process.
I want to repeat - I do not claim htmx solves all website issues. Its just the websites I am involved with, htmx has been a great choice moving forward, and they are a combination of simple to complicated websites.
I recently had developers blink slowly and ask me to repeat the statement that an ordinary ASP.NET Razor web forms app could be used for a site that had a single form on it (with about a dozen text fields only).
"But... how... can it submit? Doesn't it need an API?"
See https://learn.microsoft.com/en-us/aspnet/web-pages/overview/...
There is a very substantial fraction of developers who have never done anything else, and are completely unaware that such thing is even possible.
I don't think there is such thing as an HTMX hype outside HN. There is definitely a SPA hype outside HN though. A shame, since a large number of applications would benefit from being a MPA.
Junior front-end engineers are already feeling threatened by low-code-llm-agents. LLMs have strong aesthetic sensibilities and the functional nature of modern front-end frameworks means that LLMs can get good at them, really fast.
HTMX allows junior engineers to develop as front end and backend engineers at the same time. So if one profession is threatened, they still have a backup.
We've entered the Honda civic / Toyota Camry era of visual design for standard websites and apps. The UI isn't a selling point as it once used to be. If anything, customers prefer familiarity. (Frontier tech like ML and VR are obvious exclusions)
Most front end problems are civics and camrys. Yes, LLMs won't be able to build the ferrari equivalent of front ends, but they're going to be fully capable of doing CRUD competently.
Too many engineers were trained to build the next Google or Facebook through the 2010s. In reality, calling them a tiny minority would still be an exxageration. Most engineers at google and Facebook don't build Google or Facebook, let alone those working at normal companies at normal scale with normal customers.
The fact that's relatively lightweight makes me feel okay using it though. If you'd like a similar lightweight library you can try alpinejs.
Adds reactive stores with just a javascript link.
Before we had SPAs that part of the “backend” was actually called the front-end. You had business logic, and output models in the form of json, views if substitutions and logic by itself, etc.
Such as?
HTMX beautifully captures the zone between static and SPA, but devs already seem to want to use the hammer for everything, because all SPAs are suddenly not true SPAs. Well it was similar with jQuery too. The apps were considered to not be complex enough for a different tech stack, but eventually many apps grew more complex in their requirements and there is no sane way to move from jQuery to Angular and those projects got left in the dust.
But the counter argument is also valid; if your app did not grow complex, then you paid an upfront price for that expected growth but didn't reap the rewards.
I would also oppose the frequently made proposition that HTMX is for people who hate Javascript. I certainly do not love Javascript, but I do not go out of my way to avoid it. My apps always have some vanilla Javascript sprinkled in where it fits.
To refer to the article: people really need to stop searching for that "silver bullet" and just use the tooling they are comfortable with.
I really have to say I'm annoyed by parties on both sides of the isle who either refuse anything but SPAs and React or others who see HTMX as the holy grail. The tooling on both sides (e.g. either React or HTMX) is being overhyped a lot. Once your app grows to a certain size or complexity you will struggle with either for some time until you "figure stuff out". No tool will ever alleviate the struggle in its entirety.