Agent one: handles the request and does tool calls
Agent two: reads the result and decides on quality vs a re-drive if it’s low quality
Agent three: decides how to present the information to the user, creates a collection of HTMX elements
HTMX hx-get is reliably, and beautifully rendering the result of the Agentic Workflow without any react, etc.
Very happy and passing quality gates. I love not having security alerts every week to patch because of some buried react dependency library
<button hx-post="/clicked" hx-swap="outerHTML">
No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.
<a href=“/clicked”>click me</a>https://github.com/jon49/htmz-be
It's amazing how much further you can go when you flip the server as the one deciding where what should be updated on the page.
This was originally conceived by datastar and nomini also implements it this way. And HTMX 4.0 will have this as a first class citizen.
> the build time is over 30 seconds!
that's silly. 30 seconds building time is nothing compare to the accumulated time you wait for micro changes to your frontend.
for typical web development using react/vue/svelte you have hot code reloading, which can reload the current website < 1 seconds after you hit [Save] on your favorite editor.
for htmx to update, you have to wait for your whole server to reload (which can be way slower even you use interpreted languages like ruby or python, due to complexity of the framework you use).
not to mention it does not keep any state of the current website, make debugging way more troublesome compare to a js mature framework.
only people who never have to improve their website incrementally think htmx is a viable option. or insane people.
obviously, for some small websites with minimal interactions or no need to change the content very often, then htmx can be good, but for that case, vanilla js also works, and they do not need 14kb of excess baggage.
Only backend developers that think frontend is trivial and we’re all just idiots think that HTMX is the solution. They saw it working in their hello world side project and think they discovered gold.
> And suddenly you've got:
> A package.json with 847 dependencies
> A build step that takes 45 seconds (if the CI gods are merciful)
> State management debates polluting your pull requests
> Junior devs losing their minds over why useEffect runs twice
> A bundle size that would make a 56k modem weep
No? React is surprisingly small, and if you're in dependency hell then fix that. The alternative is another idiom.
And if you glue packages together you're basically reinventing frameworks. This can be a good thing or a bad thing.
Regardless of your choice between glueing libs or a framework, you'll end up with tons of dependencies for most non-trivial projects anyway.
(Also, I don’t think we can go back to XSLT in the same sense that I can’t go back to the moon.)
After a bit of searching all the examples I could see use JavaScript to glue the HTTP request making part and then invoke the XSLT processor so it looks like the answer is "no".
Just pure eval(). [1]
1. htmx.config.allowEval: defaults to true, can be used to disable htmx’s use of eval for certain features (e.g. trigger filters)
For things with heavy interaction (drag and drop, chat etc.), I find the code to make it work with HTMX is just too clumsy to work with as a mental model.
> The server just returns HTML (not JSON, actual HTML)
I like to separate presentation HTML from the data (returned from HTTP request). Some like to make backends that do nothing but serve the (singular) frontend, even running templates to make the HTML they return for easy consumption. That's not where I draw the line.
Dx resources must aim AI's attention having enormous technical documentation and be AI efficient in order to become mainstream.
I believe no other shiniest thing will ever make cognitive nest in humans. We are overloaded.