https://htmx.org/essays/hypermedia-driven-applications/
> htmx
docs
reference
examples
talk
sponsor
[ ]
Genesis
thesis: MPA - multi-page application
antithesis: SPA - single-page application
synthesis: HDA - hypermedia-driven application
--@htmx_org
The Hypermedia-Driven Application Architecture
The Hypermedia Driven Application (HDA) architecture is a new/old
approach to building web applications. It combines the simplicity &
flexibility of traditional Multi-Page Applications (MPAs) with the
better user experience of Single-Page Applications (SPAs).
The HDA architecture achieves this goal by extending the existing
HTML infrastructure of the web to allow hypermedia developers to use
more powerful hypermedia-driven interactions.
Two constraints characterize the HDA architecture:
* The application uses a declarative, HTML-embedded syntax, rather
than imperative scripting, to achieve better front end
interactivity
* The application interacts with the server in terms of hypermedia
(i.e. HTML) rather than a non-hypermedia format (e.g. JSON)
The HDA architecture falls within the original REST-ful architecture
of the web in a way that contrasts with the SPA architecture. In
particular, HDAs make effective use of HATEOAS in a way that SPAs
typically do not.
An Example
Consider the htmx Active Search example:
Search Contacts
Searching...
First Name
Last Name
Email
Here htmx is being used to achieve a UX pattern that would typically
be associated with an SPA: as the user types, after a slight pause,
results will populate the result table below.
This example effectively demonstrates the essential characteristic of
an HDA:
* The front end of the feature is specified entirely in hx-
declarative attributes, directly in HTML
* The interaction with the server is done via HTTP and HTML: an
HTTP request is sent, HTML is returned and inserted into the DOM
The Place of Scripting In An HDA
Code-On-Demand is an optional constraint of the original REST-ful
architecture of the web.
Similarly, the HDA architecture has a final, optional constraint:
* Code-On-Demand (i.e. scripting) should, as much as is practical,
be done directly in the primary hypermedia
This addresses the concern regarding Code-On-Demand mentioned in
Fielding's thesis:
However, it also reduces visibility, and thus is only an optional
constraint within REST.
By embedding Code-On-Demand (scripts) directly in HTML, you increase
visibility and satisfy the Locality of Behavior design principle.
Three approaches to scripting that satisfy this constraint are
hyperscript, AlpineJS and VanillaJS (when embedded directly on HTML
elements).
Here is an example of each demonstrating HDA-friendliness:
Note that the hypermedia (HTML) is given primacy of place here: it is
not an after-thought being produced by a client-side templating
engine.
The scripts augment the existing hypermedia but do not supersede it
or subvert the fundamental REST-ful architecture of the system.
HDA-style libraries
Some libraries that allow developers to build HDAs:
* https://htmx.org
* https://unpoly.com/
* https://kasta-ua.github.io/twinspark-js/
* https://turbo.dev
* https://hyperview.org/ - (a mobile hypermedia!)
And some complementary, HDA-friendly scripting tools:
* https://hyperscript.org
* https://alpinejs.dev/
* http://vanilla-js.com/ (embedded directly in HTML)
Conclusion
The HDA architecture is a synthesis of two preceding architectures:
the original Multi-Page Application (MPA) and the (relatively) newer
Single-Page Application.
It attempts to capture the advantages of both: the simplicity and
reliability of MPAs (due to the REST-ful Architecture, in particular
by returning to Hypermedia As The Engine Of Application State).
>