It also uses a DSL that has no application outside of its specific corner.
It also forces you to return HTML fragments via AJAX.
By the way I did use intercooler.js (prev. iteration of htmx) intensively and while I liked it at first, it really added up to being an HTML/JS soup when other developers started extending.
14kb
> It also forces you to return HTML fragments via AJAX.
not true, you can return anything. support client-side templating for JSON etc
Here's your list of examples: https://htmx.org/examples/
Here's validation: https://htmx.org/docs/#validation-example
It looks kinda like ruby.
https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-n...
You said it yourself:
> We all have finite time and it's great to learn something once and be able to use it multiple times.
We all have finite time and it's great to use tools that help us work efficiently, following the strengths of those tools, instead of having to maintain unnecessarily complex solutions
I think if you are, like me, someone who for various reasons never followed the JavaScript ecosystem for various reasons over the last few years (in my case because I was working on exclusively backend APIs in C#), coming back into trying to do any frontend website is just ten thousand people saying "it's not that hard, just follow something like this: x", where 'x' is any one of forfty hundred humungous different frameworks.
If you don't want to have to learn a whole new ecosystem but just want to bang out something that can take advantage of a bunch of modern-ish nice front end paradigms like being able to selectively update individual components without having to do a full page reload then htmx feels like it would hit the spot for a lot of different use cases.
(I say this having only read the site several times, usually when it pops up here in some context, and I always think "oh damn yeh that thing exists, I have to give it a go at some point!" but never actually have yet)