> 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/

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.

> 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.

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.