作者 | Alexander Williams

审校 | 平川

多年来，React 一直占据着统治地位，不仅是作为一个 UI 库，而且是作为全栈 Java 架构的基础。但 Remix 3 正在颠覆这一局面。它挑战了 React 应成为开发宇宙中心的观点，将 Web 基本原理重新置于聚光灯之下。

Remix 3 遵循渐进式增强和服务器优先原则而构建。它不仅优化了性能，还重新定义了我们的构建方式。在一个迷恋客户端的世界里，这个框架提出了一个问题：如果我们不再将 React 视为一个框架，而是开始将其作为一个工具来使用，会怎样？这可能会完全重塑前端架构。

一个敢于打破常规的框架

Remix 3 不只是一个升级，它还是一个声明。多年来，我们围绕 React 构建我们的 Web 应用程序，在样板代码的海洋中构建了互动岛（islands of interactivity）。随后出现了一些框架试图克服 React 的过激行为：Next.js 简化了路由，Gatsby 优化了静态输出，Vite 加快了开发速度。但 Remix 3 呢？它将整个 React 中心思维置于质疑之中。

Remix 3 不再将 React 视为一切都要围绕其运行的太阳，而是将其视为众多工具中的一个。这种转变既微妙又震撼。你仍然要编写 React 组件，但框架不期望你将所有状态、获取逻辑和布局配置都塞进 React 运行时。实际上，Remix 故意避免了许多传统的 React 模式，更偏向于渐进式增强、标准 Web API 和服务器原生思维。

问题不在于 Remix 3 是否“比 React 更好”。问题是：Remix 是否标志着 后 React 架构时代 的开始？

为什么以 React 为中心的架构会成为主流？

React 之所以赢得了前端战争，不仅仅是因为 JSX 或组件，还因为 它为开发者提供了控制权 和多种解决问题的方法。细粒度状态、作用域组件和共定位逻辑的舒适性有很强的吸引力。但随着 React 应用程序的成熟，蔓延也随之愈加严重：重客户端代码库、状态库叠加以及栈间数据获取策略不一致。

Next.js 等框架就是为了弥补这一缺陷而发展起来的。它们用约定俗成的方式修补了 React 的缺陷：基于文件的路由、SSR 和 ISR、API 路由。但这些也只是针对 React 与全栈 Web 不匹配之处的变通方法。开发人员开始构建 React 优先的应用程序，将浏览器视为二等公民。客户端捆绑包膨胀，加载时间受到影响，交互性以复杂性为代价。

本质上，“React 架构”成了一场在 React 协调周期下抽象浏览器和服务器的比赛。Remix 3 提供了一条不同的路线——React 只是视图层，而不是应用程序宇宙的中心。

Remix 3 的哲学：Web 标准优先，React 次之

Remix 3 团队并没有打算取代 React。他们的目标是 修复 Web 开发体验。也就是重新思考数据加载、错误处理、数据变更、导航和缓存，并尽可能以 Web 原生的方式解决它们。因此，Remix 没有发明新范式，而是大量依赖 Web 已经做得很好的事情。

需要加载数据吗？使用在服务器上运行的加载器。需要改变状态吗？使用与表单提交相关的动作。导航？通过增强型链接实现，如果 Java 失败，它可以优雅地降级。Remix 按照 Web 的设计初衷来使用 Web 平台；React 只是你构建 UI 的方式。

强调渐进式增强对性能至关重要。通常，用 Remix 构建的应用程序更快、更有弹性、更易于维护，因为它们依赖的 Java 捆绑包更少，依赖原生浏览器行为更多。更不用说，SEO 和市场营销表明，由于架构更“轻量级”，Remix 构建的网站排名更靠前，与反向链接等排名因素的交互也更好。

重点是什么？Remix 并没有最小化 React；它重新定义了它，使其更具可移植性。

Remix 3 在内部做了哪些改变？

随着 Remix 3 的到来，架构变得更具有可声明性和可组合性，但对 Java 的依赖减少了。路由不仅是 URL 处理器，还是代码和数据责任单元。加载器和动作是路由合约的一部分。错误边界是按路由范围划分的。心智模型不再是“React 组件获取数据”，而是“具有嵌入式逻辑和 UI 的路由”。

