SPA 的其他实现方式

押韵了，哈哈。

我前几天在 播客中提到，我有点觉得 WordPress 应该自带 Turbolinks。它的前提非常简单

1. 构建一个服务器端渲染的网站。
2. Turbolinks 拦截来自同一来源链接的点击。
3. 它使用 AJAX 获取新页面的 HTML，并用新页面替换当前页面。

换句话说，通过添加这个库，将服务器端渲染的应用转换为“单页应用”（SPA）。

为什么要这样做？它可以稍微快一点。与 SPA 相比，完整的页面刷新可能会感觉很慢。Turbolinks 是一种有点“老旧”的技术，但它仍然非常有用。事实上，Starr Horne 最近写了一篇关于 在 Honeybadger 迁移到 Turbolinks 的很棒的博文

Honeybadger 不是单页应用，而且可能永远不会是。对于我们的技术需求来说，SPA 毫无意义。来看一下

• 我们的应用主要用于显示静态信息页面。
• 我们处理大量数据来生成单个错误报告页面。
• 我们只有一个由四位开发人员组成的非常小的团队，因此我们希望代码库尽可能地小巧和简单。

……多年来，我们一直在使用一种方法，它让我们能够鱼与熊掌兼得……它的核心思想是，您可以在没有大量 JavaScript 的情况下获得类似 SPA 的速度。

这就是我对 WordPress 的意思。默认情况下，它以服务器端渲染的方式工作非常好，但它也可以通过 Turbolinks 这样简单的方法从 SPA 中获益。您始终可以 自己添加它。

仅仅保留您的服务器端渲染站点并不是一件坏事。如果您保持页面轻量级并缓存资源，那么您可能就没事了。

Chrome 开始了一些新的想法

• “绘制保持” 减少了页面加载之间的白屏闪烁。
• “Portal” 元素 将有助于在页面之间过渡而无需重新加载。 请注意可访问性问题。

我毫不怀疑这种服务器端渲染但增强为 SPA 的方法是帮助普及 Next 和 Gatsby 等方法的原因。

我不想贬低“真正的”SPA 方法的强大功能。网络是网站速度慢的主要罪魁祸首，因此，如果一个应用被设计成传输相对较小的数据片段（而不是相对较大的 HTML 块），然后计算它可以重新渲染的最小 DOM 部分并执行此操作，那么这非常棒。好吧，也就是说，直到 瓶颈变成 JavaScript 本身。

令人遗憾的是，SPA 方法通常以完全不进行服务器端渲染为代价。同样令人遗憾的是，“水合”服务器端渲染应用以使其成为 SPA 的成本是以占用 JavaScript 中的主线程为代价的。

进退两难。

幸运的是，存在渲染选择的光谱 用于选择合适的架构。