Also like bnert, when using Clojure we prefer to use a library on the server-side called hiccup to generate HTML from Clojure data structures instead of a template library. Either way, template engine or hiccup HTML generation, the principle is the same. You are coding everything on the server-side and rendering HTML back to the browser - something it is VERY good at rendering. :) As part of that HTML rendering, you are putting attributes on some HTML elements that htmx understands from the browser side.

ClojureScript is a totally different concept, as it basically allows a Clojure developer to write JavaScript in Clojure - it generates JS. With the server-side rendering model above, we still code 100% in Clojure, but we get to jettison a lot of the complexity of the ClojureScript model (Reagent etc), and development set-up. It is far simpler.

Other benefits of the hypermedia approach provided by htmx: 1. It is obviously true HATEAOS, so we don't worry about end-point versioning issues. 2. The barriers of the UI team and Server team negotiating and re-negotiating end-points is gone. We have all transitioned to "full stack developers" - sanely. 3. As mentioned above, it is language and server-side agnostic, so use what you prefer and have competitive advantage with using. 4. Simpler mental model. The team thinks in hypermedia terms from a server rendering perspective only. That lets you wrap your brain more easily around the business problems. 5. You have the full power and capability of your database at your disposal instead of going through and desigining the correct endpoints to get there first.

Hope that made sense

what im not sold on is HTMX specifically. im kind of wondering things like "hey what if we just used alpine.js with JSP or thymeleaf and skip htmx entirely", etc

what im getting incrementally with htmx is a bit unclear...while staying in the server side rendering of things.

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)])

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.

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.

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 ?

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 ?

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.