摘要：近日，一位 React 生态的核心参与者 Mark Erikson，深度分析了现在 React 及社区的现状，包括 React 发展方向、开发方式、推荐使用方案、服务器组件等方面的争议和社区的困惑与担忧。Erikson 自 2015 年起就开始使用 React

近日，一位 React 生态的核心参与者 Mark Erikson，深度分析了现在 React 及社区的现状，包括 React 发展方向、开发方式、推荐使用方案、服务器组件等方面的争议和社区的困惑与担忧。Erikson 自 2015 年起就开始使用 React，是 Redux Toolkit 的创建者，Redux 作为 React 常用的状态管理工具在 React 社区中颇具知名度。

从大多数衡量标准来看，React 及其相关框架是当今构建应用程序的主流方案。根据 Stack Overflow 最新调查，JavaScript 是使用最广泛的语言，TypeScript 在专业程序员中的普及度紧随其后，而 React 及其衍生的 Next.js 则是最受欢迎的 Web 框架。

但 Erikson 承认，React 及其生态如今是“复杂和支离破碎的”。同时，社区对 React 存在不少不满。更糟糕的是，每个人都在围绕这些问题的不同子集展开争论，且许多陈述的担忧要么是错误的，要么完全是恐慌性言论（FUD）。

Vercel 已经接管了 React？

答案是：反了

首先，React 团队力推 React 服务器组件（RSC），但文档中仅将 Vercel 赞助的 Next.js 列为完整实现方案；且 Next.js 在 Vercel 托管时性能最佳，这引发了外界质疑：Vercel 是否将 React 导向为其平台的“入口”，而非保持供应商中立的框架。

现在一种极为普遍的观点是： “Vercel 在主导 React 的发展，目标是通过托管网站赚取更多利润”。今年早些时候，Reddit 上一条获得最高点赞的评论称：“Vercel 实际上已经接管了 React，其主要利益在于推动用户使用部署在 Vercel 上的 NextJS，从而让 Vercel 的股东更富有。”

这种观点与其他几个相关担忧交织在一起：

React 文档中优先推荐 Next，且在 “哪些功能构成了 React 团队的全栈架构愿景？” 部分，Next App Router 被列为主要示例；

Next 仍是唯一可投入生产的 RSCs 实现方案；

有 React 团队成员曾称 “Next 的这次版本发布才是真正的 React 18”。

对此，Erikson 指出，从他了解的所有情况来看，这种观点颠倒了因果关系，且存在误解。

React 在 2011-12 年左右在 Meta（前身为 Facebook） 内部开发，并在 2013 年开源。问题在于，React 服务器组件（RSCs）是 React 团队对未来编写 React 应用方式的愿景。当 Meta 的 React 团队确信应该在框架中构建服务器端组件时，他们需要一个外部赞助商。

当前，React 的开发工作由两家公司赞助和拥有：Meta 和 Vercel。但从一开始，React 就是 Meta 旗下的项目。尽管代码是开源的，任何人都可以提交 PR，但本质上所有开发工作都由 Meta 的 React 团队完成，这对 React 的开发方式产生了重大影响。

React 核心团队的会议通常是内部的，路线图规划也是如此。React 团队经常会针对某个问题领域设计半打左右的原型方案，然后让 Meta 内部的应用团队试用并进行评估。当新的 React 功能宣布时，它已经经过了多次内部迭代，并在实际使用中得到了验证。与此同时，React 团队还负责为 Meta 的应用团队提供 bug 修复和其他支持。

尽管如此，React 团队在开发库的方式上还是相当自由的。虽然 React 是在 Facebook 内部为 Facebook 的使用而创建的，但 React 团队自己决定了该库的路线图和长期愿景。在很大程度上，React 的实际开发过程和路线图是由他们自己驱动的，而不是受 Facebook/ Meta 内部其他因素的影响。也就是说，他们也必须证明自己的工作成效以及项目如何使 Meta 受益。

对于 React，Meta 的使用广泛但又不同于社区的使用方式。Meta 拥有自己庞大的服务器基础设施，包括数据获取、路由、安全等方面的标准技术。Meta 发明了 GraphQL 协议以及 Relay GraphQL 客户端层，并经常将它们与 React 代码一起使用。这意味着 Meta 对 React 的使用很少需要第三方库来解决路由、状态管理、样式或其他社区常见的问题。

而 Vercel 主要是一个 Web 应用托管平台，其盈利模式主要依靠吸引更多用户在其平台上托管应用，并通过提供便捷的使用体验来收费。该公司投入了大量工程资源用于开发 Next.js 框架（以及支持其他框架），并使其能在 Vercel 基础设施上轻松设置和部署 Next 应用。同时，Vercel 首席执行官 Guillermo Rauch 一直是 React 及其能力的坚定支持者。

