I think the takeaway here is "make the easy things easy, don't use it for the hard things".

One of the most exhausting things about any discussion about front end web dev is that it gets treated like a monolith. It _can_ be incredibly complicated. In many scenarios that complication is unwarranted. But in some it's justified.

Htmx is a poor choice for a full single page app. That's fine. It excels in other areas. Right tool for the right job.

But easy things are also relatively easy when using other tools that scale up better. Even if HTMX makes the easy things slightly easier, is that worth investing time and energy into learning it in addition to those tools that scale up better? Is it worth building things with it if I know that months down the line I'm going to need to scrap it once my easy thing becomes slightly less easy?

Like I said, this seems like a poor value proposition to me. Of course, if other people are happy with it more power to 'em.

To me it feels like people are eager to latch onto this because it's different, and because there's a dopamine hit associated with seeing the easy thing become a little easier when taking a new path that's overoptimized for it - hence the hype - not because it's actually good engineering, in terms of the tradeoffs you're making.

Of course, I feel the same way about Tailwind, so maybe I'm just old and grumpy.

> Even if HTMX makes the easy things slightly easier, is that worth investing time and energy into learning it in addition to those tools that scale up better?

Depends what your aim is. Do you want to become a full time front end engineer? Then no, probably focus on other frameworks. But do you, from time to time, want to put small pieces of interactivity on web pages when it isn’t the sole (or even major) focus of your job? Htmx might be ideal.

Because it's a drop-in, no-dependency, no build-step library that can make your static MPA a little less static for the little bits of interactivity you need with not much effort. It's what you reach for to avoid "write the whole website in JS."

React -> "The site exists in JS, HTML is just a render target."

jQuery -> "Poke at the HTML from JS." Which is brittle as hell.

htmx -> "The site exists in HTML, extend HTML to handle the common tasks you want to do with it."

For me the strength of htmx is to allow non JS languages and frameworks on the server side. Now I can use Raku+Cro+Red to make a modern website with dynamical modern UX. The standard paradigm is keep all state in isolated htmx state machines (eg modelling a form submission) or real state stored in my db and this works fine for my simple site needs.

> strength of htmx is to allow non JS languages and frameworks on the server side

I don't see how that has anything to do with the choice of htmlx. You always have the freedom to use any languages in the backend. If anything, htmlx imposes a bunch of hypermedia convention on top of your conventional API, regardless of languages.

Back-end devs think htmlx will allow them to be comfy in the back-end and just trash their front end with "thin client" that has no framework or any sort of organization. Eventually someone who is willing to actually think about front-end has to rebuild it and decouple the 2. Happens all the time.

I build quite basic websites for money. Today I use WordPress and write some combination of PHP/JavaScript with Advanced Custom Fields where I need custom storage. So tbh anything else has gotta be better! This means I have both front end and back end aspects under my personal control.

I want to be able to be able to code in a more natural back end setting - I like Raku, others may prefer Go (or Rust or PHP or JS). I am not ready to commit to a complex event driven framework like using the WordPress backend and React on the front end. But I do recognise that a pure browser only model for UX is too crummy … let’s say I want to validate an email … well if I specify input email in HTML, my browser will pop and ugly dialog if there is no @ in the input.

So HTMX gives me my backend coding preference and a clean way to add simply tweaks to the UX. That is the power of HTMX for me.

I don’t think HTMX is a good solution is you want to write Google Maps or Facebook. But it is a great way for straightforward sites to be written and I do not understand why I will be forced to step into JS front end rewrites if I go this route (and I can happily bundle some JS + CSS + HTML into an HTMX response for the islets where I need it.

> I want to be able to be able to code in a more natural back end setting

I think the point the OP is making is that very new frontend frameworks dictate what backend language you use. They just use HTTP requests and consume JSON.

On the contrary, making easy things easy and hard things possible is about as good of a value proposition as I can realistically expect. Hard things are going to be hard no matter what, and making them easy usually either adds excessive complexity or else makes easy things hard (if not impossible).

Making easy things easy and hard things possible is great, I agree...but that's not what I wrote. And I don't think that's what HTMX provides - it mostly gets in your way with the hard things.

> but that's not what I wrote.

Making hard things hard is a subset of making hard things possible. Better than making hard things impossible, which is the usual result of making easy things easy :)

> And I don't think that's what HTMX provides - it mostly gets in your way with the hard things.

And yet they're still possible. Like I said: hard things are going to be hard no matter what. Even if the hard things are harder, that's still a worthwhile tradeoff for maximizing the easy things.