This is not a post about hating HTMX.
HTMX is actually very good.
This is a post about why I don’t use it yet, even though people keep telling me to.
The title is a little tricky on purpose.
A better title would be:
- Please Stop Telling Me to Use HTMX, or
- Why I’m Not Using HTMX (Even Though It’s Cool)
What People Say About HTMX
When people talk about HTMX, they usually say things like:
- “You don’t need a frontend framework anymore”
- “Just write HTML on the server”
- “Less JavaScript is better”
- “It’s simpler and cleaner”
And honestly, that sounds great.
If you are tired of complicated tools, HTMX feels like a breath of fresh air.
So I tried it.
The First Problem: Seeing Changes Is Slow
When I use modern frontend tools, this is what happens:
I save my file → the screen updates right away
That feels nice.
With Go + HTMX, it usually feels like this:
I save my file
→ I stop the server
→ I start the server again
→ I refresh the browser
→ now I see the change
That’s a lot of steps for one tiny change.
Yes, there are tools that can help:
- tools that restart the server for you
- tools that refresh the browser for you
But you still have to set all that up yourself.
Modern frontend tools already do this for you.
The Tailwind Problem (Why My Styles Don’t Show Up)
While styling with Tailwind, I prefer to build only the classes I actually use in the specific project to avoid packaging the full CSS bundle.
But Tailwind only knows about styles that already exist at the time it runs. Meaning that after the initial build, further changes down the line may be prone to containing undefined CSS classes.
With HTMX:
- HTML is split into many small pieces
- some parts only appear sometimes
- new styles are added later
So this happens a lot:
“Why doesn’t my new style work?”
The answer is usually:
- Tailwind didn’t see that style
- you forgot to rebuild the CSS
- or the style only appears sometimes
You can fix this — but you must:
- run Tailwind in watch mode
- configure it carefully
- remember special rules
That’s more thinking than people admit.
HTML Starts Simple… Then Gets Complicated
HTMX makes simple things very nice.
A small button looks clean and easy.
But real apps are not small.
Real apps have:
- loading states
- error messages
- permissions
- conditions
- reused pieces
So your HTML slowly becomes:
- longer
- harder to read
- full of logic
You didn’t remove complexity.
You just moved it into HTML.
That’s not bad — it’s just something to know.
“The Old Web” Wasn’t Always Better
People say HTMX feels like the “old web”.
But the old web:
- refreshed the whole page a lot
- felt slow
- still used JavaScript when things got hard
HTMX isn’t the old web.
It’s something new that mixes old ideas with new ones.
And mixing things always comes with tradeoffs.
People Recommend HTMX Too Quickly
One thing that bothers me is this:
You say:
“I’m struggling with this problem”
Someone replies:
“Just use HTMX”
No questions.
No context.
No thinking.
HTMX is not magic.
It’s a tool.
And tools are good only when they fit the job.
Why I Don’t Use HTMX (Yet)
I don’t avoid HTMX because it’s bad.
I avoid it for now because:
- I like seeing changes instantly
- restarting things breaks my flow
- HTML gets messy faster than expected
- styling takes more care than advertised
That doesn’t mean HTMX is wrong.
It means it’s not always the best choice.
When HTMX Is Actually Great
HTMX is amazing for:
- forms
- dashboards
- admin pages
- internal tools
- simple business apps
If that’s what you’re building, you might love it.
If you’re building:
- very interactive pages
- fancy animations
- fast-changing designs
You might not.
And that’s okay.
The Real Point
This post is not saying:
“Don’t use HTMX.”
It’s saying:
“Please stop acting like HTMX is the answer to everything.”
I’ll probably use again HTMX one day.
Just not because someone told me I should.
Top comments (0)