2021 年底，一些 React 核心团队成员离开 Meta 加入 Vercel。先是 React 团队负责人 Sebastian Markbage 离开 Meta 加入 Vercel，这是 React 核心团队成员首次在 Meta 以外的机构全职工作。随后，核心团队成员 Andrew Clark 和前 React 组织负责人 Tom Occhino 也相继加入。此前，React 团队已在内部对 RSC 功能进行了大量原型设计，并参与设计 Next.js 的 App Router，而 Vercel 也让更多工程师开始为 React 的核心功能和服务器渲染能力做出贡献。

“从外部来看，我的理解是 React 团队找到了 Vercel 并提出他们对 RSC 的愿景，而 Vercel 同意在 RSC 开发过程中成为新的试验场。”Erikson 表示，“我也没有看到证据表明 Vercel 在主导 React 的设计，或者对框架和 RSC 的强调是为了让 Vercel 盈利。”

正如 React 核心成员 Dan Abramov 所描述的：

Vercel 团队分配了许多全职工程师多年的时间来实现 React 团队想要的功能。这并不是说要直接接受 React 团队的技术指导。Next.js 几乎是从零开始重写的。现在设计 Next.js 的人正是发明 React Hooks 的人。因此，如果说有什么不同的话，这更像是 React 团队 “接管” 了 Next.js 的发展方向，而不是 “偏爱” 它。

当然，Next 对 React 也提出过一些 “需要这样改” 的需求。Erikson 回忆道，在某次 NextConf 前夜，React 仓库合并了多个 PR，而那次会议宣布了重要的 Next 版本更新（可能是 13.4 中稳定的 App Router）。但即便如此，完成这些工作的仍是 React 团队成员。

React 现有的服务器渲染方法（如 renderToString 和 renderToPipeableStream）可以在任何地方调用，例如 Express 路由处理程序。然而，从架构上讲，RSC 要复杂得多。RSC 功能需要解析代码以查找'use client'和'use server'指令，然后转换代码以插入适当的调用，从而向 RSC 核心功能注册客户端组件和服务器函数。这需要与捆绑器紧密集成，以便它可以正确确定服务器和客户端的完整模块图并对其进行适当编译。

此外，尽管 React 核心实现了实际的 RSC 功能，并提供了在客户端和服务器之间发送序列化组件和数据的原语，但实际上需要由框架在正确的位置调用和使用这些原语。这主要涉及与路由器的集成，以便客户端应用接收正确的延迟加载客户端组件，并使用操作和数据调用正确的端点。

这意味着，RSC 的设计方式导致每个框架对其的使用和实现都各不相同。Next 通过 App Router 在处理布局和路由方面做出了非常具体的实现决策。其他框架和构建工具（如 Waku、Parcel 和 React Router）已经在做出一些截然不同的设计决策。

Erikson 将 RSC 描述为一种“混合功能”，其主要功能在 React 核心平台中，但缺少额外的打包工具、路由器和框架配置就无法使用。这意味着 React 团队无法独立推出完整的 RSC 实现方案。

事实上，React 团队也曾努力让其他框架和公司参与这一过程。Shopify 的 Hydrogen 框架对 RSCs 进行了一些早期测试并提供了反馈，但最终认为它不适合自身需求。Remix 团队多次被问及是否愿意参与，但最初决定专注于自己的方案。

因而，Next 成为了第一个（实际上仍是唯一一个）“可投入生产” 的 RSC 实现方案。但如今，其他几个框架（包括 Parcel、React Router 和 Waku）正在致力于 RSC 集成，不过 Next 的 App Router 仍是目前使用 RSC 的唯一广泛选择。

当前有不少网友严肃或疑惑地称，“React 现在只能和 Next 一起用”。Erikson 表示，这一说法很容易被反驳。他解释道，只需查看 “创建新 React 项目” 页面，就能看到除 Next 之外的其他框架，以及颇具争议的 “我可以不使用框架来使用 React 吗？” 部分。

“显然，这是对 React 工作机制的完全误解。但这也反映出围绕 React、使用框架以及 Vercel 影响力的信息已变得多么令人困惑。”

据 Erikson 介绍，React 库（尤其是 ReactDOM）本身并不限制页面内的使用方式。使用者可以提供一个近乎空白的 HTML 占位符，并渲染 React 组件树以在客户端生成完整页面内容（即单页应用 “SPA”）；也可以将 React 用于服务器渲染（SSR）—— 服务器动态响应每个请求，或静态站点生成（SSG）—— 在构建时预生成静态 HTML 页面。使用者也能使用任何语言或框架（如 Python + Django、Ruby + Rails、PHP + WordPress、.NET 等）提供静态或服务器渲染的 HTML 页面，并在页面中嵌入 React 以增加交互性。

