Why I Use HTMX: I Want the Web to Stay Mostly HTML
When AI builds a web interface, it is easy to end up with an application architecture before you have proved that you need one. I do not want that to be automatic.
My default question is not “Which frontend framework?”
My default question is: What does this interaction actually need?
If a user submits a form and the server can return the next piece of HTML, I am interested in doing exactly that. If one region of the page needs to update, I would rather return that fragment than build a client-side state machine by reflex.
The browser already knows how to navigate, submit forms, manage focus, render HTML, handle native controls, and progressively enhance a page. I want a reason before I replace those capabilities with another abstraction.
I like server-owned state
A lot of the interfaces I build are really workflows: forms, recommendations, booking steps, status changes, admin actions, receipts, delivery states, operational screens, and agent-control surfaces.
In many of those cases, the server already owns the truth. I do not gain much by inventing a second representation of that truth in the browser and then spending engineering effort keeping both sides synchronized.
The mental model stays close to the actual system: request → server action → HTML response → updated interface.
Minimal JavaScript is not an aesthetic rule
I often describe the stack I prefer as HTML-first, minimal JavaScript. That is not ideology. I am trying to keep the number of moving parts proportional to the problem.
Every client-side abstraction has a cost: dependencies, state coordination, security surface, upgrades, build tooling, debugging paths, and another set of assumptions an AI coding agent can violate. Sometimes that cost is worth paying. Sometimes it is not.
The browser is already a platform
Native forms are useful. URLs are useful. HTTP semantics are useful. The back button is useful. Progressive enhancement is useful. Native controls and ordinary links can carry a surprising amount of interface work.
I would rather compose those capabilities first and add complexity where the product proves it needs complexity. Do not invent an application because you know how. Earn the application architecture.
Simple does not mean careless
Choosing a smaller stack does not remove the need for engineering discipline. I have dealt with HTMX implementation issues around content security policy, script behavior, response handling, and XSS risk. In production work that has meant hardening configurations, escaping untrusted HTML, tightening request behavior, and fixing places where the simple-looking version was not safe enough.
A technology choice should survive contact with security requirements. Minimalism is not a substitute for security.
I am not anti-React
I do not think HTMX should replace every React application. If I need a deeply client-driven experience, significant offline behavior, sophisticated local state, intensive canvas interaction, or a product whose interaction model genuinely lives in the browser, I will choose accordingly.
The point is not HTMX versus React. The point is default versus decision. I do not want the most familiar framework to make the architecture decision for me.
AI makes defaults dangerously cheap
AI is very good at completing familiar patterns. That speed is useful. It also means unnecessary complexity can now be generated faster than ever.
One of my jobs is to keep asking whether each layer earned its place. HTMX is one expression of that habit. It reminds me to start with the web that already exists—HTTP, HTML, the server, and the browser—and then add the next layer because the product needs it, not because the generator knows how to create it.
That is the kind of technical judgment I want my work to demonstrate. Not that I know a particular library. That I know why I chose it.