Nothing totally new, but it is an attribute based extension of html that allows any element to generate http get/post and handle/target a hypermedia response back into the dom... without the need (but still have the option) to write javascript if you want. You end up writing almost zero js and it's wonderful.

So each HTML element can have a a JS onclick handler (via htmx) that hits the server, which generates HTML, and the requesting page then uses JS to replace the instructed DOM node?

This reminds me of the era before AJAX when we used to POST to a hidden iframe, and then JS in the hidden iframe would update the parent page.

Yes that's about the idea, except since HTMX is somewhat specified there is hope for browsers to implement that natively and therefore empower users, not remote website operators.

This thing preserves your sanity!

I'm waiting for anyone to demonstrate me how this method isn't 3 step backward in 2022.

I mean this sincerely: can you demonstrate how using React et al for 95% of web apps (not talking about highly interactive stuff, offline-first or other special cases) was at all a step forward for web apps, OTHER than eliminating full page refreshes and thereby improving UX? Nevermind developer experience, although that is more subjective of course. The "decoupling" and "single JSON-based REST API for all clients", etc. arguments are nice in theory but impractical in reality. By all means have a JSON-based API for exactly that - application programming interfaces, not human-consumable interfaces. I would argue the development, deployment & maintainability complexity of those SPAs can not be justified for most web apps, if you are able to offer the essentially the same UX benefits with an HDA approach.

I love the idea of a SPA without full page refresh. But from experience, the UX of that is terrible! 99% of SPAs i've tried prevented me from using history navigation from my browser, and simply failed in unobvious way when the network wasn't reachable (yeah just keep on spinning without ever loading anything or timing out).

When doing a "full page refresh" my browser has good UX for displaying errors and retrying requests, potentially resending <form> data. SPAs don't have any of that.SPAs is a cool pattern but as long as it is not supported by the HTML/CSS specs (and therefore the browser natively) it will remain terrible from a UX perspective.

It is three step backwards. And one step to the side. Which is what I needed, and many others too.

Damnit, I hate it when other people are more eloquent and on the money than me.

By far the biggest downside of this approach for me is that I found out about it in 2020 instead of 2013, when htmx predecessor was created (intercooler).

The hype around reactive technologies in the mid to late 2010s looks kinda funny now considering how much unwarranted hot garbage companies have built with it.

But hindsight is 20/20. Someone may be building a beautiful language that will kill JS in the 2020s, and in 2026 we'll all be wondering why weren't using it in in early 2022.

TBH I think one of the real drivers was just being able to share an API with mobile apps, as 'mobile app for everything' dies down so will SPAs for everything under the sun

Ok, you mean this thing isn't worth my attention as a front-end developer? Carry on.

It definitely is worth looking into. By reducing complexity around the interactivity portions of an application and all of the dom manipulation, it frees frontend developers to focus more on the aesthetic portion and the user experience itself.

:) I think it's worth at least taking a look at

the core idea is to use hypermedia, rather than an RPC-style architecture, and that is, at the least, an interesting alternative approach to consider when creating front end code

Yes, this is not for a front-end developer, this is for all the other people who don’t want to be front-end developers and don’t want to spend months every year to keep up with JS churn.

Since we began using this approach, we can be full-stack developers again. One person can easily implement both parts, which is so much faster.