超媒体在你喜欢的任何东西上
Carson GrossMPA（多页应用）的一个主要剩余优势是（服务器端编程）语言选择。如果你已经是
反 JavaScript 抵抗运动的一部分，那么我在演讲其余部分所说的任何内容都不会
那么重要。但是，我稍后会讨论这一点：那艘船可能已经扬帆起航了…
Rich Harris - Have SPA’s Ruined The Web?
我们喜欢讨论的一个概念是“The HOWL Stack”。HOWL 代表 超媒体在你喜欢的任何东西上。
这是一个半开玩笑的 软件栈，并参考了更著名的栈，如 The LAMP Stack 或 The MEAN Stack。
The HOWL Stack 的 TLDR 是：当你为 Web 应用使用 超媒体驱动的方法 时，你可以
自由选择最适合你问题和你个人技术偏好的 任何 服务器端技术。
感受到 JavaScript 的压力
如果你决定为 Web 应用使用 SPA 框架，你自然会有一个用 JavaScript 编写的大型前端代码库。
鉴于此，下一个问题不可避免地会出现：
“嗯，为什么我们不在后端也使用 JavaScript 呢？”
这是一个合理的问题，在线两端采用相同编程语言有很多优势：
- 你可以在两个代码库之间共享应用逻辑。一个很好的例子是验证逻辑。
- 你可以在两个代码库之间共享数据结构。
- 你可以在单一语言 JavaScript 上积累专业知识，使开发者更容易在应用的各个部分工作。
- 你可以重用你在前端获得的构建系统和依赖管理知识
随着你对 JavaScript 前端生态系统的投资增长，这种采用 JavaScript 的 压力 只会越来越大。
此外，JavaScript 在过去五年中取得了显著改进，现在有多个优秀的服务器端运行时来执行它。许多关于该语言混乱的老论点可以通过 linting、开发者纪律等预防措施来打消。
JavaScript 是 Web 开发思想领袖中的主导语言，有大量教程、代码营等强烈强调该语言。没有什么比成功更成功的了，JavaScript（以及 React） 已经成功了。
我们将这种结果称为 JavaScript 压力，并承认几乎每位从事 Web 开发的开发者至少在某种程度上都感受到它。
超媒体：我们唯一的希望
非 JavaScript 开发者在 Web 开发中有什么希望？
嗯，有一种古老的技术与 JavaScript 一起存在于浏览器中：超媒体。
浏览器提供了优秀的 HTML 支持（以及相关的文档对象模型，或 DOM）。事实上，即使你使用 SPA 框架，你也会以某种形式（例如通过 JSX 模板）使用
该超媒体基础设施，如果你只是为了创建浏览器能理解的 UI。
所以，你将在 Web 应用中以某种方式使用 HTML 或相关的 DOM API。
嗯，如果我们让 HTML 成为一种更强大的超媒体呢？
这就是 htmx 的理念，它使使用超媒体方法实现 常见的现代 Web 应用模式 成为可能。这缩小了传统 MPA 和 SPA 之间的用户体验差距，使超媒体
路线对于更大范围的 Web 应用成为可行的选择。
一旦你采用这种超媒体方法（记住，你反正要使用超媒体基础设施， 所以为什么不尽可能利用它？），就会发生一个令人惊讶的副作用：
突然间，Harris 归因于 MPA 的服务器端语言选择优势 重新回到了桌上。
如果你的应用前端主要用 HTML 编写，也许有一些客户端脚本，
并且没有大型 JavaScript 代码库，你突然大幅减少了（或完全消除了）后端的 JavaScript
压力。
现在，你可以基于其他考虑因素（技术、美学或其他）来选择你的服务器端语言（和框架）：
- 也许你在从事 AI 工作，并想为项目使用 Lisp 变体
- 也许你在处理大数据，并想使用 Python
- 也许你非常熟悉 Django，并喜欢它的一体化方法
- 也许你更喜欢 Flask 及其精简方法
- 也许你喜欢 PHP 的原始、接近 HTML 的感觉
- 也许你有一个现有的 Java 代码库需要一些修饰
- 也许你正在学习 Cobol，并想使用 htmx 为其创建一个不错的 frontend。
- 也许你就是真的很喜欢 Rust、Ocaml、Kotlin、Haskell、.NET、Clojure、Ada、ColdFusion、Ruby… 随便什么！
这些都是完全合理的从技术、哲学和美学角度的观点。
而且，通过将超媒体作为你的主要前端技术，你可以追求这些目标，而无需双重代码库。超媒体不在乎你用什么来生成它：你可以在你喜欢的任何东西上使用超媒体。
为每个人开放的 Web
当我们说“任何东西”时，我们真的是认真的。
这是 htmx discord 的 HOWL 子版块最近的一个截图。请注意，这些只是碰巧有活跃流量的频道，还有更多。
你可以看到我们在各种不同的编程语言和框架中进行持续对话：Java、Go、.NET、 Rust、Clojure、PHP、Ruby、Python、Ocaml。我们甚至有一些人讨论使用 htmx 与 Bash 和 Cobol！
这正是我们想要看到的未来：一个丰富而充满活力的 Web，在其中 每个 后端语言和框架 都可以作为平等且有趣的替代方案。每种语言和框架都有自己独特的优势和文化， 每种都可以贡献于 Web 这个神奇的 超媒体系统。
但是，这是一种 反 JavaScript 抵抗吗？
在结束这篇论文之前，我们确实想讨论一下对 JavaScript 处处 抵抗的想法，这不一定是 反 JavaScript 的。
现在，无可否认，我们嘲笑了不少 关于 JavaScript 的笑话，我们甚至创建了一个 Web 的替代脚本语言，hyperscript。
所以，似乎我们应该是持有会员卡的反 JavaScript 主义者。
但恰恰相反，我们对 JavaScript 深表感激。
毕竟，htmx 和 hyperscript 都是 用 JavaScript 构建的。没有 JavaScript，我们无法创建这些库，无论别人怎么说，它都有一个伟大的优点：就在那里。
我们甚至进一步 推荐 在超媒体驱动的应用中使用 JavaScript 来满足前端脚本需求，只要你以 超媒体友好 的方式编写脚本。
此外，我们不会劝阻某人不要在 服务器端 为超媒体驱动的应用使用 JavaScript（或 TypeScript），如果该语言是你团队的最佳选择。正如我们之前所说，JavaScript 现在 有多个优秀的服务器端运行时和许多优秀的服务器端库可用。
它可能是你和你的团队的最佳选择，在这种情况下没有理由不使用它。
超媒体在你喜欢的任何东西上就是这个意思：你喜欢的任何东西。
但 JavaScript 不是，而且不应该是，你团队的 唯一 服务器端选项。
转舵
随着对超媒体的兴趣复苏（以及改进），Web 的开放和多样化未来现在是一个 真正的可能性，如果不是新兴现实的话。
Web 被设计为一个开放、多语种和参与式的超媒体系统。
那艘船 还没有扬帆起航，至少目前还没有！
我们可以通过重新学习和重新拥抱 Web 的基础技术：超媒体，来保持那个梦想的活力。
我讨厌 htmx 社区已经退化为构建者们互相帮助而不考虑点赞，吸引那些不追逐炒作的人，将简短的字节扩展为细微差别。它可能不会获得廉价的社交媒体积分，但 这是健康的。Web 曾经比这更糟糕。