After a quick glance, it seems like htmx would complement thymeleaf, if the web page/app you're writing doesn't need any sort of eager client (eager as in, treat and interaction with a remote service as "successful" and resolve the error in the background somehow).
W/ htmx + clojure, you can define your ui like so:
(def counter (atom 0))
(defn partial-count-markup [c]
[:span (str "Pressed: " c)])
; Handler for /partial/count
(defn partial-count []
(swap! counter inc)
(partial-count-markup @counter))
; Handler for index.html
(defn handler []
[:button {:hx-put "/partial/count" :hx-swap "innerHtml"}
(partial-count-markup @counter)])
And like that you have a page with a button that tracks a counter and updates the ui (I haven't tested this, YMMV).
Also if it isn't clear, you can also keep all your markup as Clojure data structures, which means you can write an `html` function which has the common styles/scripts/etc.. necessary so you get a ton of re-use with an already similar syntax vs needing to learn a new templating syntax w/ its own conventions.
W/ clojurescript, to get the same behavior you need:
- clojurescript toolchain w/ some configuration of how you'll bundle/package it
- an idea of how you'll distribute your application (serve spa from same API service? S3/Object store? another web service? How to reconcile state?)
- an idea of how you'll reconcile state between local/server, if you want to go that route. If only local, nbd. If server, you add a handler and fetch data once SPA or cljs has loaded.
- and idea of what format you want to consume (JSON, HTML, XML,text) and then write the translation between that format and your markup.
etc...
I hope the above answers your question, or at the very least offers another perspective.
As a quick postscript, I think it is underestimated how convoluted templates/templating engines are, given they have the tendency to implement their own language/semantics outside of the PL you're using. I have much respect for the authors of template engines/spec, the engineering that goes into them is impressive, however, most I have come across tend to be a leaky abstraction. Once I experienced writing markup as Clojure data structures, it ruined me for templates permanently. I don't want to go back to writing templates, and doing an assessment of "what language does this template engine implement, and is it simple/easy to learn?" is an exercise I do not miss.
Note: I've been Clojure/ClojureScript developing professionally for almost two years now and have debated most of the above internally during that time. Done some templating w/ JS, Go.