itsscb/htmx
1
0
Fork 0
mirror of https://github.com/bigskysoftware/htmx.git synced 2025-10-02 15:25:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

update HOWL essay

Browse Source
This commit is contained in:
Carson Gross 2023-05-23 09:31:48 -06:00
parent e4ffff5b5f
commit b5a01c1158
2 changed files with 74 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
www/content/essays/hypermedia-on-whatever-youd-like.md
View File

@ -12,93 +12,107 @@ tag = ["posts"]
> >
> Rich Harris - [Have SPA's Ruined The Web?](https://youtubetranscript.com/?v=860d8usGC0o&t=440) > Rich Harris - [Have SPA's Ruined The Web?](https://youtubetranscript.com/?v=860d8usGC0o&t=440)
One term we will sometimes throw around, when discussing htmx, is the idea of The HOWL Stack. HOWL, here, stands for A concept we like to talk about is "The HOWL Stack". HOWL stands for _Hypermedia On Whatever you'd Like_.
_Hypermedia On Whatever you'd Like_.
This is a tongue-in-cheek [software stack](https://en.wikipedia.org/wiki/Solution_stack), a reference to more popular This is a joke-but-not-really [software stack](https://en.wikipedia.org/wiki/Solution_stack), and a reference to more
software stacks like [The LAMP Stack](https://en.wikipedia.org/wiki/LAMP_%28software_bundle%29) well known stacks like [The LAMP Stack](https://en.wikipedia.org/wiki/LAMP_%28software_bundle%29)
or [The MEAN Stack](https://en.wikipedia.org/wiki/MEAN_(solution_stack)). or [The MEAN Stack](https://en.wikipedia.org/wiki/MEAN_(solution_stack)).
The TLDR of The HOWL Stack is this: by adopting a [hypermedia-driven approach](/essays/hypermedia-driven-applications) The TLDR of The HOWL Stack is this: when you use a [hypermedia-driven approach](/essays/hypermedia-driven-applications)
you free yourself up to choose _whatever_ server-side technology best fits your problem and your own technical tastes. for your web application, you free yourself up to choose _whatever_ server-side technology best fits your problem and
your own technical tastes.
## The JavaScript Empire ## Feeling The JavaScript Pressure
When you choose to use an SPA framework for your web application you will, naturally, have a large front-end codebase written in If you decide to use an SPA framework for your web application you will, naturally, have a large front-end codebase
JavaScript. that is written in JavaScript.
And, just as naturally, the following question will come up: Given that, the following question inevitably will come up:
> "Well, why aren't we doing the back-end in JavaScript too?" > "Well, why aren't we doing the back-end in JavaScript too?"
This is a perfectly reasonable question to ask and there are a lot of advantages to adopting the same programming This is a reasonable question to ask and there are a lot of advantages to adopting the same programming language on both
language on both sides of the wire: sides of the wire:
* You can share application logic between the two code-bases. A good example here is validation logic. * You can share application logic between the two code-bases. A good example here is validation logic.
* You can share data structures between the two code-bases. * You can share data structures between the two code-bases.
* You can build up expertise in a single language, JavaScript, making it easier on developers * You can build up expertise in a single language, JavaScript, making it easier for developers to work in various parts
* We don't see this mentioned much, but by adopting a single language on both sides of the wire, of your application.
[full stack development](https://www.geeksforgeeks.org/what-is-full-stack-development/) is much easier to do * You can reuse the build system & dependency management knowledge you've acquired for the front end
This _pressure_ to adopt JavaScript will only grow as your investment in the JavaScript front end ecosystem grows. Your This _pressure_ to adopt JavaScript will only grow as your investment in the JavaScript front end ecosystem grows.
team will be building up expertise in JavaScript, you will likely be maintaining a JavaScript-based build system and
so forth.
On top of this, JavaScript has improved _dramatically_ in the last five years and there are now multiple excellent Furthermore, JavaScript has improved dramatically in the last five years and there are now multiple excellent
server-side runtimes for executing it. Server-side JavaScript frameworks continue to sprout up and innovate. Library server-side runtimes for executing it. Many of the older arguments about the messiness of the language can be
support in the language continues to grow and many web development thought leaders have embraced the language, which means waved off as preventable via linting, developer discipline, and so forth.
that there are lots of learning resources available online.
All of this adds to a sense of inevitability of JavaScript that Rich Harris alludes to above. JavaScript is the dominant language among the web development thought leaders and there are massive numbers of tutorials,
code camps, etc. that strongly emphasize the language. Nothing succeeds like success, and JavaScript (as well as React)
have succeeded.
Why _wouldn't_ a web project adopt JavaScript across the whole stack? Let's call the result of this _The JavaScript Pressure_ and acknowledge that nearly every developer working with the
web feels it at least to some extent.
## The Hypermedia Resistance ## Hypermedia: Our Only Hope
Besides JavaScript, there is another technology sitting in the browser: _hypermedia_. What hope do non-JavaScript developers have in web development?
Or, more concretely, HTML support (and the related Document Object Model, or DOM). In fact, even if you are using an Well, there is one older technology sitting there in the browser alongside JavaScript: _hypermedia_.
SPA framework, you will be working with that hypermedia infrastructure in some form, via JSX templates for example, if
Browsers offer excellent HTML support (and the related Document Object Model, or DOM). In fact, even if you are using an
SPA framework, you will be working with that hypermedia infrastructure in some form (via JSX templates, for example) if
only to create UIs that a browser can understand. only to create UIs that a browser can understand.
So you are going to be using HTML or the related DOM APIs in some manner in your web application. So you are going to be using HTML or the related DOM APIs in some manner in your web application.
What if we made HTML more powerful? Well, what if we made HTML a more powerful hypermedia?
That's the idea of [htmx](/), which makes it possible to implement [common modern web application patterns](/examples) That's the idea of [htmx](/), which makes it possible to implement [common modern web application patterns](/examples)
using the hypermedia approach. This closes the UX gap between traditional MPAs and SPAs, making taking the hypermedia using the hypermedia approach. This closes the UX gap between traditional MPAs and SPAs, making taking the hypermedia
route feasible for a much larger set of web applications. route feasible for a much larger set of web applications.
Once you've adopted the hypermedia approach (and remember, you are going to be using hypermedia infrastructure _anyway_, Once you adopt this hypermedia approach (and remember, you are going to be using hypermedia infrastructure _anyway_,
so why not leverage it as much as possible) it suddenly puts server-side language choice back on the table. so why not leverage it as much as possible?) a surprising side effect occurs:
You aren't going to have a large JavaScript code-base for your front end, so you've removed the pressure that comes with Suddenly, the advantage of server-side language choice that Harris attributed to MPAs is _back on the table_.
that to adopt JavaScript on the back end. You can now make your server-side language (and framework) choice based on other
considerations, both technical and aesthetic.
Once you go hypermedia, you can use that hypermedia on whatever you'd like: HOWL! If your application's front end is mainly written in terms of HTML, maybe with a bit of client-side scripting,
and with no large JavaScript code-base, you've suddenly dramatically diminished (or entirely eliminated) The JavaScript
Pressure on the back end.
You can now make your server-side language (and framework) choice based on other considerations: technical, aesthetic or
otherwise:
* Perhaps you are working in AI and want to use a Lisp variant for your project
* Perhaps you are working in big data and want to use Python
* Perhaps you know Django really well and love the batteries-included approach it takes
* Perhaps you prefer Flask and the stripped-down approach it takes
* Perhaps you like the raw, close-to-the-HTML feel of PHP
* Perhaps you have an existing Java codebase that needs some sprucing up
* Perhaps you are learning Cobol, [and want to use htmx to make a nice front end for it](https://twitter.com/htmx_org/status/1656381761188954113).
* Perhaps you just really like Rust, Ocaml, Kotlin, Haskell, .NET, Clojure, Ada, ColdFusion, Ruby... whatever!
These are all perfectly reasonable technical, philosophical and aesthetic perspectives.
And, by adopting hypermedia as your primary front-end technology, you pursue any of these goals without a bicameral
code-base. Hypermedia doesn't care what you use to produce it: you can use hypermedia on whatever you'd like.
## An Open Web for Everyone ## An Open Web for Everyone
And when we "whatever", we really mean that. And when we say "whatever", we really mean it.
Here is a screen-shot of the [htmx discord](/discord)'s HOWL section recently: Here is a screenshot of the [htmx discord](/discord)'s HOWL subsection recently:
<div style="text-align: center; padding: 16px"> <div style="text-align: center; padding: 16px">
<img src="/img/howl-channels.png"> <img src="/img/howl-channels.png">
</div> </div>
You can see we have traffic in loads of different programming languages and frameworks: Java, Go, .NET, Rust, Clojure, You can see we have ongoing conversations in a bunch of different programming languages and frameworks: Java, Go, .NET,
PHP, Ruby, Python, Ocaml... Rust, Clojure, PHP, Ruby, Python, Ocaml. We even have some folks talking about using htmx with Bash and Cobol!
We even have some folks talking about using htmx with Bash and Cobol! This is exactly the future that we want to see: a rich and vibrant Web in which _every_ back-end language and framework
can play as an equal & interesting alternative. Each language and framework has their own unique strengths & cultures and
How cool is that? each can contribute to the magical [hypermedia system](https://hypermedia.systems) that is The Web.
This is exactly the future that we at Big Sky Software want to see: a rich and vibrant web in which
_every_ back-end language and frameworks can play as an equal & interesting alternative. Each language and framework has
their own unique strengths & cultures, and each can contribute to the magical
[hypermedia system](https://hypermedia.systems) that is The Web.
## But, Is it An *Anti*-JavaScript Resistance? ## But, Is it An *Anti*-JavaScript Resistance?
@ -115,25 +129,27 @@ But, to the contrary, we are deeply appreciative of JavaScript.
After all, both htmx and hyperscript are _built in JavaScript_. We couldn't have created these libraries without After all, both htmx and hyperscript are _built in JavaScript_. We couldn't have created these libraries without
JavaScript, which, whatever else one might say, has the great virtue of [_being there_](https://en.wikipedia.org/wiki/Being_There). JavaScript, which, whatever else one might say, has the great virtue of [_being there_](https://en.wikipedia.org/wiki/Being_There).
And we recommend _using_ JavaScript for front-end scripting needs in a hypermedia-driven application, so long as you And we even go so far as to _recommend using_ JavaScript for front-end scripting needs in a hypermedia-driven
script in a [hypermedia-friendly](/hypermedia-friendly-scripting/) way. application, so long as you script in a [hypermedia-friendly](/hypermedia-friendly-scripting/) way.
Further, we wouldn't steer someone away from using JavaScript (or, perhaps, TypeScript) on the server side for a Further, we wouldn't steer someone away from using JavaScript (or, perhaps, TypeScript) on the _server side_ for a
hypermedia-driven application, if that language is the best option for your team. As we said earlier, JavaScript now hypermedia-driven application, if that language is the best option for your team. As we said earlier, JavaScript now
has multiple excellent server-side runtimes, and many excellent server-side libraries available. It might be the best has multiple excellent server-side runtimes, and many excellent server-side libraries available. It might be the best
option for you and your team! option for you and your team!
But it is not, and it shouldn't be, the *only* option for your team. Hypermedia On Whatever you'd Like means just that: whatever you'd like.
But JavaScript is not, and it should not be, the *only* server-side option for your team.
## The Dream of the 90s Is Alive... ## The Dream of the 90s Is Alive...
With the resurgence of interest in (and improvements of) hypermedia an open and diverse future for The Web is now a With the resurgence of interest in (and improvements of) hypermedia, an open and diverse future for The Web is now a
real possibility, if not an emerging reality. real possibility, if not an emerging reality.
The Web was designed to be an open, polyglot & participative hypermedia system and the ship _hasn't sailed_ on that, The Web was designed to be an open, polyglot & participative hypermedia system. The ship _hasn't sailed_ on that dream,
not yet! at least not yet!
We can keep it that way by re-embracing the fundamental technology of the web: hypermedia. We can keep it that way by re-learning and re-embracing the foundational technology of the web: hypermedia.
The [dream of the 90s](https://www.youtube.com/watch?v=TZt-pOc3moc) is alive, with hypermedia. The [dream of the 90s](https://www.youtube.com/watch?v=TZt-pOc3moc) is alive, with hypermedia.

3
www/themes/htmx-theme/static/css/site.css
View File

@ -165,6 +165,9 @@ h4 {
box-sizing: border-box; box-sizing: border-box;
} }
ul li {
padding: 8px;
}
@media(max-width:45rem) { @media(max-width:45rem) {
#nav { #nav {