Please Just Try Htmx

Exactly - it's on a short leash towards being blocked by browsers.

https://security.googleblog.com/2025/10/https-by-default.htm...

That's in some sense even worse than plain HTTP, because it gives you a false sense of security.

What are you guys talking about. It automatically redirects to the HTTPS version and the cert is signed by Let's Encrypt.

Let's Encrypt is a CA.

https://crt.sh/?q=pleasejusttryhtmx.com

Nextjs, great example of this. I've yet to find an actually valid use case to choose it outside of "our incestor's relationship got us unlimited vercel credits for like three years."

For all of the esoteric talk about hypermedia and things like this, this is the greatest advantage of HTMX, why I use and, and also why GP is dead wrong.

Thanks I'll look into it, but on first glance I feel like I just got space blasted by the website! What happened to simple websites eh

My current plan is to switch to Datastar too, although the devs seem a little odd. The guys writing HTMX seem like a more professional bunch.

Well listen, we have two modes of operation. It's either html/js/css in the classic sense, or Go templating with some tailwind and JQuery (or whatever the kids are calling it these days). In the case of react, something totally different. But essentially when you try to go that middle path with something that defines its own syntax, it starts to bleed into everything. It's not self contained. I'd argue maybe tailwind is like that as well, so you want to put it in templates or something. But if your htmx code lives in your actual code the way it does with Go a lot of the times because they promote building these partial functions, it looks horrible, very hard to reason or manage. I'm not talking one or two snippets, I'm talking when you have a full blown web app.

The reality is it's going to suit some people and some languages really well and others not so well. I think I like html/css/js and using AI to generate that. But I also like Go templates and trying to isolate that in a programmatic way. I find htmx in principle, a good idea, but when I actually tried to use it, fundamentally the wrong tool for me.

It's not less noisy, you just move the noise to the backend

> Well why not have the benefits of invokers, but today - with HTMX?

Because I already have the benefit of invokers, today, using the composedPath method. And a map to some functions is usually less, in my experience, than 14kb of js.

> You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself[...]

Exactly. So why use a library? If it's that simple, the suggestion is akin to using a library for a toggle, when a checkbox would do. Yes, there are reasons to do it, but no, it's not what I'm going to do most of the time.

> A prefilled list is never an acceptable solution for a search box.

Yes it is. When the query is more expensive than the entire dataset included in some other query, a static list built from previously queried content is the more performant search, even if you want to classify it as a filter. I, as a user, am still searching through this list of unknown nodes even if you, the program, are just filtering what your nodes are for me. All searches are filters; hard lines for best practices only matter insofar as they engage with their practical application.

As you should be able to tell from the other comments, this is not a library for me. If I had ever looked into it past trying to actually implement it, I would have realized that it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much. The author made that very clear in the supporting documentation, I just never bothered to check.

So I relayed my personal experience with it and then, because of this great comment section, I became aware that I was trying to use it for things that it isn't helpful for. Because, yes, I would have to write custom JS for the functions I would try to invoke with invokers, but I would also have to write custom JS for the functions I would try to invoke with htmx. There's no change, for me, other than including 14kb that I do not need to run a PWA.

So you can take whatever issue you want with my impatience and my myopia in disregarding it as not useful, but my complaints are not immaterial. It doesn't do what I said it doesn't do, and you seem pretty happy to confirm that. I shouldn't have expected a cat to bark, and I regret it. Hell, I'd apologize if someone felt mislead, or if someone feels I'm misleading people in my aspersions. But - like any app - my apps swap out html all of the time and there's nothing that htmx provides that helps me with that in a way that's worth the weight.

> it is often simply because the site is badly written

I find that some techs tend to cause badly written code. I have junior coworkers that can write clear Python after a short intro, but can't write clean R after a year using it daily. I don't know if it is caused by the philosophy behind the language, the community, the tutorials and docs...

Different teams/projects have different needs and require different solutions. While it's good it worked in their favor, I am quite confident that someone else can tell a completely different story. In fact, there are some comments in this very HN discussion that detail their negative experience with htmx. I would not use one or the other to "convince" anybody to go with either solution like what this article attempts to do.

Not having to deal with npm and a build step can remove a huge barrier to adoption for a large number of potential adopters, or people that just want some lightweight interactivity in an app.

What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it.

React is easy for small websites so why would I use a separate framework when I can use one framework for everything?

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

