This was posted here two and a half years ago on this forum:
So “Clojure UIs” already include a framework which works with HTMX, together with all the other React-based frameworks referenced by the author, as well as template-based (Hiccup, Enlive, Enfocus), DOM-manipulation-based (dommy, jayq) and many others. Based on this alone, I don’t believe “Clojure UIs” have taken any wrong turn as such.
While I certainly have various gripes with React and don’t use it any more as a result, I don’t see anything “wrong” with a web page retrieving data from a server and rendering on a client.
I admit HTMX provides some really nice features, but fundamentally it only covers a very narrow sliver of functionality which a modern day web developer should be able to use. So to do anything useful beyond client-server communications, you have no choice but to employ one or more additional JS libraries, whether you write it yourself or use an existing one.
Now the crux of the article(s) is really that HTMX/Hypermedia (herein just HTMX) with server-side rendering is a much better solution to building web-based applications than RPC-style REST returning data which is rendered client-side. The problem with this is that it doesn’t take into account the extremely limited scope HTMX has compared with RPC-style REST.
With HTMX, the client makes a request to the server. Since the response can only be HTML, the client can only be a web browser. So that rules out mobile apps entirely from using HTMX.
If you want to provide any styling in the response, you either have to use inline styles, or the client must already have those styles loaded. If the client has to have the styles loaded, then you already have tight coupling between the client and server.
If you want to provide any JavaScript functionality in the response, you have exactly the same options and the same tight coupling.
So in most cases if you use HTMX, you will have to write both the client and server.
With an RPC-style API, the client makes a request. The client can be anything you want it to be and doesn’t have to be a browser. If it is a browser, it can choose what it wants to do with the data. Most important of all, it can validate the data, so that if an API does change, it can take an appropriate course of action. If the data is valid, it can choose to render it, styling it in any way the particular client app sees fit, and providing any behaviour which that app already has loaded. If not, it can take an alternative course of action.
And the beauty of this approach is that not only can you provide the same RPC-style API to mobile apps, but you can in fact provide it to different web-based apps as well, even server-based apps, and let each app determine how they want to render the data, if at all. With HTMX you are entirely at the mercy of the server as to how the response is rendered.
Based on just a comparison between HTMX and RPC, I would argue that RPC-style APIs provide much looser coupling than HTMX and are much more consumable by a wider variety of clients than HTMX.
Another problem is that HTMX assumes that all client state can and should be managed entirely by the server, effectively eliminating client-state from the front-end. Much as we as functional developers want to try to eliminate state, this actually greatly limits the functionality of the client app and makes it entirely dependent on the server for any state changes, which can very quickly result in a much slower app. A client should have the option of maintaining its own state, and updating server state as and when it needs to, if at all.
It can also mean moving a lot of the work which a browser can and should perform onto the server, thereby creating an additional load on the server. This seems like a complete waste especially when it is something the client can easily handle and is better placed to handle.
If you have multiple regions on a page which are updated by HTMX, using just HTMX itself there doesn’t appear to be any easy way for these to communicate with each other, or to provide coordination between the different regions. They are after all just HTML/DOM elements, so this also represents a huge loss in functionality which you wouldn’t have if you were dealing with data manipulated by JavaScript.
What about a client which consumes from multiple APIs, any number of which are external to the origin serving the client? Again, RPC/REST wins hands down here, since at this time the overwhelming majority of APIs will be RPC/REST, usually serving JSON. This fact alone should be the primary driver for the design of the client app, since you will also be very hard-pushed to find an HTMX-based API which can provide you with what you are after.
These are just a few things I came up with when I first looked at the book on the page https://hypermedia.systems/ when the above developer first posted his framework. Definitely some good ideas but as I’ve hopefully shown, very limited in scope and a lot of shortcomings.