【CSDN 编者按】Web 应用程序的三元悖论是我们尝试可视化当前 Web 框架及其应用模式时不得不做出的一些权衡。

原文链接：https://generalreasoning.com/posts/2023/web-app-trilemma

未经允许，禁止转载！

译者 | 弯月
责编 | 夏萌出品 | CSDN（ID：CSDNnews）

当前 Web 应用程序的状态很棘手。我们希望拥有一个快速响应式 UI、一个简单的状态（最好能集中到一个地方），而且最重要的是，我们希望 UI 能够正确反映状态。

为什么？客户喜欢快速的应用程序，但状态管理是主要难题所在。界面出错，用户就会非常失望。

Web 应用程序的三元悖论是我们尝试可视化当前 Web 框架及其应用模式时不得不做出的一些权衡。这种三元悖论表明，在 Web 应用程序中，快速且正确的 UI 和简单、集中的状态，二者不可能同时兼得。

三元悖论

这里所说的三元悖论可归结如下：

• 为了获得快速的 UI，我们不得不牺牲状态的简单性或 UI 的正确性（不可避免地引入错误）。

• 为了实现正确的 UI，我们不得不放弃状态的简单性或速度。

• 为了实现简单的状态，我们不得不在 UI 的正确性或速度上做出妥协。

下面，我们来仔细研究一下这三方面的权衡。

假设放弃快速反应式 UI 的要求。那么，我们只需实现简单的状态和正确的 UI。我们可以把状态集中到一个地方（后端），然后应用程序仅负责状态的可视化。在这种情况下，我们可以采用无状态架构，也就是请求-响应式的 Web 应用程序原本的样子。服务器端框架能在这种架构中能发挥巨大作用。

假设放宽简单状态的要求，我们就有机会加快 UI 的速度。着眼于正确且快速的 UI，我们就可以引入加载状态、注水等操作，实现最优的 UI。在这种情况下，用户感知的延迟是最小的。但为了达到这种效果，我们扭曲了应用程序的状态：UI 不仅需要更新缓慢的服务器驱动状态，还需要更新客户端状态。这会引入分布式状态，即状态被分割到客户端和服务器。为了保持 UI 的正确性，我们必须仔细划分二者的职责。后端不再是唯一的真实数据来源。

这就是当前 JavaScript 框架的做法：前端加 API 层。每个人都试图避免将可变状态保存到服务器上。根据这个三元悖论，一个简单的中心化状态很难满足需求。

而没有人想要的一种情况是简单的状态与快速的 UI（大多数教程似乎都是这种情况）。在这种情况下，前端会发送很多请求，而 UI 会卡住，不停地显示加载图标。状态分布并复制到无数请求中，每个请求都很简单。但当作为一个整体时，就会产生包含许多不正确状态的组合。错误处理和极端情况（例如竞争条件）被忽略。用户界面速度很快，但像水晶球一样脆弱，也像水晶球一样没什么用。

三元悖论是真的吗？

有些框架试图将这三者结合起来。这些技术位于三角形的某个中间位置。然而到目前为止，还没有任何一个框架能够实现三位一体。

我们注意到出现了两种不同的方法。一些框架依赖于事件驱动的架构。他们的目标是用 RPC 调用取代部分浏览器的请求响应网络。

还有一些框架则强调使用最少的 JS，在服务器端呈现静态 HTML。这些框架与原始的超媒体约定保持一致，并且更多地依赖于浏览器功能。

如果真的能打破 Web 应用程序的三元悖论，这些框架也许就是一线希望。

推荐阅读：

▶ Linux 内核崩了，只因拔掉罗技的 USB 接收器.....

▶编写一个 “Hello World” 的 Web 服务器，Go、Node.js、Nim 和 Bun 谁更快？

▶中国大模型掌门人首次集结、全球研发中心掌门人齐聚现场，1024 程序员节「岳麓对话」重磅官宣！