(Disclaimer: I haven't actually run into a case where I had to move from HTMX to a SPA framework, even partially, so this is largely an educated guess)

I think this scenario would either be very apparent early on in the project, or wouldn't actually be that challenging. There are a couple ways you could run into the limits of HTMX:

1. You require purely client side interactivity. The right (IMO) way to use HTMX is as a replacement for sending JSON over the wire and rendering it into HTML on the client, so if your app has features that _wouldn't_ be done that way, you should reach for something else. Fortunately there's lots of solutions to this problem. You can use built in browser features to achieve a lot of the basics now (e.g. the <details> tag means you don't really need custom scripts if you just want an accordion), write simple vanila scripts, or adopt light weight libraries like alpinejs or the creator of HTMX's (only slightly deranged) hyperscript.

2. Maybe your purely client side interactivity needs are complex enough that you do need a SPA framework. At that point you can adopt the islands architecture and create interactive components in your fraemwork of choice, but continue to use hypermedia to communicate with the backend.

3. If you can't easily separate client side state (handled with javascript, potentially with the aid of frameworks) from server state (handled on the server and sent to the client via hypermedia), you can again adopt the islands architecture and have your islands manage their own network requests to the backend.

4. If the above applies to all of your app, then hypermedia/HTMX is a bad fit. But this should generally be pretty obvious early on, because it's about the basic, fundamental nature of the app. You probably know you're building google docs when you start build google docs, not mid-way through.

>Where do I add the JavaScript for that? Is it raw, inline, or are we back to packages and bundling and a build step?

That’s really your call to make. I’ve never went the full build step with it, but I’ve only built some internal dashboards and crud apps with it.

> To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward.

I'm not sure "fear" is exactly the right word here, but it's something I consciously evaluate for when looking at any new framework or library. Anything that has a lot of "magic" or "by-convention" type config is subject to this.

You start with the "hello world" example, and then you hit that wall. The test of an awesome framework vs a fundamentally limited (or even broken) one is: can you build on what you have with extensions, or do you have to rewrite everything you did? There's a lot of these where as soon as you want to do something slightly custom, you can't use _any_ of the magic and have to redo everything in a different way.

This isn't just libraries either. Another almost worse example is AWS Elastic Beanstalk. Simple way to get an app up and going, and it handles a lot of the boilerplate stuff for you. The problem is as soon as you want to extend it slightly, like have another custom load balancer route, you actually have to completely abandon the entire thing and do _everything_ yourself.

This is a really hard thing to get right, but in my view is one of the things that contributes to a framework's longevity. If you hit that wall and can't get past it, the next project you do will be in something else. Once enough people start posting about their experiences hitting the wall, other people won't even pick it up and the framework dwindles to a niche audience or dies completely.

I mean I built a pretty featureful P2P (via webrtc) planning poker app using React and it's around 1300 lines of typescript.

More, but I don't think it's a mind-blowing difference and I wasn't playing code golf when I wrote it

https://github.com/ceuk/planning-poker

Is this comment relevant at all???

That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.

Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself.

Good abstractions mean you don't have to worry about the layer below.

Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and styling, but I don't think it's a forgone conclusion that abstractions force you to learn the level below.

Otherwise we'd all spend half our time learning assembly.

I do have sympathy though for a developer who just wants to focus on the higher level paradigm and let the library maintainers worry about the innards.

That just makes HTML/CSS part of the React paradigm though. You can still use all those features in a React app, after all. The 'new paradigm' to learn with HTMX is how it does reactivity.

honestly both the react haters & the htmx haters are wrong on this

if you care about have a solid UI, you should learn everything

you should learn css, react, svelte, vue, rails, tailwind, html

if you don't and you say you actually care about your UI, your opinion is actually irrelevant

This featured article is about HTMX not HTML. Ofc everyone working in the FE should know HTML/CSS

I agree that people often do this but I don't think you _have_ to. You could have freely ignored SSR, RSC, etc. and kept on making boring old React SPAs. The churn is largely opt-in.

The thing is most of us have jobs where we can't unilaterally switch to the 'cooler' solution, and I value my own context-switching overhead much more than I value a slightly smaller bundle or dep tree. I'll much sooner optimize the former than the latter and so the general purpose solution that will solve both my own projects and the work ones typically wins.

My first reaction, having done a fair bit of XSLT in ancient times, was "I hope not".

After a bit of searching all the examples I could see use JavaScript to glue the HTTP request making part and then invoke the XSLT processor so it looks like the answer is "no".

See the quickstart from htmx.org

    <script src="https://cdn.jsdelivr.net/npm/htmx.org@2.0.8/dist/htmx.min.js"></script>
      <!-- have a button POST a click via AJAX -->
      <button hx-post="/clicked" hx-swap="outerHTML">
        Click Me
      </button>

When the user clicks the button the browser will take the result of the request to `/clicked` and swap the whole button dom node for whatever the server sent.

As a dev you get to write HTML, and need to learn about some new tag attributes.

Your browser is still running js.

They mean that you don't need to write JS, you can just add a script tag to your page

Sorry I know other people have responded already, but it means you don't have to write any client side javascript at all. You can just skip along with a server that returns html. Just throw the script tag in there, and you're done.

The magic of this is that it's pretty easy to make SPA-like webapps with no javascript or complex client side framework. You can write your server in python, rust, clojure, whatever. If you don't need a lot of state management, it's really simple and awesome.

You [as a dev] don't need [to write] js.

Your browser will still run js. See sibling thread.

I will never ever ever ever touch htmx after this interaction I just witnessed.

I'm the author of the original article. fwiw, I haven't seen anything that bothers me.

And if there was originally a harsher response which I missed, well then I hope it wasn't merited.

I'm pretty light-hearted about this topic! It's more fun that way.

Agree updated my comment