Thanks for sharing this, it's very neat! I also looked at your somewhat related Inertia.js/PingCRM stuff recently - what are your feelings about this approach relative to that stack so far?

I'm working on an internal app built with hiccup and https://unpoly.com - somewhat similar concept and works great in practice

Is this a typo? https://github.com/prestancedesign/babashka-htmx-todoapp/blob/master/htmx_todoapp.clj#L141

In the Readme, extendable should perhaps be extensible?

@U01EFUL1A8M Thanks for pointing me out. The missing space is not interpreted but definitely a typo, yes. @U0522TWDA This text is quoted from the official htmx website https://htmx.org/ so I don't know. English isn't my first language, but it seems "extendable" exists right?

both “extendable” and “extensible” are completely fine, the slightly more precise term would be “extensible”, but they are largely interchangeable. https://english.stackexchange.com/questions/90426/extensible-vs-extendible

@U0JEFEZH6 I didn't know a "unpoly", so thank you! It seems very interesting, I'll definitely play with it soon! :-)

@U899JBRPF Thanks! I will say while both are alternative propositions but do not have the same objective of abstraction. Htmx allows not to write a single line of JS (although it is possible to write a backend in Node.js 🙂) while with Inertia.js, it is necessary to have a base with one of the following JS front-end frameworks (or "React" "Vue" "Svelte"). When we know and do not rule out the use of these, I would say that the approach of Inertia.js is more direct. The front-end is easy to write because it acts much as a template and everything that is routing, state management, auth, etc. will be done back-end side as writing a classic application. This will require little adaptation for a back-end profile having notions of front for example. With Htmx, there will be a little more to learn and the approach seems less obvious at the beginning with the advantage of being much lighter. I spent a lot more time in Inertia.js documentation than in Htmx so my opinion is certainly a bit biased at the moment. I hope that answers your question.

htmx seems to be brutally simple and it takes the HTTP REST / HATEOAS approach very seriously, which is I think a good thing if you buy into the model. Also, it’s always going to be faster and more lightweight to directly inject HTML fragments instead of parsing JSON/EDN, then constructing a VDOM and then rendering the HTML. I think the limits are clear: As soon as you add forms and interactive elements with reactive states, you don’t want to make round-trips. The server typically also doesn’t need to know about the specific UI state you’re in at any given time. I like htmx! And I’m looking forward to explore it’s limitations, uses and how to solve problems that it doesn’t solve well.