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