itsscb/htmx
1
0
Fork 0
mirror of https://github.com/bigskysoftware/htmx.git synced 2025-09-29 05:51:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into dev

Browse Source 
# Conflicts:
#	www/attributes/hx-swap-oob.md
#	www/essays/a-response-to-rich-harris.md
#	www/img/js-devs-be-thinking.png
This commit is contained in:
carson 2022-01-12 23:19:10 -07:00
commit eb74e39912
7 changed files with 123 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
package.json
View File

@ -14,6 +14,7 @@
"files": [
"LICENSE",
"README.md",
"src/htmx.d.ts",
"dist/*.js",
"dist/ext/*.js",
"dist/*.js.gz"

10
test/scratch.html
View File

@ -24,12 +24,12 @@
<script src="util/scratch_server.js"></script>
<script>
// this.server.respondWith("GET", "/test", '<a hx-get="/test2">Click Me</a>');
// this.server.respondWith("GET", "/test2", "Clicked!");
//
// make('<div hx-get="/test">dd</div>')
htmx.logAll();
// htmx.logAll();
// var i = 1;
// this.server.respondWith("GET", "/test", function(xhr){
@ -62,6 +62,12 @@ Autorespond: <input id="autorespond" type="checkbox" onclick="toggleAutoRespond(
</div>
<script>
this.server.respondWith("GET", "/preserve", 'foo');
</script>
<div hx-post="/preserve" hx-trigger="every 1s">
<iframe hx-preserve='true' id='iframe1' width="300" height="200" src="https://www.youtube.com/embed/Z1oB2EDu5XA" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
</body>
</html>

154
www/essays/a-response-to-rich-harris.md
View File

@ -1,27 +1,27 @@
---
layout: layout.njk
tags: posts
title: A Response To Rich Harris
title: A Response To "Have Single-Page Apps Ruined the Web?"
---
# A Response To Rich Harris
# A Response To "Have Single-Page Apps Ruined the Web?"
[Rich Harris](https://twitter.com/rich_harris) is a well-known web developer who on [Svelte.js](https://svelte.dev/), a novel
[Rich Harris](https://twitter.com/rich_harris) is a well-known web developer who works on [Svelte.js](https://svelte.dev/), a novel
Single-Page Application (SPA) framework.
In October of 2021, he gave a talk at JamStack entitled ["Have Single-Page Apps Ruined the Web?"](https://www.youtube.com/watch?v=860d8usGC0o).
In October of 2021 he gave a talk at JamStack entitled ["Have Single-Page Apps Ruined the Web?"](https://www.youtube.com/watch?v=860d8usGC0o).
We have been asked for our opinion on the talk, so this essay is our response.
The first thing to say about the talk is that it is very well done: thoughtful, funny, fair to both sides of the debate
and reasonable throughout. We don't agree with a lot that Mr. Harris has to say, as we will detail below, but we respect
The first thing to say about the talk is that it is very well done: well produced, thoughtful, funny, fair to both sides of the debate
and very reasonable throughout. We don't agree with a lot that Mr. Harris has to say, as we will detail below, but we respect
and appreciate his opinions as well as the technologies he works on.
## Problems with SPAs
The talk begins with some reasonable criticisms of SPAs, particularly pointing out usability issues found
with Instagram, a canonical SPA implementation from our friends at Facebook. All in all, he takes a very fair look at
the drawbacks to SPAs, including the following:
The talk begins with some reasonable criticisms of SPAs, particularly focusing on usability issues found
with Instagram, a canonical SPA implementation from our friends at Facebook. He takes a very fair look at
the drawbacks to SPAs, including but not limited to the following list:
* You will need a bloated JS framework
* Performance will suffer
@ -39,94 +39,127 @@ After considering the usability issues with Instagram, Mr. Harris has this to sa
Here we find ourselves in violent agreement with Mr. Harris, with the caveat that we would substitute "the *javascript* web platform"
for just "the web platform", since that is what is in play with Instagram.
We would further clarify that SPA applications and frameworks often simply *ignore* the web platform, that is,
the original, [REST-ful model](/essays/rest-explained.md) of the web, except perhaps as a bootstrap mechanism.
We would further clarify that SPA applications and frameworks often simply *ignore* the *actual* web platform, that is,
the original, [REST-ful model](/essays/rest-explained.md) of the web, except as a bootstrap mechanism.
## Problems with MPAs
Mr. Harris then moves on to problems with Multi-Page Applications (MPAs) which are the "traditional",
click-a-link-load-a-page-of-HTML web applications that are, to an extent, being supplanted by SPAs.
click-a-link-load-a-page-of-HTML web applications we are all familiar with and that are, to an extent,
being supplanted by SPAs.
We will go through the problems he outlines, all of which are valid when discussing "standard" MPAs,
we will demonstrate how a Hypermedia-centric technology like htmx can solve each of them, while still remaining within the
general category of MPA.
Below, we will go through the various problems he outlines, all of which are true of "standard" MPAs,
and we will demonstrate how an MPA using a hypermedia-oriented technology, [htmx](/), can solve each of them.
### "You Can't Keep A Video Running"
### "You Can't Keep A Video Running On Navigations"
A general problem with standard MPAs is that they issue a full page refresh on
every request. This means something like a video or audio player will be replaced and, thus, stop playing, when a request is made. This can be addressed in htmx via the [`hx-preserve`](/attributes/hx-preserve) attribute, which tells htmx to preserve a particular piece of content between requests.
every request. This means something like a video or audio player will be replaced and, thus, stop playing, when a request is made.
This problem can be addressed in htmx via the [`hx-preserve`](/attributes/hx-preserve) attribute, which tells htmx to
preserve a particular piece of content between requests.
### "Back Button & Infinite Scroll Don't Work"
In the presence of infinite scroll behavior (presumably implemented via javascript of some sort) the back button will not work properly with an MPA. I would note that the presence of infinite scroll calls into question the term MPA, which would traditionally use paging instead of an infinte scroll.
That said, [infinite scroll](/examples/infinite-scroll) can be achieved quite easily using htmx, in a hypermedia-oriented and obvious manner. And, when combined with the [`hx-push-url`](/attributes/hx-push-url) attribute, history and the back button works properly with very little effort by the developer, all with nice Copy-and-Pasteable URLs.
That said, [infinite scroll](/examples/infinite-scroll) can be achieved quite easily using htmx, in a hypermedia-oriented and obvious manner. When combined with the [`hx-push-url`](/attributes/hx-push-url) attribute, history and the back button works properly with very little effort by the developer, all with nice Copy-and-Pasteable URLs, sometimes referred to as "Deep Links" by people in the SPA community.
### "What about Nice Transitions"
### "What about Nice Navigation Transitions?"
Nice transitions are, well, nice, although we think that designers tend to over-estimate their contribution to application usability. htmx, however, supports transitions using [standard CSS transtions](https://htmx.org/examples/animations/) to make animations possible. Obviously there is a limit to what you can achieve with these techniques, but we believe there is an 80/20 (or 95/5) rule in play in this regard.
Nice transitions are, well, nice. We think that designers tend to over-estimate their contribution to application usability, however. Yes, the demo sizzles, but on the 20th click users often just want the UI to get on with it.
That being said, htmx supports using [standard CSS transtions](https://htmx.org/examples/animations/) to make animations possible. Obviously there is a limit to what you can achieve with these pure CSS techniques, but we believe this can give you the 80 of an 80/20 situation. (Or, perhaps, the 95 of a 95/5 situation.)
### "Multipage Apps Load Javascript Libraries Every Request"
Mr. Harris focuses heavily on "crappy Ad Tech" as a culprit for web usability issues, and who can defend the 2.5MB payload of tracking, spyware and adware that most websites deliver to their users today? He says that SPAs ameliorate this issue by loading up the bundle of garbage once, rather than over and over as an MPA does.
Mr. Harris focuses heavily on "crappy Ad Tech" as a culprit for web usability issues on the web, and who can defend the 2.5MB payload of tracking, spyware and adware that most websites deliver to their users today? Mr. Harris points out that SPAs ameliorate this issue by loading up this bundle of garbage once, rather than over and over on every request, as an MPA does.
Now, a vanilla MPA would typically have said garbage cached after the first request, so the download cost, at least, is about the same as with SPAs. However, an MPA powered by htmx has exactly the same characteristics as an SPA: said garbage would be downloaded and executed once, and after that all requests would be relatively light-weight replacements of DOM elements.
Now, a vanilla MPA would typically have said garbage cached after the first request, so the download cost, at least, is about the same as with SPAs. But an MPA must *execute* the bundle of garbage again on each page, which does burn CPU and can lead to poor user experience.
However, an MPA powered by htmx, we note, has exactly the same characteristics as an SPA: the ad garbage would be downloaded and executed once on the first request, and, after that, all requests will be relatively light-weight replacements of DOM elements.
### "MPAs Have Network Latency Issues"
This is a valid point: with an MPA-style hypermedia approach you are gated by how fast your server can respond to requests. However, there are well-known techniques, developed over decades, for monitoring and optimizing this response time and, to be frank, the SPAs we work with day-to-day are often plenty laggy. On top of that, the complexity of optimistically synchronizing data with a server can lead to extremely difficult to understand data consistency issues and, a topic we will return to, a significant increase in application complexity.
This is a valid point: with an MPA-style application your UI interactions are gated by how fast your server can respond to requests, its latency. Part of that is network latency, which is hard to overcome without giving up one of the tremendously simplifying aspects of traditional web applications: a centralized data store. However, networks are fast and are getting faster, and there are well-known techniques for optimizing *server* latency (i.e. how fast your server returns a response), developed over decades, for monitoring and optimizing this response time. SQL tuning, Redis caching and so on, all well established and making sub-100ms responses a reasonable goal. Many htmx users remark just how fast htmx-based applications feel, but we won't pretend that latency isn't an issue to be considered.
Of course the problem with latency issues is that they can make an app feel laggy. But, like you, we have worked with plenty of laggy SPAs, so we must say the problem isn't neatly solved by simply adopting SPA frameworks. On top of that, optimistically synchronizing data with a server can lead to extremely difficult to understand data consistency issues as well as a significant increase in overall application complexity, a topic we will return to later.
### "Github Has UI Bugs"
Github does, indeed, have UI bugs, it's true. But none of them are particularly difficult to solve. htmx offers multiple ways to [update content beyond the target element](https://htmx.org/examples/update-other-content/), all of them quite easy and any of which would work to solve the UI consistency issues pointed out.
Github does, indeed, have UI bugs. However, none of them are particularly difficult to solve.
Compare and contrast with the engineering work required to fix the bugs that Mr. Harris pointed out in Instagrams web application. We know which issues we'd rather fix.
htmx offers multiple ways to [update content beyond the target element](https://htmx.org/examples/update-other-content/), all of them quite easy and any of which would work to solve the UI consistency issues Mr. Harris points out.
Contrast the Github UI issues with the Instagram UI issues Mr. Harris pointed out earlier: the Instagram issues would
require far more sophisticated engineering work to resolve.
## Transitional Applications
Mr. Harris then discusses the concept of "transitional applications" which are a mix of both SPA and MPA technologies. This terminology is reasonable, we'll see if it sticks. We recommend using htmx for the parts of the app it makes sense and kicking out to other technologies when needed: vue.js, alpine.js, etc. and so we can recommend a "transitional" approach to web development.
Mr. Harris then discusses the concept of "transitional applications" which are a mix of both SPA and MPA technologies.
This terminology is reasonable, and we will see if the term sticks in the industry.
We often recommend using htmx for the parts of the app it makes sense to keep things simple, and then using other
technologies when needed: [alpine.js](https://alpinejs.dev/), [hyperscript](https://hyperscript.org), a small reactive
framework, etc.
So we can agree with Mr. Harris here to an extent and recommend a "transitional" approach to web development, although
we would recommend leaning MPA/hypermedia when possible, whereas it seems fairly certain Mr. Harris would lean SPA/javascript.
## The Elephant In The Room: Complexity
Unfortunately, there is a topic that Mr. Harris does not discuss, and we believe this may be because he doesn't see it. As he is a javascript developer who is passionate about that language and swims in the engineering culture of front end frameworks, the current *complexity* of javascript front end development seems natural to him. But, for many of us, the javascript ecosystem is simply *insanely* overly-complicated. Comically so, given the requirements of most web applications.
Unfortunately, there is a topic that Mr. Harris does not discuss, and we believe this may be because he doesn't see it. He is a javascript developer who is passionate about that language and who swims in the engineering culture of front end frameworks, so the current *complexity* of javascript front end development seems natural to him. For many of us, however, the javascript ecosystem is simply *insanely* overly-complicated. Comically so, in fact, given the requirements of most web applications.
Many of the "transitional" technologies that Mr. Harris goes on to mention: [React Server Components](https://vercel.com/blog/everything-about-react-server-components) (which he calls "like html over the wire, but vastly more sophisticated), [Marko](https://markojs.com/) (which is doing "partial hydration"), [Quik](https://github.com/BuilderIO/qwik) (which aggressively lazy loads things, apparently), are all remarkable engineering achievements, but are also all, we must say, quite complicated.
This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer. "Simple" is disparaging and "sophisticated" is high praise.
This is, unfortunately, part of the culture of front end development right now: sky-high levels of complexity are tolerated in application frameworks, in build tool chains, in deployment models and so on, and, when problems arise due to all this complexity, more complexity is often offered as the answer.
This complexity is overwhelming many developers and development teams. As Mr. Harris himself points out when discussing Instagram, even some of
"Simple" is disparaging and "sophisticated" is high praise.
This complexity is overwhelming many developers and development teams today. As Mr. Harris himself points out when discussing Instagram, even some of
the best front engineers in the world appear to be unable to keep it all under control.
So there is a cultural issue here.
But there is a technical one as well:
There is a technical issue as well.
The technical issue is what we will call "The Hypermedia Approach" vs. "The Remote Procedure Call (RPC) Approach". When web applications moved from MPAs to SPAs, they adopted, often unwittingly, the latter RPC approach to application development: AJAX moved to JSON as a data serialization format and largely ([and correctly](/essays/hypermedia-apis-vs-data-apis/)) abandoned the hypermedia concept. This abandonment of The Hypermedia Approach was driven by the admitted usability issues with vanilla MPAs.
This technical issue can be summarized as "The Hypermedia Approach" vs. "The Remote Procedure Call (RPC) Approach".
It turns out, however, that those usability issues often *can* [be addressed](/examples) using The Hypermedia Approach: rather than *abandoning* Hypermedia for RPC, what we need is a *more powerful* Hypermedia. This is exactly what htmx gives you.
When web applications moved from MPAs to SPAs, they adopted, often unwittingly, an RPC approach to application development:
AJAX moved to JSON as a data serialization format and largely ([and correctly](/essays/hypermedia-apis-vs-data-apis/))
abandoned the hypermedia concept. This abandonment of The Hypermedia Approach was driven by the admitted usability
issues with vanilla MPAs.
It turns out, however, that those usability issues often *can* [be addressed](/examples) using The Hypermedia Approach:
rather than *abandoning* Hypermedia for RPC, what we needed then and what we need today is a *more powerful* Hypermedia.
This is exactly what htmx gives you.
By returning to The Hypermedia Approach, you can build reasonably sophisticated web applications that address many of
Mr. Harris's concerns regarding MPAs, at a fraction of the complexity required by most popular SPA frameworks. And, for free,
you get all [the benefits](https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_concepts) that Roy Fielding
outlined with a truly REST-ful architecture.
Mr. Harris's concerns regarding MPAs at a fraction of the complexity required by most popular SPA frameworks. Further, without
thinking about it very much, you will get all [the benefits](https://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_concepts)
that Roy Fielding outlined about truly REST-ful architectures.
Is this architecture right for all web applications? Obviously not.
Is The Hypermedia Architecture right for all web applications? Obviously not.
Is it right for many, perhaps most, web applications? We certainly think so.
Is it right for many, and perhaps most, web applications? We certainly think so, at least in part.
## Javascript: The Resistance
Now we get to the most emotionally charged claim made in the talk: that "the ship has sailed" on javascript, and we should
accept that it will be the dominant programming language in web development going forward.
Now we get to the most emotionally charged claim made in the talk: that "the ship has sailed" on javascript, and that
we should accept that it will be the dominant programming language in web development going forward.
Mr. Harris believes that it will be [edge computing](https://en.wikipedia.org/wiki/Edge_computing) that will be the
driver that finally eliminates the remaining, scattered opposition to javascript.
We are not so sure about that.
Mr. Harris mentions edge computing as a driver for javascript adoption, but we do not expect edge computing to figure in the
majority of web applications for the forseeable future, or, frankly ever. CPU is cheap and microservices are a mess. Don't @ us.
To the contrary, we do not expect edge computing to figure in the majority of web applications for the foreseeable future.
Or, to be frank, ever. CPU is cheap, network speeds are fast and increasing and microservices are a mess.
And, contra what Mr. Harris says, today the [trend is not obviously in javascripts favor](https://insights.stackoverflow.com/trends?tags=java%2Cc%2Cc%2B%2B%2Cpython%2Cc%23%2Cvb.net%2Cjavascript%2Cassembly%2Cphp%2Cperl%2Cruby%2Cvb%2Cswift%2Cr%2Cobjective-c). Five years ago, we (as, yes, members of the javascript resistance) were despairing of any hope of stopping the Javascript juggernaut.
But then something unexpected happened: Python took off and, from the looks of it, javascript has, well, flat lined:
And, contra what Mr. Harris says, today the [trend is not obviously in javascripts favor](https://insights.stackoverflow.com/trends?tags=java%2Cc%2Cc%2B%2B%2Cpython%2Cc%23%2Cvb.net%2Cjavascript%2Cassembly%2Cphp%2Cperl%2Cruby%2Cvb%2Cswift%2Cr%2Cobjective-c). Five years ago, we, as founding members
of the javascript resistance, were despairing of any hope of stopping the Javascript juggernaut. But then something
unexpected happened: Python took off and, at the same time, javascript flat lined:
<div style="text-align:center">
@ -134,22 +167,37 @@ But then something unexpected happened: Python took off and, from the looks of i
</div>
Does this mean javascript will go away?
This trend of javascript peaking in the mid-2010's can be observed [on Github](https://www.benfrederickson.com/ranking-programming-languages-by-github-users/) as well:
<div style="text-align:center">
![Javascript Devs](/img/language-trends-github.png)
</div>
Now, does this mean javascript will eventually "lose" to Python and go away?
Of course not. Javascript is a core technology of the web and will be with us forever. Without it, we couldn't have built
htmx (or [hyperscript](https://hyperscript.org)) to replace it, so we are very thankful, in a funny sort of way, for javascript.
htmx (or [hyperscript](https://hyperscript.org)) so we are very thankful for javascript.
But this does mean that the future does not *necessarily* belong to javascript, as appeared to be the case say five years ago.
But this *does* imply that the future of the web does not *necessarily* belong to *entirely* javascript, as appeared to be the case
say five years ago.
We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, whatever. Even javascript, if you like. There's no accounting for taste, after all.
We are fond of talking about the HOWL stack: Hypermedia On Whatever you'd Like. The idea is that, by returning to a (more powerful) Hypermedia Architecture, you can use whatever backend language you'd like: python, lisp, haskell, go, java, c#, whatever. Even javascript, if you like.
That's a world we'd rather live in: many programming language options, each with their own strengths, technical cultures and thriving
communities, all able to participate in the web development world through the magic more powerful hypermedia. Diversity, after all, is our strength.
Since you are using hypermedia & HTML for your server interactions, you don't feel that pressure to adopt javascript on
the backend that a huge javascript front end produces. You can still use javascript, of course, (perhaps in the form of alpine)
but you use it in the manner it was originally intended: as a light, front end scripting language for enhancing your
application. Or, if you are brave, perhaps you can try [hyperscript](https://hyperscript.org) for these needs.
And so, in conclusion,
This is a world we would prefer live in: many programming language options, each with their own strengths, technical cultures and thriving
communities, all able to participate in the web development world through the magic of more powerful hypermedia, rather than a
monolith of SPAs-talking-to-Node-in-JSON. Diversity, after all, is our strength.
<dov style="text-align:center">
In conclusion,
<div style="text-align:center">
![Javascript Devs](/img/js-devs-be-thinking.png)
</dov>
</div>

BIN
www/img/js-devs-be-thinking.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 381 KiB

After

Width:  |  Height:  |  Size: 205 KiB

BIN
www/img/language-trends-github.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 34 KiB

2
www/posts/2021-11-22-htmx-1.6.1-is-released.md
View File

@ -2,7 +2,7 @@
layout: layout.njk
tags: ['posts', 'announcements']
title: htmx 1.6.1 has been released!
date: 2021-10-02
date: 2021-11-22
---
## htmx 1.6.1 Release

16
www/talk.md
View File

@ -5,20 +5,26 @@ title: </> htmx - high power tools for html
## htmx Talk
[htmx discord server](/discord)
[htmx Discord Server](/discord)
[Github Discussions](https://github.com/bigskysoftware/htmx/discussions)
## Feature Requests & Bug Reports
[https://github.com/bigskysoftware/htmx/issues](https://github.com/bigskysoftware/htmx/issues)
[Github Issues](https://github.com/bigskysoftware/htmx/issues)
## Social
[@htmx_org on Twitter](https://twitter.com/htmx_org)
[#htmx on Stack Overflow](https://stackoverflow.com/questions/tagged/htmx) Please send us the URL via Discord after creating the question.
[#htmx on Stack Overflow](https://stackoverflow.com/questions/tagged/htmx)
(NB: *Please post the StackOverflow question URL to the [Discord](https://htmx.org/discord) after creating the question for
faster service.)*
[r/htmx on reddit](https://www.reddit.com/r/htmx/)
Email: [htmx@bigsky.software](mailto:htmx@bigsky.software)
<iframe src="https://github.com/sponsors/bigskysoftware/card" title="Sponsor bigskysoftware" height="225" width="600" style="border: 0;"></iframe>
@ -51,6 +57,7 @@ title: </> htmx - high power tools for html
* [Hypermedia APIs vs. Data APIs](/essays/hypermedia-apis-vs-data-apis)
* [Complexity Budget](/essays/complexity-budget)
* [SPA Alternative](/essays/spa-alternative)
* [A Response To "Have SPA's Ruined The Web"](/essays/a-response-to-rich-harris)
## Podcasts
@ -58,7 +65,8 @@ title: </> htmx - high power tools for html
* [JS Party - Less JavaScript more htmx](https://changelog.com/jsparty/171)
* [Software Breakthroughs for the 21s Century](https://www.youtube.com/watch?v=O4ZFIx1ckSg)
* [Django Chat](https://djangochat.com/episodes/htmx-carson-gross)
* [Talk Python](#https://talkpython.fm/episodes/show/321/htmx-clean-dynamic-html-pages)
* [Talk Python](https://talkpython.fm/episodes/show/321/htmx-clean-dynamic-html-pages)
* [.NET Rocks!](https://podtail.com/en/podcast/-net-rocks/htmx-with-carson-gross/)
[Contact Us](mailto:podcasts@bigsky.software) to Join You on Your Podcast!