7 of 21

SPA World

This JavaScript runtime is so powerful, in fact, that today many developers ignore the hypermedia features of the browser, in favor of building their web applications entirely in JavaScript. Applications built in this manner have come to be called Single Page Applications (SPAs). …[which] communicate with a server, these applications typically use JSON API calls via AJAX. And they often update the user interface using a “reactive” style frontend JavaScript library.

In these applications HTML becomes a…graphical interface description language that is used because, for historical reasons, that’s what happens to be there, in the browser.

Applications built in this style are not hypermedia-driven: they do not take advantage of the underlying hypermedia system of the web.

Source: https://hypermedia.systems/introduction/

8 of 21

Source: https://www.excellentwebworld.com/what-is-a-single-page-application/

9 of 21

An General Example

The JavaScript will issue an AJAX HTTP GET request to /api/v1/contacts/1 using fetch(). …unlike requests issued by those hypermedia controls, it is up to the JavaScript code to handle the response from the server.

The JavaScript code above converts the JSON text received from the server into a JavaScript object... [the Javascript] is responsible for updating the UI based on the data encoded in the JavaScript Object, perhaps by displaying the contact in a bit of HTML generated via a client-side template in the JavaScript application.

The JSON API being used here does not return a hypermedia response…This JSON API is, rather, a Data API. Because the response is in JSON and is not hypermedia, the JavaScript… must understand how to turn this contact data into HTML. the code…needs to know about the internal structure and meaning of the data.

It needs to know:

Exactly how the fields in the JSON data object are structured and named.
How they relate to one another.
How to update the local data this new data corresponds with.
How to render this data to the browser.
What additional actions/API end points can be called with this data.

In short, the logic in updateUI() needs to have intimate knowledge of the API endpoint at /api/v1/contact/1... As a result, the updateUI() code and the API have a strong relationship, known as tight coupling: if the format of the JSON response changes, then the code for updateUI() will almost certainly also need to be changed as well.

Source: https://hypermedia.systems/hypermedia-reintroduction/

10 of 21

Roy Fielding, the creator of REST

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

Source: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

11 of 21

Why do we have SPAs in the first place then?

The dynamic loading of the content gives the user a seamless experience
Less data is potentially exchanged (we don’t have to load the entire page)
Servers just serve data, which can potentially be consumed by multiple clients (web, mobile, native, etc.)
You are not confined to using only elements which browsers support, allowing teams to create highly rich native-like experience

12 of 21

General trend

Amount of SPA-like code cost

Interactivity

13 of 21

General trend

Amount of SPA-like code cost

Interactivity

14 of 21

Coupling, state, complexity, cost…

State synching between the client/server means more code, tooling, etc.
More code means more bugs

(a) Industry Average: "about 15 - 50 errors per 1000 lines of delivered code."

More code means more people
More codebases means more deployables

15 of 21

More interactivity w/ lower cost?

Amount of SPA-like code cost

Interactivity

16 of 21

HTMX

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

Click Me

</button>

Source: https://htmx.org/

The hx-post and hx-swap attributes on this button tell htmx:

“When a user clicks on this button, issue an AJAX request to /clicked, and replace the entire button with the HTML response”

17 of 21

Drawbacks, cost

Small learning curve, but it’s one more thing to learn
Not appropriate for some usecases (an spreadsheet app would be a bad fit, for example)
This is not a zero-JS solution, as HTMX extends the browsers capabilities, so does need to be delivered to the client

18 of 21

Advantages, payoff

No need for shadow-cljs, react, etc.
Browsers are complicated, and browser Javascript APIs can be rough
A lot less code
Built with browsers in mind

Crawlable HTML
Browser history just works
etc…

Use whatever tooling you want, all you have to do is focus on delivering HTML to your browser (or HXML to your mobile app, see: Hyperview)
Great docs and community

19 of 21

Clojure <3 HTMX

Biff - https://biffweb.com/docs/reference/htmx/

SimpleUI - https://simpleui.io/

Examples from Hypermedia Book in Clojure (reitit, hiccup) - https://github.com/aburd/hypermedia-systems-clj-examples

HTMX Docs - https://htmx.org/docs/#introduction

20 of 21

Demo

https://github.com/aburd/hypermedia-systems-clj-examples

21 of 21

So why should HTMX be in your toolkit?

It shouldn’t replace what you know, but it should be an option to get the most bang for your buck
It is GREAT for people who consider themselves “backend engineers”
It is great for teams that want to spend their complexity budget elsewhere
Small learning curve
Right tool, right solution, try to see your toolkit as covering a gradation of different axis and think about what you know to fit those cases