From 0dc7f20c46bcba4cf41fb181530978f890d0ea5f Mon Sep 17 00:00:00 2001 From: carson Date: Sun, 6 Feb 2022 07:27:00 -0700 Subject: [PATCH] HDA essay + essay improvements --- www/essays/a-response-to-rich-harris.md | 4 + www/essays/complexity-budget.md | 4 + www/essays/hateoas.md | 4 + www/essays/hypermedia-apis-vs-data-apis.md | 7 +- www/essays/hypermedia-driven-applications.md | 143 +++++++++++++++++++ www/essays/locality-of-behaviour.md | 7 +- www/essays/rest-explained.md | 6 +- www/essays/spa-alternative.md | 6 +- www/essays/splitting-your-apis.md | 6 +- www/talk.md | 1 + 10 files changed, 183 insertions(+), 5 deletions(-) create mode 100644 www/essays/hypermedia-driven-applications.md diff --git a/www/essays/a-response-to-rich-harris.md b/www/essays/a-response-to-rich-harris.md index 2dbd1681..d0b184ec 100644 --- a/www/essays/a-response-to-rich-harris.md +++ b/www/essays/a-response-to-rich-harris.md @@ -201,3 +201,7 @@ In conclusion, ![Javascript Devs](/img/js-devs-be-thinking.png) + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/complexity-budget.md b/www/essays/complexity-budget.md index 9226fbd5..dc79ec08 100644 --- a/www/essays/complexity-budget.md +++ b/www/essays/complexity-budget.md @@ -66,3 +66,7 @@ apart or aggressive refactoring. We must always bear in mind [Chesterton's Fenc If an application is functioning well (or even reasonably) then we should assume that the complexity budget was well (or reasonably) managed. And we must also bear in mind that, with unfortunate frequency, attempts at addressing complexity in existing, large applications often fail or, sadly, make things worse. + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/hateoas.md b/www/essays/hateoas.md index d18331e3..ec654aac 100644 --- a/www/essays/hateoas.md +++ b/www/essays/hateoas.md @@ -271,3 +271,7 @@ necessity for building RESTful systems. font-size: 1.1em; } + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/hypermedia-apis-vs-data-apis.md b/www/essays/hypermedia-apis-vs-data-apis.md index 0a67bcb1..bc591e9b 100644 --- a/www/essays/hypermedia-apis-vs-data-apis.md +++ b/www/essays/hypermedia-apis-vs-data-apis.md @@ -146,4 +146,9 @@ can satisfy more client needs without modification. # Conclusion When designing a hypermedia API, you should use a different design mindset than you use for data APIs. Churn is -much less of a concern, and providing the end points you need for a good hypermedia experience should be your primary goal. \ No newline at end of file +much less of a concern, and providing the end points you need for a good hypermedia experience should be your primary goal. + + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/hypermedia-driven-applications.md b/www/essays/hypermedia-driven-applications.md new file mode 100644 index 00000000..311d0fc0 --- /dev/null +++ b/www/essays/hypermedia-driven-applications.md @@ -0,0 +1,143 @@ +--- +layout: layout.njk +tags: posts +title: htmx - high power tools for html +--- + +## Genesis + +> thesis: MPA - multi-page application +> +> antithesis: SPA - single-page application +> +> synthesis: HDA - hypermedia-driven application +> +> \-\-[@htmx_org](https://twitter.com/htmx_org/status/1490318550170357760) + +## The Hypermedia-Driven Application Architecture + +The **Hypermedia Driven Application (HDA)** architecture is an old/new 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](https://en.wikipedia.org/wiki/Single-page_application) (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](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) 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 another format (e.g. JSON) + +The HDA architecture falls within the **original [REST-ful](https://developer.mozilla.org/en-US/docs/Glossary/REST) +architecture of the web** in a way that contrasts with the SPA architecture. In particular, HDAs make **effective use +of [HATEOAS](/essays/hateoas/)** in a way that SPAs typically do not. + +## An Example + +Consider the htmx [Active Search](/examples/active-search) example: + +```html +

+ Search Contacts + + Searching... + +

+ + + + + + + + + + + + +
First NameLast NameEmail
+``` + +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 MDA + +[Code-On-Demand](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7) 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](/essays/locality-of-behaviour/) design principle. + +Three approaches to scripting that satisfy this constraint are [hyperscript](https://hyperscript.org), [AlpineJS](https://alpinejs.dev) +and [VanillaJS](http://vanilla-js.com/) (when embedded directly on HTML elements). + +Here is an example of each demonstrating HDA-friendliness: + +```html + + + + + + + + +``` + +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: + +* +* +* +* + +And some complementary, HDA-friendly scripting tools: + +* +* +* (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](https://developer.mozilla.org/en-US/docs/Glossary/REST), in particular [HATEOAS](essays/hateoas/)) + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/locality-of-behaviour.md b/www/essays/locality-of-behaviour.md index c9df54c6..4a1b9c20 100644 --- a/www/essays/locality-of-behaviour.md +++ b/www/essays/locality-of-behaviour.md @@ -97,4 +97,9 @@ are: Locality of Behavior is a subjective software design principle that can help make a code base more humane and maintainable. It must be traded off against other design principles and be considered in terms of the limitations of the system a code unit is written in, but, as much as is it is practical, adherence to this principle will increase your software maintainability, -quality and sustainability. \ No newline at end of file +quality and sustainability. + + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/rest-explained.md b/www/essays/rest-explained.md index 922eab70..77e7cec9 100644 --- a/www/essays/rest-explained.md +++ b/www/essays/rest-explained.md @@ -246,4 +246,8 @@ REST describes the original web model. The uniform interface concept is, in my aspect of REST, and is useful for web developers to understand as it is primarily responsible for the benefits described above. -Finally, I hope you can see how inappropriate REST is for describing most JSON APIs in use today. \ No newline at end of file +Finally, I hope you can see how inappropriate REST is for describing most JSON APIs in use today. + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/spa-alternative.md b/www/essays/spa-alternative.md index 52072ec9..0303dd86 100644 --- a/www/essays/spa-alternative.md +++ b/www/essays/spa-alternative.md @@ -108,4 +108,8 @@ efforts on what your application does, rather than on how it does it. From the [htmx developer's starter kit](https://twitter.com/htmx_org/status/1306234341056344065): -![What if?](/img/what_if.png) \ No newline at end of file +![What if?](/img/what_if.png) + +
+~~~ +
\ No newline at end of file diff --git a/www/essays/splitting-your-apis.md b/www/essays/splitting-your-apis.md index e24df65c..25400898 100644 --- a/www/essays/splitting-your-apis.md +++ b/www/essays/splitting-your-apis.md @@ -117,4 +117,8 @@ of the benefits of the REST-ful web model (simplicity, reliability, etc.) and of And, by choosing a hypermedia-oriented front end technology like htmx, you can create [excellent user experiences](/examples) within that model. -Everything old is new again, but, this time, a little bit better. \ No newline at end of file +Everything old is new again, but, this time, a little bit better. + +
+~~~ +
\ No newline at end of file diff --git a/www/talk.md b/www/talk.md index 57c0d837..db964874 100644 --- a/www/talk.md +++ b/www/talk.md @@ -51,6 +51,7 @@ Email: [htmx@bigsky.software](mailto:htmx@bigsky.software) ## Essays +* [Hypermedia-Driven Appplications (HDAs)](/essays/hypermedia-driven-applications) * [HATEOAS](/essays/hateoas) * [Locality of Behavior (LoB)](/essays/locality-of-behaviour) * [Splitting Your Data & Application APIs: Going Further](/essays/splitting-your-apis)