这种模型提供了极大的灵活性。想要 完整的服务器端渲染？它已经内置了。只想要激活所需的交互性？很简单。想要部署到 Cloudflare Workers 或在边缘运行？Remix 3 提供了开箱支持。这为开发者提供了逃生仓口（escape hatches），而且不会损害框架的核心理念。

这也意味着依赖减少了。Remix 鼓励让服务器来完成繁重的工作，而不是使用 SWR 或 React Query。当你将逻辑移入加载器和动作，就会默认获得 SSR、缓存和安全性。这就回归了瘦客户端，但仍然具有现代化的开发体验。

对组件思维和可重用性的影响

在传统的 React 架构中，组件边界通常也充当逻辑边界。组件可能会获取自己的数据，跟踪自己的加载状态，处理错误并渲染 UI。这种自主性很强大，但 Remix 不鼓励这样做。Remix 鼓励开发者采用路由思维，并将逻辑隔离到服务器端函数中。

这种转变打破了我们已经习惯的一些模式。不再是 将组件封装在 useQuery 中，然后看着它重新渲染。相反，当组件挂载时，数据已经在那里了。这消除了瀑布流和 Spinner，但需要一个更深思熟虑的数据模型。

可重用组件仍然有其存在的价值，但已经有所不同。它们不再是自包含的逻辑容器，而变成了纯粹的表现形式。Remix 剥离了组件的数据获取能力，从而削弱了它们的作用。结果呢？关注点分离更清晰了，渲染路径更快捷了。

后 React 时代未来一瞥

如果 Remix 3 成功地推广了这种架构，那么它可能会激励一代框架降低将 React 作为默认选择的优先级。我们已经看到了早期迹象。Astro 将 Java 视为可选项，Qwik 将水合作用推迟到绝对必要的时候，SolidJS 则完全放弃了虚拟 DOM。React 不再是终极目标，它只是一个可能的选项。

这些新兴框架联合起来不是反对 React 的立场，而是支持 Web 的立场。它们愿意重新评估 React 的假设：一切都在客户端渲染，Java 为王，组件拥有一切。

从这个角度来看，Remix 3 可能是 React 主导地位和更多元化生态系统之间的桥梁。在这个生态系统中，框架尊重 Web 平台，拥抱部署多样性，并减少对庞大客户端捆绑包的需求。

你应该放弃 React 转而使用 Remix 3 吗？

不，Remix 3 也不希望你这样做。Remix 是以 React 为基础构建的。真正的问题是，你的架构是否仍然需要将 React 视为基础。如果你正在构建一个内容密集型应用、混合渲染型应用，或者需要快速加载及服务器端逻辑的东西，Remix 3 可能正是你所需要的。

但是，如果你的应用程序已经是深度以客户端为中心的，一个仪表板、一个游戏，或者一个具有复杂状态的 SPA，那么以 React 为中心的方法可能仍然最适合你。Remix 不是万能的；它只是一种优先级的转变。

对于习惯于 React 元框架的团队来说，采用 Remix 3 意味着需要放弃一些习惯，但回报也很显著：更快的 TTI、更小的捆绑包、更简单的逻辑路径，以及重新发现 Web 平台已经有多强大。

是一个时代的终结，还是只是一次航向修正？

Remix 3 并不意味着 React 的终结。但它确实挑战了我们共同的假设，即 React 应该始终位于我们技术栈的核心。其架构提醒我们，Web 是一个强大、有弹性的平台——我们已经围绕它做了太多工作。

这不仅仅是一个趋势；这是一个重新校准。Remix 3 不拒绝 React，它将其从从未打算做的工作中解放出来。这是会成为一种新常态，还是会成为一种小众哲学，取决于开发者接下来做什么。

但有一点是清楚的：Remix 3 已经在前端对话中点燃了火焰。这不仅是关于我们使用什么工具，还关于我们如何看待 Web 本身。