This was shared with me by a non-Clojurist and I would like your thoughts.
Without a specific goal in mind, arguing where to push the work is a frustrating endevor because you will just go in circles playing whackamole with the perceived annoyance.
If you go the route he is suggesting, I think what inevitably happens is it’s very hard to understand the narrative around what the client is doing. Because while looking at the client code because large parts of functionality (and not just the data it’s showing) are now on the server.
But why not just have one codebase for both you say? Well, that’s an option to, but it makes doing very complex frontend or backend tasks slightly harder. It’s generally not done as much because it requires skills in both domains and a language that can easily blend them together. Hyperfiddle is such a tool. Also you can kind of due it with a rules engine and some fairly obvious wiring. GitHub - oakes/odoyle-rum
There is also a good question about HTMX and Clojure tools at Who's using HTMX with Clojure and how's it going?
You are right – the post itself has some writing issues, and is a bit scrambled. I think some of his comparisons are not good, too. HTML to EDN is apples and oranges…
This confuses an illustration with the principle I’m arguing for. It’s not fundamentally a question of HTML vs JSON or EDN.
There is no reason why, in principle, why a hypermedia client/server could not be built using edn. This tends not to be as practical (see HAL).
The main point is that RPC style architectures create a great deal of accidental complexity due to the specific kinds of coupling it creates. Many of the problems being solved by Clojure’s web app frameworks over the years have been focused on accidental problems that arise from doing RPC.
Much better to go to the root of the issue. There are many alternatives here, hypermedia being one. Maybe Electric is another. There’s plenty of inspiration from other programming communities as well that have been more focused on simple, data-oriented approaches.
The author! Yay!
What is RPC? does FRP (functional reactive programming) fit into this, or does it belong more to the react.js group?
I’m trying to look into htmlx and how it deals with databases. At that point does HATEOAS become the same as the traditional REST structure, only without much JS?
What is RPC?
Remote Procedure Call - you write the code as if all the data and computation is local to one machine, but specific procedures are actually executed on a different machine and the return values (if any) are sent back. I suppose you could consider running commands over SSH to be a kind of basic RPC.
Yes, remote procedure call. This is the first article in a series. This one is very derivative, most of the ideas are laid out much better in other places (such as this blog post by Roy Fielding and the Hypermedia Systems book.
At that point does HATEOAS become the same as the traditional REST structure, only without much JS
This is a good question, and it gets at what I hope to expand on in future posts. REST is underappreciated, but it is more constrained than hypermedia. And hypermedia is more constrained than what I’m calling (for lack of a better word) “extended hypermedia”.
For example HTMX sticks pretty closely to hypermedia and REST. But there can be times when relaxing some of the REST constraints can be useful. For example, statelessness is a constraint. But Phoenix Liveview is able to provide some benefits by abandoning that constraint. And Liveview is within what I’d want to call an extended hypermedia approach.
My team writes full stack Clojure apps, clojurescript and Clojure. We use Reagent and sometimes reframe. We don’t do any remote services; it’s just Rest to our own stuff. What would this arrangement look like for RPC? Would RPC just take out the Ajax?
it’s quite possible that what you call REST is what we’re calling RPC; see </> htmx ~ How Did REST Come To Mean The Opposite of REST?
I see two dimensions to how teams choose to architect their systems:
- What tech does the team know and have experience with, what examples are available online or in documentation and what are the majority of people “out there” doing with their tech stacks. What is technologically familiar to the team.
- What is the distribution model of the system (web, appstore, desktop, OS) ; what is the social environment around developing the system (one team for entire stack, multiple teams, multiple teams over different organizations).
On the first dimension you need a type of thought-leader to break away from what is going on in the mainstream. It might hurt Mr Fielding to say this, but most/a lot of teams are doing RPC-style HTTP endpoints with fairly rich client runtimes. Nobody ever got fired for chosing IBM/java/react.
On the second point; RPC is exactly what some teams/systems require. It suits some system features and some system/team distributions quite naturally and the drawbacks are really just the cost for making a valid tradeoff.
Talking about what is “right” is philosophic, and educational and important, but not an unbeatable argument to criticise what teams are doing.
HTMX doesn’t deal with databases. That’s what your webserver/backend code is for, and your webserver also renders HTML fragments that HTMX places/replaces in the right place in your DOM.
What surprises me the most is that this article mentions Phoenix LiveView yet there is no mention of Clojure Electric.
That’s a really interesting blog post; thank you for sharing it here @dave.liepmann. There are so many things one can learn from technologies that were ahead of their time.
Okay. I was confusing HTMX with “serverless.” I am concluding that for a fullstack app, HTMX doesn’t necessarily apply; hiccup is a superior implementation of HTML, which is (as far as I can tell) an objective fact, and we are not using AWS or other parse-on-the-front-end APIs, so AJAX is purely local.
I’m surely missing something here. Is it the use of Reagent/React.js that HTMX would object to? Or is it AJAX? Or does it just not apply to full-stack, single-server things?
Is it the use of Reagent/React.js that HTMX would object to?
Yeah–htmx is basically an alternative to React. It doesn’t replace server-side hiccup; it’s more like an extension to hiccup. It’s very much (only) intended for full-stack apps 
.
I wrote this post a little while ago which might be a good explanation? Understanding htmx
I like that I can use HTMX no matter what backend stack I have. I have a Biff (CLJ) project with hiccup on the backend and a node project with a JS hiccup library. So switching context is a bit easier. What’s also nice for noobs like me is that you can build your stuff with req/resp and page reloads first and add HTMX when you want to spice is up later.
isn’t the biggest thing that React gives us the virtual-DOM empowering hot reloading? Dev without that seems less joyful.
The point is that you only need stuff like React because you’ve moved so much business logic into the client and made a fairly fat client. If you avoid that temptation, you can still have interactive apps, but with the logic on the backend (where you have your live REPL already).