尽管如此，到 2015 年，React 最常见的用法仍是客户端 SPA 架构。这类架构与其他方案一样存在权衡：优势在于简化页面内容生成（全由 React 组件构成）、加速用户交互（点击或路由切换时仅更新组件而非刷新整个页面），并支持更丰富的应用体验；后端技术栈（JS、Java、PHP、.NET、Python）也无关紧要 —— 只需暴露 JSON API 供数据获取。但缺点是初始页面的资源包加载较慢，且客户端路由可能导致与原生浏览器行为不一致的交互体验。

早期客户端的数据获取通常需要手动处理，并在副作用中加入复杂逻辑（例如在组件首次渲染时通过 componentDidMount 触发数据请求）。这类操作常借助 Redux 处理数据获取和缓存，但相关代码往往充斥着模板化逻辑和复杂性。后来，React Query、Apollo、SWR 和 RTK Query 等专用数据获取库通过提供定制 Hook 和预建缓存机制，极大简化了客户端数据获取流程。

Next 和 Remix 等框架为 React 服务器渲染提供了标准化方案，内置基于文件系统的路由约定，但当时缺乏服务器端数据获取的统一规范。Next 首创了与组件并列定义异步获取函数的机制（如 getServerSideProps），Remix 随后推出了类似架构的 “loaders”。但两者都未完全融入 React 的原生设计。

这引发了 React 生态系统的整体思维转变：一方面更推崇基于 SSR 的架构，以改善页面加载体验、减少页面所需 JS 量，并避免在客户端使用数据获取库；另一方面，React 团队大力反对数据获取中的 “瀑布效应” 以提升页面加载性能，甚至像 React Router 和 TanStack Router 等客户端路由器也提供了在路由 / 页面层级预获取数据的方式，而非在组件树深层触发获取。

“我应该使用 Next 还是 React？”，这一问题也频繁出现在开发者们的讨论中。Erikson 指出，从字面上看，人们认为 “Next” 和 “React” 是不同的事物，这显然是错误的。Next 是使用 React 库的框架，它是 React 的超集，而非竞争对手。大多数人真正想问的或许是 “我应该使用 Next，还是使用 CRA 或 Vite 这样的客户端 SPA？”，但他们没有准确表达这一问题的术语。

另一个争议点是，为何 React 团队如此坚决地要求所有 React 用户使用框架，甚至声称不这样做就是错误的？Erikson 并不认为他们主张 “使用框架” 的目的是 “让人们使用 Next 并在 Vercel 上托管”，而是背后有其他的逻辑。

Andrew Clark 在 2023 年 1 月的推文清晰阐述了这一意图：

如果现有应用未使用框架，应逐步迁移；如果创建新项目，应从一开始就使用框架。你选择的 React 框架应内置数据获取、路由和服务器渲染方案。框架不会将这些视为独立问题 —— 它们提供深度集成的解决方案，易于使用且开箱即得优异性能。

如果你选择放弃框架，实则是在选择构建自定义框架，而这很可能比现成方案差得多。即使你认为当前的自定义框架比其他选项更好，一年后还会如此吗？

跟上技术前沿需要大量时间和精力：你准备好成为框架维护者了吗？还是说，你的时间本可以用于更有价值的事？

此后的主要变化是框架变得愈发强大。过去，纯 React + Webpack 的方案曾优于或等同于一体化框架，但在我看来，这已不再成立。问题不在于 “是否可以不使用框架构建 React 应用”—— 这始终是一个选项。关键在于：你自行搭建的方案能否在功能、性能和开发者体验上与行业领先框架竞争？技术门槛正在不断提高。

同样，Dan Abramov 在解释为何考虑弃用 Create React App（CRA）时提到：

CRA 仅解决了问题的一面。它提供了良好的（在当时）开发体验，但缺乏足够的结构设计，无法帮助开发者利用 Web 的优势打造优质用户体验。你可以尝试自行解决这些问题，但需要 “弹出” 并大幅定制配置，这违背了 CRA 的初衷。每个真正高效的 React 项目都是定制化的，且无法通过 CRA 实现。

这些用户体验问题并非 CRA 独有，甚至不是 React 特有的。例如，基于 Vite 首页模板创建的 Preact、Vue、Lit 和 Svelte 应用也面临相同问题。这些问题是纯客户端应用（不支持静态站点生成（SSG）或服务器端渲染（SSR））的固有缺陷。

如果使用 React 构建完整应用，支持 SSG/SSR 至关重要。CRA 对它们的缺失显而易见，但这并非唯一落后之处。

React 本身只是一个库，不规定路由或数据获取方式，CRA 亦然。遗憾的是，这意味着仅靠 React 或按初始设计的 CRA，都无法解决这些问题。如你所见，这不是单一功能缺失，而是服务器渲染、静态生成、数据获取、打包和路由等功能的联动缺失。

