That's what I was expecting to see, a way of specifying a target. Certainly not returning custom headers for the benefit of such a 'simple' frontend library.
Solution 2 is clearly the best option. htmx authors would be wise to get opinionated and champion that approach. Forget about IE11 compat. Completely rearranging the DOM (Sol. 1) and a two request chain for one update (Sol. 3) are non-starters
This page illustrates why I just don't get HTMX. It seems like a ton of effort to save not a lot of server cycles and html over the wire.
I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param.
When we're talking dozens of KBs of HTML for a tab it's not the extra complexity to try and slim that down.
Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Getting rid of the frontend dependencies, builds systems, and languages can bring a lot of speed to a project.
Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could.
Another thing is that the templates can get a bit crazy quick.
I found a good solution is to use swap-oop (https://htmx.org/attributes/hx-swap-oob/) for everything and have a "component" wrapper server-side to abstract the ids and which template to choose.
Then, some kind of typed data structure tracking all the element ids, since you need to refer to them from the templates to know which element to update. This way you can easily find all the templates that update a specific id or all the ids that are updated by a template.
>Htmx advantage is not that it sends less bytes, but that it effectively removes frontend.
Right, which you can achieve by replacing the main content div. HTMX takes it many steps further and allows you to slice the HTML up into small bits and replace only those. This adds a lot of complexity for little benefit.
It has. The issue jQuery was designed to solve doesn't exist anymore, hence there's no reason to rely on this heavy and convoluted library any longer. There really are better solutions.
My main use case will be basic UI interaction, mostly just posting or fetching data from a backend then updating the innerHTML on some element. Vanilla might be enough, but I'm keeping my options open.
Also, no compilation step, so no need for npm, etc
IMO that's where alpine.js complements HTMX, you can use HTMX mainly for interfacing with a server and then use alpine.js for any special interaction that does not require a round-trip with the server.
That's my thought as well. Anything that needs new data from the server uses HTMX and if you need to manipulate something already on the page use Alpine, Jquery, vanillajs, or whatever other framework you prefer.
JQuery would make sense when we didn’t have querySelector and fetch API. I can’t think of any reason to use it today on a new project, there are not advantages over vanilla.
Have you seriously looked at this and thought "yeah thats better than using a single native function (fetch)"?
As for the rest of the API - what would you even use besides the css and selector functions? Which again, the native `classList` and a simple bind to the selectors are simpler and less verbose.
You just return an HTML fragment that describes the error with a header that says where to put it. The htmx JS API has events for errors too, if you want to do client-side handling.
Solution 3 gave me a good laugh though.