SPA 替代方案
Carson Gross最近 Tom MacWright 写了几篇关于单页应用及其不满的帖子：
网络开发的流行规范是构建一个 React 单页应用，并使用服务器端渲染。这种架构的两个关键
元素大致是：
- 主要 UI 使用 React 或类似工具在 JavaScript 中构建和更新。
- 后端是一个 API，该应用向其发出请求。
这个想法真正席卷了互联网。它从几个主要流行网站开始，并已蔓延到像营销网站和博客这样的角落。
在这两篇文章中，Tom 阐述了与 React/SPA 无处不在心态相关的问题。如果我用一句话总结它们：SPA 框架往往很复杂，而在许多情况下，你并不会从中获得与之匹配的好处。
一种替代方案
Tom 在第二篇文章中概述了几种 SPA 方法的替代方案，我很高兴地说，他提到了 htmx。然而，
他将 htmx（以及 Stimulus 和 Alpine.js）
分类为“渐进式增强”库。这是一个很好的描述，但至少就 htmx 而言，我认为有一个更好的术语来帮助描述这种风格的库：HTML 中心（或者，或许是 超文本中心）
HTML 中心开发
在 HTML 中心开发中，HTML 不是一个事后考虑，而是被拥抱为应用开发的主要媒介。这与大多数 SPA 框架形成对比，在那些框架中，客户端模型及其操纵它的 JavaScript 是中心焦点。
HTML 中心开发建立在网络的原始模型之上，正如
Roy Fielding 的博士论文 中概述的那样，该论文描述了网络
架构。特别是，通过将 HTML 拥抱为一种超文本，你会获得
REST 和 HATEOAS 的好处，而无需成为这两个主题的专家。
（回想一下，Roy 是在 描述 网络架构，因此原始网络
在很大程度上是 REST-ful 的，而原始参与者无需特别努力）
通过选择 HTML 中心开发，你会获得许多好处：
- 一个更简单的前端允许你将 复杂度预算 节省到后端功能上，
这些功能将你的应用与其他应用区分开来。 - 你不会面临采用后端 JavaScript 的压力“因为前端是用 JavaScript 写的”。这允许
你为特定应用使用最佳的后端框架。 - 借助更简单的前端，“全栈”开发者可以更容易地管理和优化从前端到后端的优化，
导致系统调优更好。 - 你的网络应用反正会包含 HTML，因此通过最大化其效用，你是在提升现有组件的威力，
而不是在最终用户和你的应用代码之间添加另一层复杂度。 - 网络的无状态模型已被证明非常有弹性且易于开发。许多成熟且经过实战考验的
技术和技巧（例如 缓存）存在，用于
构建基于 HTML 的应用。
HTML：糟糕的部分
鉴于 HTML 中心模型的所有这些好处，人们可能会想知道为什么它已被许多网络开发者放弃（并且经常被嘲笑）。从高层来看，答案是：
与基于 JavaScript 的应用相比，HTML 中心应用历史上提供的交互性有限。
这在很大程度上是因为 HTML 是一种有限的超文本。特别是：
- 只有
<a>和<form>可以发出 HTTP 请求 - 只有
click和submit事件可以触发它们 - 只有 GET 和 POST HTTP 方法 被广泛支持
- 请求必须替换整个屏幕，导致笨拙且有时令人震惊的用户体验
当然，这些约束都不是超文本概念的固有部分，而 htmx 的目标是移除它们中的每一个。
通过移除这些约束并将 HTML 完成为一種功能齐全且高功率的超文本，HTML 中心
应用可以在许多应用领域与 SPA 竞争，同时获得上述提到的技术和复杂度好处。
技术上的勇敢
Tom 以这句话结束了他的第一篇文章：
如果每个人都错了呢？我们以前也错了。
网络开发已经走过几次死胡同：GWT、Java Server Faces、Angular 1、FlatUI 等。
在每个这些技术炒作周期的高峰期，反其道而行之是很困难的。在技术世界中这样做尤其困难，
因为在技术上落后不仅仅是对我们自我的威胁，也是对我们就业的威胁。
“No One Ever Got Fired For Using React”
是今天的
“No One Ever Got Fired For Buying IBM”
这是一个我们必须接受的现实，即使我们觉得 React 等并不适合当今构建的许多（甚至大多数）网络
应用。
然而，我们开始看到对 SPA 方法的重新考虑。凭借一点技术上的勇敢，一种愿意
逆众而行的意愿，你或许能够使你的应用少得多复杂度，并将开发努力集中在你的应用做什么上，
而不是它如何做。
来自 htmx 开发者入门套件：
