Taking clojure out of the equation and only looking at htmx, I would say it buys you is simplicity, and for most use cases that is the difference between a shipped thing and a dead one (thing in this case is project, product, etc...). Granted, htmx isn't a silver bullet, as you have to learn some of the idioms of the library. But it may be worth it to some (it is to me), to not have to bring in an entire JS toolchain to get a thing bootstrapped.

im not able to figure out what is it that htmx is saving you in the example above. with clojurescript, wouldnt you have written very similar code ? i mean all you are doing is calling an api. is it automatically doing conversion of JSON to ur DTO/business object. that cant be right can it ?

It can kind of be what you need it to be (if I am interpreting the API provided by htmx correctly). The way I have been using it is to partially update my DOM based on some user interaction (either a POST, PUT, DELETE), by returning html. This makes updates html -> html vs json -> frontend framework -> html.

As far as ClojureScript code, the above example would resemble the equivalent ClojureScript code almost 100% (with some slight differences). The example above was a little contrived, in that it is so simple. However, if you think about a larger use case (i.e. 100's of elements need to be rendered from a db), it doesn't become contrived.

With a Clojure backend + htmx, all I do is write my business logic, define my html via hiccup (Clojure vectors w/ a convention similar to html) and return the html to the client, which I can ship without needing to coordinate different pieces. In addition, the hiccup I hopefully defined is broken up into functions that'll allow me to partially update the DOM for different user CRUD operations.

With a Clojure backend + ClojureScript SPA, its the same-ish business logic on the backend to return results from a JSON API, some more logic on the front end to validate said JSON, some additional logic to add said data to a global store, then finally my view can update. Then in order to get you're app out there, you'll need to figure how to get you're application deployed. There has been a lot of work in ClojureScript land as far a build/packaging tools, but they can still be rough around the edges, which results in headaches sometimes between dev/prod. After you've gone through that and put your app in an S3 bucket/object store (for the sake of example), you'll need to get your API deployed (which should be same steps as above backend + htmx).

So while it may seem the same, there is a lot more complexity that comes with ClojureScript SPA.

Also, as a final thought for this section, even if you went with vanilla ClojureScript + html, you won't get much for free. You still need to compile your ClojureScript, which still requires DOM API's, which you'll still need to call from ClojureScript to handle updating the DOM from the ClojureScript which still needs to call AJAX/fetch, which still needs to resolve promises in order to get your JSON data (or html data), which still needs to translate your interchange format (in this instance JSON) to html. At this point, are the layers of abstraction worth it?

my mind is telling me that it is some kind of lifecycle management - like before/after hooks. make sure that the html loads after server is loaded, etc. is that what it is ?

Sort of. I like to think of htmx as filling the role of sync-ing my web view/page/app with backend state without all the ceremony and fuss of a frontend framework. I can handle all the logic and UI definition on the server and defer http requests (GET, POST, PUT, PATCH, DELETE) and DOM patching to htmx. Kind of like how a user of a frontend framework defers that same patching to the underlying virtual dom implementation.

Personally, when I first saw htmx I thought "well... that doesn't seem useful. I can get a React (or Vue, or Solid, or Svelte, or X) spun up w/ a cli command and do all my things there. But then I used it and couldn't have been more wrong on its usefulness. I encourage you to play around with htmx, try implementing the counter example in your preferred language, see if you come to the same conclusion you had previously.

There are cases where a SPA is appropriate and merits the investment, but I think they should be the exception not the rule, due to the complexity brought about by a frontend framework.

In conclusion, I hope I answered your questions. I am happy to continue this discourse if you still want to chat about it. At the end of the day though, all we're trying to do is render web pages, so do whatever makes sense to you to accomplish that.

oh this clicked. Now i get what htmx is doing. its basically doing a react-ish way of UI changes without a full page reload (which thymeleaf would have done).

so what happens if i click something that needs to go to another "page"? do you "swap" the html out with the html of the other page ? or do you trigger a full page reload. For SEO reasons, im kinda putting the requirement that every interaction must have a unique url

Interesting, I missed that in my scan of the thymeleaf docs. I haven't used that library at all (and tend to shy away from Java land in general, unless it's Clojure).

And for my purposes, yes. I may be missing the point of the library, but that is how I've tended to use it.

so what happens if i click something that needs to go to another "page"? do you "swap" the html out with the html of the other page ? or do you trigger a full page reload. For SEO reasons, im kinda putting the requirement that every interaction must have a unique url

I'd say pick your poison. You could go either route and it would most likely be roughly the same code.