What I don't like about Htmx is, that it is still a JS framework, without good automatic fallbacks for a noscript situation. This leads to web devs thinking it would be great to do all the things in Htmx, even if all they have is a static page with static content.
Just recently I looked at hosting an old school forum. I don't want to load all the PHP and MySQL baggage on my server or even run it in docker, so I looked for Python solutions. Found PunkwebBB. Was happy for a short time with it, until I tested it more in depth with no scripts. Unfortunately, while it has some good fallbacks in some places, it doesn't have them everywhere and some buttons just don't do anything without JS. It also uses Htmx. Completely unnecessary JS, considering the function of the buttons.
I considered forking it. But the amount of work to remove the needless JS, and repair it ...
So now I am building my own forum completely without JS, and with Python Django doing a lot of heavy lifting.
I get the point but I do feel like Htmx's whole design is a big automatic fallback... If some browsers will never be able to understand the hx-get/post/etc attribs, you can just design the initial html you send over around that.
while what you're saying is true in theory, you still have to make sure that e.g. your form responses do the right thing. You might think "just return the full page!" but it's extra work that for many people is busywork, and makes it harder to reuse things ("my comment post endpoint returns the rendered comment" becomes "my comment post endpoint needs to know what page the comment is in to return the fully rendered page")
In practice I think it's very easy to make your htmx application JS-requiring.
Indeed. And the amusing/disappointing/frustrating thing is: my next.js site works if you turn off JS. Links are server-rendered as links, HTML is server-rendered as HTML. If you visit one of the tools that run on the client then they won't work, but the pages that could be static content? They're static content.
Or at least they were, until I started using cache components the other week, and I'd not noticed they'd regressed. That's frustrating. Give me a few minutes...
This is exactly why I prefer Turbo ( https://turbo.hotwired.dev/ ).
Turbo comes from a progressive-enhancement philosophy: start with proper HTML and add richer behaviour on top. HTMX is a JavaScript library in much the same sense that React is. There is nothing inherently wrong with that, but it makes this anti-pattern easier to fall into.
Honestly, “the site should work without JavaScript” is no longer the strongest argument. Server-rendered, semantic HTML matters more for accessibility, SEO, and increasingly for LLMs and other automated tools.
Of course, you can write excellent HTML with HTMX. It just requires more discipline—or enough experience to recognize when you are quietly building a JavaScript application in HTML attributes.