Sorry, but it's a no from me.
htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw from a core module or anything).
Also, just a suggestion because it's not technically wrong:
The example of sometimes needing an auto-completing search box is probably not the best one to use. I'm sure it's meant to say "you want the results to be queried from a server/database on every input", which you would certainly need javascript for. But the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
> We're very close to invokers being baseline, and that will take care of plenty of what htmx was designed to do.
From what I've seen, invokers without extra code are designed for client side interactivity (e.g. showing a modal), which is orthogonal to the (correct, IMO) use case of HTMX. You shouldn't use HTMX to turn every custom user interaction into a network round trip, you should use it instead of fetching JSON. If a user interaction wouldn't trigger a network request if you built your app with react/vue/svelte/{insert_framework_of_choice}, then it shouldn't trigger one if you build it with HTMX either.
You can add custom commands with invokes and custom JS, but at that point you're basically re-implementing HTMX yourself, and I'm not sure what the advantage of that would be over hx-trigger="command" (especially when you also consider using fixi if you don't need all the features of HTMX). There's also the triptych proposals [2] from one of the HTMX maintainers which would add some of HTMX's behaviors to HTML, but those are a long way from being baseline, and may get there.
[1] https://github.com/bigskysoftware/fixi
[2] https://alexanderpetros.com/triptych/
> 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.
ETA: sorry; I should have mentioned, I'm ignoring server stuff because it's not my use case. I don't hydrate code on a server and send it down to people. I just write HTML or let javascript compose it in the browser. Since I don't use frameworks, that's the way I've developed to be efficient. Since I can't speak to how useful htmx is for server-rendered stuff, I'm staying out of it. Just talking about what htmx can do for me, which is very little.
Why use any library, ever? Why not just reimplement the wheel yourself every time then?
Many libraries provide features that were unavailable in packages that are small enough for comfort. Those features and sizes vary per project, and, as admitted, sometimes there's great use for htmx. It's just not going to be for front end, local-first, SPAs. As the author, himself, said very clearly.
The standard invoker commands deal with the display of already loaded page content in the DOM.
HTMX deals with loading content into the DOM, not managing display of the DOM.
They serve two different roles and together should handle the majority of javascript framework use cases.
Web Components does cover some of the same use case as HTMX, but is intended for when a server is returning data rather than HTML. It is both more powerful and more complex.
> the specific example of just having a search box autocomplete can actually be fulfilled with a datalist element. It won't dynamically re-query results, but it will filter based on input. So it's a muddy example, at best, and that's probably not great for the point trying to be made.
A prefilled list is never an acceptable solution for a search box. A search box is meant to capture arbitrary input. A filterable datalist is not a search box.
> 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.
I can't quite follow your comment.
If you have a predetermined number of things that can be "searched" for, that is a filter box, not a search box. Even if you want to stretch the semantics and call it a search box, it is still a solution that only works for a very small subset of the search box problem space. Your criticism that this semanically stret hed snall subset wasn't explicitly excluded is just silly.
Invokers don't give you what htmx gives you out of the box. If you want to, for example, have an invoker command to fetch a resource and swap it in to the page, you have to write custom JS for that. That's the thing that htmx gives you out of the box, along with error handling, progress indicator support, history support, animated transitions, and a host of other features.
If you don't need or want all these and are happy with the worse UX, then of course you don't need htmx.
Re your suggestion: datalist makes you select an option, then fills in an input with the value of the option. Then you have to submit the form to actually get the resource you just searched for. Active search gives you the links to the resources directly in the search results, so you can load them with one click. There's a big UX difference.
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's actually specifically for server-rendered content and using it for front-end development doesn't actually add much
It's for server-rendered content that can be used to build a frontend app. I know because I've done it several times.
> I would also have to write custom JS for the functions I would try to invoke with htmx
The difference is with invokers you would have to re-implement everything from scratch and with htmx you typically only need to implement some parts that it doesn't handle, like eg listening to a DOM event and doing some action in response.
lol. oh boy! everything from scratch! must reimplement the whole library even though I don't package server responses for injection.
glad you're enjoying your framework, friend!
Thanks. I love it when people make incorrect claims, I reply with corrections, and get condescending comments in return.
> We're very close to invokers being baseline
Well why not have the benefits of invokers, but today - with HTMX?
HTMX could eventually switch its implementation to use invokers under the hood in the future, and you'd have the convenience of using declarative behaviors on your buttons, today.
> autocomplete can actually be fulfilled with a datalist element
I wish that the spec would cover more use cases, but last time I tried to use it, I couldn't, because it has really bad UX, and is inconsistent across browsers.
Also, like you mentioned, it only works for small data sets that you can deliver with the initial HTML, not large amounts of data which reside on the server.
You could argue that these are use cases where you wouldn't require an auto-complete in the first place, because the data set is too small.
> 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.