超媒体，随你喜欢
卡森·格罗斯剩下的一个主要优势（MPA 的优势）是（服务器端编程）语言的选择。如果你已经是抗议 JavaScript 运动的一部分，那么我在这次演讲中剩下的内容对你来说可能并不重要。
但是，我稍后会谈到：这艘船可能已经启航了……
Rich Harris - SPA 是否毁掉了 Web？
我们喜欢谈论一个概念，叫做“HOWL 堆栈”。HOWL 代表超媒体，随你喜欢。
这是一个开玩笑但并非完全是玩笑的 软件堆栈，也是对更著名的堆栈（如 LAMP 堆栈 或 MEAN 堆栈）的引用。
HOWL 堆栈的 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 之间的 UX 差距，使采用超媒体路线对于更多类型的 web 应用程序来说变得可行。
一旦你采用了这种超媒体方法（记住，你无论如何都会使用超媒体基础设施，所以为什么不尽可能地利用它呢？），一个惊人的副作用会出现
突然，Harris 归因于 MPA 的服务器端语言选择优势重新回到桌面上。
如果你的应用程序前端主要是用 HTML 编写的，可能还会有一些客户端脚本，并且没有大型 JavaScript 代码库，那么你已经显著减少（或者完全消除）了后端上的 JavaScript 压力。
你现在可以根据其他考虑因素（技术、美观或其他）来决定你的服务器端语言（和框架）。
- 也许你正在人工智能领域工作，并希望为你的项目使用 Lisp 变体。
- 也许你正在大数据领域工作，并希望使用 Python。
- 也许你非常了解 Django，并且喜欢它所采用的包含一切的方法。
- 也许你更喜欢 Flask 和它所采用的精简方法。
- 也许你喜欢 PHP 的原始、接近 HTML 的感觉。
- 也许你有一个现有的 Java 代码库，需要进行一些改进。
- 也许你正在学习 Cobol，并希望使用 htmx 为它创建一个漂亮的前端。
- 也许你真的很喜欢 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 来满足前端脚本需求，只要你以 超媒体友好 的方式进行脚本编写。
此外，如果 JavaScript（或 TypeScript）是你的团队的最佳选择，我们不会阻止你在超媒体驱动的应用程序的服务器端使用 JavaScript（或 TypeScript）。正如我们之前所说，JavaScript 现在有多种优秀的服务器端运行时和许多优秀的服务器端库可用。
它可能是你和你团队的最佳选择，在这种情况下，没有理由不使用它。
超媒体，随你喜欢，就是这个意思：你喜欢什么就用什么。
但 JavaScript 并非也不应该成为你团队的唯一服务器端选择。
#扭转乾坤
随着人们对超媒体的兴趣重新燃起（以及超媒体的改进），开放而多元的 Web 未来现在已经成为现实，如果不是正在出现的现实。
Web 的设计初衷是成为一个开放、多语言和参与式的超媒体系统。
而且，那梦想还没有破灭，至少现在还没有！
我们可以通过重新学习和重新拥抱 Web 的基础技术——超媒体，来保持这个梦想的活力。
我讨厌 htmx 社区已经退化为互相帮助的建设者，而不考虑点赞，也不理会那些没有追逐炒作的人，将短语扩展为细微差别。这可能不会在社交媒体上得分，但这是健康的。Web 过去曾经比这更糟糕。