时代在变化。如今，推荐一个不具备这些功能的方案变得越来越困难。即使你不立即使用所有功能，它们也应在需要时可用。你不应为了利用这些功能而迁移到不同模板并重构所有代码。同样，并非所有数据获取或代码拆分都需要基于路由，但这应成为大多数 React 应用的合理默认选项。

Erikson 谈到，他曾与 React 团队交流后得知，他们已听到许多关于 React 应用加载慢、整体性能差的外部抱怨。因此，对框架的强调是对此的直接回应，目标是让更多应用默认具备良好性能。

总的来说，React 团队的立场为：

框架内置数据获取、路由和服务器渲染方案，且设计为协同工作；

这些能力开箱即用，无需花费时间挑选可能不兼容的组件；

由于构建配置和更优的数据获取模式，框架默认提供更好的性能；

React 服务器组件（RSC）需要集成到框架中才能正常工作；

这些考量是 React 团队认为 “当今应如何使用 React” 的核心。

换句话说，这是意识形态立场、“框架能节省时间精力” 的信念，以及 “大多数 React 应用遵循相似模式、需要相似解决方案” 的判断的综合结果。

另外，需注意 “服务器渲染” 的特别提及。总体而言，React 团队和生态系统其他关键成员（如 Remix/React Router 的 Ryan Florence 和 Michael Jackson 都高度强调服务器渲染的必要性，以避免客户端数据获取的 “瀑布效应”（如获取一组项目、渲染子组件、挂载后再触发子组件的获取等）。Next 和 Remix 等框架正是为开箱即支持服务器渲染而设计。

围绕 SSR 的 “更快初始页面加载”“客户端 JS 更少”“避免瀑布效应” 等理由都合情合理。Erikson 也认同，客户端 SPA 在许多场景下被过度使用（与 Redux 类似），且即使当下不需要所有功能，从框架起步仍是合理的，以便在需要时利用这些特性。值得注意的是，Next 和 Remix 确实具备 “SPA / 导出” 模式，仅输出静态 JS/HTML 资源，因此无需 Node 服务器即可创建纯客户端应用。但这些并非默认模式，且我认为大多数社区成员甚至不知道有此选项。

考虑到所有这些方面，Erikson 认为 React 团队决定将框架作为默认推荐是合理的。但 Erikson 也承认，这种 “推荐” 已演变为过于宽泛的指令，未能充分尊重生态系统中 React 实际使用方式的多样性。毕竟，使用全栈 React 框架有诸多理由，但不使用的理由也不少：

框架增加了许多额外特性和功能，但也带来了学习复杂度，使它们不太适合仅尝试掌握 React 基础的初学者；

复杂度增加可能导致困惑，例如在服务器组件中意外使用 Context 或 Hook（会抛出错误）；

许多公司可能不运行 JS 后端，甚至可能有相关规则限制；

具备服务器功能的框架需要特定托管环境，而纯 SPA 可轻松托管在任何提供静态 HTML 和 JS 的平台（包括 GitHub Pages 和 Amazon S3）；

尽管选择库常让 React 用户感到沮丧，但这确实支持定制项目以满足特定需求。 opiniated 框架（注：指有明确设计倾向性的框架）消除了大多数决策的需要，但也可能限制后续定制能力；

对 “服务器渲染” 的强调显然对某些类型的应用有帮助，但并非全部 —— 许多应用仅需运行在客户端。

无论事实是否如此，Erikson 都承认 React 社区和生态系统已出现分裂。他指出，React 团队期望框架的使用方式与社区实际使用方式之间的分歧日益扩大。下载数据显示，“React 生态系统中对纯单页应用（SPA）项目的需求仍然很高。”

不过，社区中有人觉得 Erikson 忽略了一些关键问题。一条针对他帖子的评论称：“现实是，2025 年的 React 前景堪忧。尽管经过了三年多的开发和上述 SPA 改进，它仍是最慢的前端框架，仍然存在相同的记忆化（memoization）和重新渲染问题，在样式、路由和状态管理方面仍处处与开发者‘作对’。”

另一个 Erikson 未提及的是过度复杂性。一位开发者在 Reddit 上表示：“到目前为止，对我来说最大的问题是服务器端渲染（SSR）和框架带来的额外复杂性。React 团队将‘框架’与‘纯 React 构建 SPA’作为选项呈现的方式，感觉他们活在一个完全不同的世界里，甚至不理解我的担忧。”

另一条评论称，尽管 React 仍是目前最好的选择，“但在我使用 React 的 6 年多时间里，我的团队首次将大量时间用于处理 React/Next 的特定问题，而非我们自己的业务逻辑。”

这些问题对 React 团队来说难以解决，而分裂的生态系统可能会促使人们关注其他解决方案。

来源：晚晚的星河日记一点号