译者前言
这篇文章来自 Redux 维护者 Mark Erikson，他作为 React 生态核心参与者，深度解析了当前围绕 React 发展方向、服务端组件、NextJS等话题的社区争议，对理解 React 的发展和生态现状具有重要参考价值。
引言
今天，React 及其生态系统的状态是复杂且分裂的，既有成功，也有怀疑和争议。
从积极的方面来看：React 是使用最广泛的 UI 框架，其概念影响了整个 JS 生态系统的其余部分。React 团队在经过多年开发后最近发布了 React 19。这是一个重大版本，包括官方稳定的 React Server Components 支持、用于处理 Promise 的新 use Hook、多个新的表单集成功能，以及删除了许多长期被弃用和过时的功能。
然而，我观察到并经历了 React 社区对 React 的发展方向、开发方式、推荐的使用方法，以及 React 团队与社区之间的互动，都产生了越来越多的挫折感和分歧。这又与在过去几年中在 React 和一般 Web 开发社区中反复出现的数十种不同争论重叠，以及对 React 工作方式的具体技术担忧、与其他类似 JS 框架的比较，以及 Web 应用程序在未来应该如何构建等问题。
让这一切变得更糟的是，每个人都在争论和辩论这些关注点的不同子集，而许多声明的关注点要么是错误的，要么完全是 FUD（恐惧、不确定和怀疑）。不幸的是，争论和恐惧也因沟通问题、自造的营销失误以及 React 团队本身缺乏开发者关系工作而变得复杂。所有这些都紧密交织在一起。
我参与了社交媒体上的许多相关讨论。我写了许多评论，既为 React 团队辩护也批评他们，解释他们为什么做出某些决定或事情实际上是如何发生的，推动改进文档和解释等等。
试图涵盖其中的一些主题需要一篇详尽而详细的文章（我甚至不会涉及"React 是否糟糕/React 与其他工具相比如何？"这些话题，因为它们更加超出了范围）。但是，在花费了太多时间进行辩论和解释之后，我觉得有必要写一篇综合性的文章来一起涵盖这些话题中的许多内容。
我还基于本文中的主题做了一个演讲。
目标
我这篇文章的目标是：
- 概述 React 发展历程
- 描述推动 React 发展的力量
- 澄清为什么以及 React 最近的发展方向是如何发生的，并解释这项工作背后的一些架构决策
- 澄清并消除关于 React 发展动机和社区用户的担忧与困惑
背景：我在 React 社区中的角色和贡献
（也就是"我是谁，你为什么应该相信我的描述，你为什么应该关心我对此的看法？😄"）
我不是也从未是真正的 React 团队的一部分。话虽如此，自 2015 年以来我一直深度参与 React 生态系统，可以说我是 Meta 或 Vercel 之外任何人中"React 社区核心圈子"的一部分。
简而言之：
- 我从 2015 年开始使用 React
- 我维护 Redux 系列库，为 React 做过贡献，并参与 React 生态系统讨论
- 我写了许多关于 React 和 Redux 的长篇教程，并经常就 React 和 Redux 发表演讲
- 在大部分时间里，我一直参与主要 React 社区部分的管理工作
列出这些成就的目的是建立我在 React 如何开发、React 社区中发生了什么、React 团队内部发生了什么以及试图帮助人们学习 React 和 Redux 方面拥有悠久的历史和专业知识。
偏见和注意事项
由于这是互联网，我会尝试预先解决一些人们可能对我写这篇文章有的担忧。
由于我维护 Redux，这确实偏向了我对 React 如何使用的看法，以及我处理的问题类型。
我绝对不总是正确的，由于知识有限、误解或过度概括，我肯定会最终错误地描述一些事情。也就是说，我写这篇文章是一个真诚的努力，尽可能诚实和准确地描述历史、动机和行为。
因此，在声明了所有这些注意事项后，我们开始吧。
React 的简史
早期历史在其他地方得到了更好的覆盖，包括 React 纪录片，但为了为这篇文章的其余部分提供一些背景：
React 在 2011-12 年左右在 Facebook 内部开发，并在 2013 年开源。它聚集了一些外部贡献者，但直到最近，所有实际开发都是由 Facebook / Meta 内部的 React 核心团队完成的。
虽然 React 的核心概念始终保持不变（组件、props、state、数据流），但实现细节、公共 API 和范围的广度随着时间的推移发生了变化。React 从使用 createClass 创建组件，到 ES6 class MyComponent extends React.Component，再到 function MyComponent()。React 从仅支持 Web 分裂为支持移动端的 React Native，然后通过可定制的 react-reconciler 核心变得可定制以支持其他平台，如 WebGL（react-three-fiber）和 CLI（ink）。内部完全重写为新的"Fiber"架构，解锁了进一步的架构变化。函数组件在 2018 年随着 hooks 的发布获得了拥有状态和副作用的能力。
多年来，React 将自己定位为一个最小的以 UI 为中心的渲染库（"MVC 中的'V'"，"一个用于构建用户界面的 JS 库"）。像 Angular 或 Ember 这样的其他框架是完全包含电池的，对如何构建和结构化应用程序有重要意见，但 React 团队将所有这些留给了社区。这导致了生态系统的大规模爆炸，无论好坏。对于任何可想象的库类别，都有数十种竞争工具解决重叠问题：状态管理（Redux、Mobx、Zustand 等）、CSS 和样式（Styled-Components、Emotion、CSS Modules 等）、数据获取（React Query、Apollo、SWR、RTK Query 等）、构建工具（Babel、Webpack、ESBuild、Vite、Parcel 等）等数百种。
React 用户在开发项目中，总是必须通过选择一系列生态库来解决应用程序中的需求。此外，React 可以以多种方式使用：在单页应用程序（SPA）中在客户端渲染每个元素，渲染附加到服务器渲染页面的多个子树，在服务器上作为多页应用程序（MPA）的一部分等等。生态系统选项的灵活性和多样性既是优势也是劣势。你可以为你的项目选择所需工具的确切组合...但你也必须选择工具组合。这导致决策疲劳、项目代码库的变化以及常用工具的不断变化。
总的来说，React 库和 React 团队都故意保持非意见化。他们不想在生态系统中的特定工具上偏爱，他们的时间和注意力集中在构建 React 本身上，他们仍然认为 React 的范围有些狭窄。
生态系统的多样性提供了灵活性，但也带来了复杂性。这在构建工具方面尤其如此。早期的 React 教程经常在开始时花费多页解释"这是如何配置 Webpack 和 Babel"，然后你才能编写你的第一个 React 组件。这导致 React 团队构建了一个名为 Create React App 的预包装构建工具配置。CRA 是一个 CLI 工具，可以从模板生成新的 React 项目，并使用高度复杂和定制的 Webpack + Babel 配置构建它，该配置旨在使用单个命令轻松启动新项目。该配置被保持为黑盒封装，以隐藏复杂性。
React 从未有过内置的数据获取方法，因此使用第三方库获取和缓存数据是标准做法。React 早期就有服务器渲染（SSR）功能，可以将 React 组件树渲染为 HTML 字符串或流的方法，但这些必须在服务器处理程序中手动使用。随着时间的推移，其他预包装的 React 构建系统和"框架"变得流行。Next.js 也包装了 Webpack，但添加了更多功能，如带有文件系统路由约定和基于页面的数据获取的内置服务器渲染。Gatsby 从基于 GraphQL 的数据源生成站点。后来，Remix 添加了服务器"数据加载器"并推动了更多基于 HTML/平台的使用约定。
在 2020 年末，React 团队宣布了"React Server Components"的原型，这是一种架构方法，允许异步 React 组件在服务器上运行并获取数据，然后渲染子组件并将子组件和数据传递给在客户端运行的 React。这旨在成为数据获取的 React 惯用解决方案，并标志着从 React 最初的"仅在客户端查看"历史宣传的重大转变。在 RSC 开发期间，一些 React 核心团队成员离开了 Meta 并加入了 Vercel，Next.js 的创建者。他们继续构建初始的 RSC 实现，并与 Next 开发团队合作，使用新的"App Router"重新架构 Next，这是 RSC 的第一个生产实现。
React 团队还花费了 2020-2023 年从头开始完全重写 React 文档站点。react.dev 上的新 React 文档有一个精彩的教程，逐步介绍 React 的概念，在页面中有许多可运行沙盒中的示例，以及大大改进的 API 参考页面。
当新文档出现时，React 团队在他们推荐使用 React 的方式上做出了重大转变。以前，旧的 React 文档推荐如果你正在学习或构建客户端 SPA，则从 CRA 开始，或者如果你需要 SSR 或静态网站，则指向其他一些框架，如 Next 或 Gatsby。在新文档中，React 团队改变了他们的方法，并开始具体且强烈地推荐"你应该使用框架来编写 React 应用程序 - 它们内置了路由、数据获取和构建功能"。这也与构建 RSC 的工作相关联。作为其中的一部分，"开始新的 React 项目"页面专门警告不要在没有框架的情况下使用 React。Next 在该文档页面上显著列出 - 在"框架"列表中排名第一，并作为唯一的 RSC 实现被提及。在 Vercel 工作的 React 团队成员被引用说"我认为即将到来的 Next.js 版本是'真正的'React 18 版本"。
这与 Create React App 在 2022 年左右有效死亡相关联。它在此之前已经有一段时间没有维护了。当一个 PR 被提交建议"将 CRA 标记为已弃用并推荐 Vite"时，Dan Abramov 写了一个详细的评论解释为什么创建 CRA，CRA 的问题，框架的兴起，以及 React 愿景的转变。作为回应，React 社区集体从 CRA 迁移，文档停止推荐它，但没有做任何事情正式将其标记为"已弃用"。
React 与其所有者的关系
今天，React 的开发工作由两家公司赞助和拥有：Meta（前 Facebook）和 Vercel。
Facebook / Meta
从一开始，React 就是一个 Facebook / Meta 拥有的项目。代码是开源的，任何人都可以提交 PR，但基本上所有开发工作都是由 Meta 的 React 团队完成的。
这对 React 的开发方式产生了重大影响。React 核心团队会议通常是内部的，任何路线图也是如此。React 团队经常为问题空间原型化半打想法，然后让 Meta 的应用程序团队尝试它们进行审查。当宣布新的 React 功能时，它已经经历了许多内部迭代并在实际使用中得到了验证。同时，React 团队还负责通过错误修复和其他支持来支持 Meta 的应用程序团队。
尽管如此，React 团队在如何开发库方面拥有相当自由的手。虽然 React 是在 Facebook 内部为 Facebook 使用而创建的，但 React 团队本身决定了他们的路线图和库应该如何工作的长期愿景。在大部分情况下，React 的实际开发过程和路线图是由他们自己驱动的，而不是由 Facebook / Meta 内部的其他影响驱动的。也就是说，他们也必须证明自己的表现以及项目如何使 Meta 受益。
Meta 自己对 React 的使用既广泛又与社区使用方式不同。Meta 拥有自己庞大的服务器基础设施，包括用于数据获取、路由、安全等的标准技术。Meta 发明了 GraphQL 协议，以及 Relay GraphQL 客户端层，并经常将这些与他们的 React 代码一起使用。这意味着 Meta 的 React 使用很少需要第三方库来解决社区其余部分常见的路由、状态管理、样式或其他问题。
Vercel、Next 和 React
Vercel 主要是一个 Web 应用程序托管平台。他们主要通过让更多人在他们的平台上托管应用程序来赚钱，并为更容易使用的便利性收费。他们在构建 Next.js 框架（以及支持其他框架）方面投入了大量工程时间，并使在 Vercel 基础设施上设置和部署 Next 应用程序变得微不足道。
Vercel 的首席执行官 Guillermo Rauch 是 React 及其功能的长期信徒，正如他 2015 年的博客文章 Pure UI 所示，该文章谈到了 React 渲染模型的力量。
在 2021 年末，React 团队负责人 Sebastian Markbage 离开 Meta 加入 Vercel。这是全职 React 核心团队成员在 Meta 以外的任何地方工作的第一个实例。后来核心团队成员 Andrew Clark 和前 React 组织负责人 Tom Occhino 也加入了他。Sebastian 和 Andrew 开始在 React 中实现 RSC 功能并设计 Next.js App Router，Vercel 还有其他工程师开始为 React 的核心和服务器渲染功能做贡献。
今天，React 团队分布在 Meta 和 Vercel 之间（大多数仍在 Meta），还有少数团队成员或外部的一致贡献者。
React 使用模式
标准 React 架构
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，极大地简化了客户端上的数据获取，提供了专门构建的 useQuery hooks 和预构建的缓存机制。
像 Next 和 Remix 这样的框架提供了使用内置文件系统路由约定进行 React 服务器渲染的标准化方法。然而，没有基于服务器的数据获取的约定。Next 发明了一个 getServerSideProps 机制来指定一个异步函数，用于与组件一起获取。Remix 后来发明了具有类似架构的"加载器"。这些都不感觉特别原生于 React。
这导致了 React 生态系统中的一般思维转变。更多地推动基于 SSR 的架构来改善页面加载体验并最小化页面所需的 JS 量，以及删除在客户端使用数据获取库的需要。React 团队大声反对数据获取中的"瀑布"以改善页面加载性能，甚至像 React Router 和 TanStack Router 这样的客户端路由器也提供了在路由/页面级别预获取数据的方法，而不是在组件树深处触发获取。
React 构建工具使用
值得查看几个主要 React 相关构建工具和框架的下载统计数据，以了解生态系统中随时间和今天的使用规模。
粗略地说，今天在思维份额和/或下载方面的主要选项工具是：
- Next.js（SSR / SSG / RSC / SPA）
- Remix / React-Router v7（SSR / SSG / SPA）
- Vite（SPA）
- Create React App（SPA）
也值得注意的是，Vite 本身从 Vue 生态系统开始，但已成为一个标准化和广泛使用的构建工具，支持许多不同的客户端框架。它还有一个插件生态系统，包括 React 支持的插件，并已成为各种框架的首选构建工具。这包括 Remix / React-Router，它们最近从内部使用 ESBuild 切换到提供 Vite 插件以启用其 SSR 和 SSG 支持。
直到最近，React 文档还将 Gatsby 列为 Web 的推荐框架，将 Expo 列为 React Native 的唯一推荐框架。Gatsby 在被 Netlify 收购后有效死亡。与此同时，Astro 是一个更通用的专注于静态站点的工具，支持包括 React 在内的许多框架。以下是它们的下载统计数据进行比较： 
从这些统计数据中得出的一些要点：
- Next.js 是使用最广泛的
- Vite 的 React 插件稳步增长，现在是第二大使用最广泛的 React 相关构建工具
- CRA 使用在 2023 年中期达到峰值，此后一直在下降，但仍然有相当大的使用量
- Remix 在这一点上有很强的口碑，但相对较小。React Router 被非常广泛地使用，但支持"框架模式"的新版本没有那么广泛采用
- Gatsby 从未有接近 Next、CRA 或 Vite 的吸引力，Astro 最近超过了它
- Astro 不是 React 特定的，但下载量与 Remix 大致相同
- Vite + CRA 一起等于 Next 的使用量，这表明在 React 生态系统中仍然有对普通 SPA 项目的强烈需求
深入 React Server Components
React Server Component 开发和 Vercel
React 团队在 Meta 的基础设施中有服务器端数据获取的经验，以及自动拆分 JS 包和延迟加载代码。然而，与之前的 React 功能开发不同，他们真的无法在 Meta 内部设计和原型化 RSC。毕竟，Meta 已经有了自己的服务器基础设施，所以他们无法在那里进行原型化并让应用程序团队尝试。
值得注意的是，React Server Components 是 React 团队对如何在未来编写 React 应用程序的愿景。据我所知，这不是 Meta 或 Vercel 提出的，或者推动 React 团队构建的东西。
多年来一直有间歇性的讨论和抱怨"React 的所有开发都是由 Meta 员工完成的"，偶尔有评论说"如果有一个'React 基金会'，或者 Meta 以外的人直接在 React 上工作，那会很好"。虽然我不知道涉及的实际讨论，但从外部看，我的理解是 React 团队找 Vercel 推销了他们的 RSC 愿景，Vercel 同意成为 RSC 开发的新试验场。这导致 Sebastian Markbage（后来是 Andrew Clark）从 Meta 转移到 Vercel，Next 团队花费大量时间、金钱和工程努力来设计和构建 Next App Router 作为 RSC 的第一个工作实现。
Vercel 团队已经分配了许多全职工程师年来实现 React 团队想要的东西。这不是说直接从 React 团队获取技术方向。Next.js 或多或少从头开始重写。 现在设计 Next.js 的人是发明 React Hooks 的人。所以如果有什么的话，更多的是 React 团队"接管"Next.js 方向的情况，而不是"偏爱"它。
有努力让其他框架和公司参与这个过程。Shopify 的 Hydrogen 框架对 RSC 进行了一些非常早期的测试和反馈，但最终得出结论它不适合他们。Remix 团队被多次询问是否愿意参与，但最初决定专注于他们自己的方法。
结果，Next 成为第一个（并且实际上仍然是唯一的）"生产就绪"的 RSC 实现。今天，其他几个框架正在致力于 RSC 集成（包括 Parcel、React Router 和 Waku），但 Next 的 App Router 是今天使用 RSC 的唯一有意义的选择。
RSC、框架和打包器
我经常看到像"为什么 RSC 需要打包器或框架？为什么它们不能直接内置到 React 中？"这样的问题。
React 现有的服务器渲染方法，如 renderToString 和 renderToPipeableStream，可以在任何地方调用，比如 Express 路由处理程序。然而，在架构上 RSC 要复杂得多。RSC 功能需要解析代码以查找 'use client' 和 'use server' 指令，然后转换该代码以插入适当的调用来向 RSC 核心功能注册客户端组件和服务器函数。这需要与打包器紧密集成，以便它可以正确确定服务器和客户端的完整模块图，并适当地编译它们。
此外，虽然 React 核心实现了实际的 RSC 功能，并提供了在客户端和服务器之间发送序列化组件和数据的原语，但由框架在正确的地方实际调用和使用这些原语。这主要是关于与路由器的集成，以便客户端应用程序接收正确的延迟加载的客户端组件，并使用操作和数据调用正确的端点。
这也意味着每个框架对 RSC 的使用和实现将是不同的。Next 在 App Router 中为处理布局和路由做出了非常具体的实现决策。其他框架和构建工具，如 Waku、Parcel 和 React Router，已经在做一些非常不同的设计决策。
总的来说，RSC 是一个不寻常的混合功能。主要功能直接内置到 React 核心包中，但该功能在集成到某种打包器/路由器/框架组合中之前无法使用。
社区担忧和困惑
有了所有这些历史背景和上下文，让我们来回答（并希望澄清或消除）几个经常被重复提及的担忧，这些担忧要么是基于误解，要么是恶意传播的不实信息，甚至是彻头彻尾的阴谋论。
担忧1：Vercel、Next 和 React
现在有一个极其常见的观点，即"Vercel 正在推动 React 开发，目标是通过托管网站赚更多钱"。例如，这是今年早些时候 Reddit 线程中投票最高的评论：
"Vercel 实际上已经接管了 React，主要兴趣是推动用户使用 NextJS，部署在 Vercel 上，这样 Vercel 股东就能变得更富有。"[www.reddit.com/r/react/com...]
有几个点引起这种担忧：
- Next 在 React 文档中首先推荐，Next App Router 也作为"哪些功能构成了 React 团队的全栈架构愿景？"下的主要示例被提及
- Next 仍然是 RSC 的唯一生产实现
- React 团队成员被引用说"这个 Next 版本是真正的 React 18"
我可以看到人们如何得出这个结论。Vercel 雇用了几个 React 团队成员，他们同时在 React 本身和 Next 上工作。从时间线上看，这确实自然地与 RSC 的开发以及推动用户使用框架的新转变相吻合...而且看，"明显的"框架确实是 Next！与此同时，Vercel 投入了大量资金和努力使 Next 易于在 Vercel 上部署和托管。可以在其他地方托管 Next，但总是有一些不工作的功能或难以配置的东西。
尽管如此，从我看到的一切来看，这种观点通常颠倒了因果关系，缺乏事实依据。是的，当然 Vercel 投资于他们认为最终会为他们赚钱的努力。但是，根据上述内容，我看到的描述 Seb 和 Andrew 去 Vercel 以及 RSC 开发过程的所有内容都说这是 React 团队推动了这套变化。
RSC 是 React 团队的愿景。它们无法在 Meta 内部有效地进行原型化和测试，所以第一次需要一些其他赞助商来投资开发并提供迭代设计的环境。我不知道它是如何发生的具体情况，但我的理解是 React 团队说服 Vercel 买入 React 团队的愿景，并让他们推动重新架构 Next 以设计匹配该愿景的 App Router 方法。
确实有一些"Next 需要这个"类型的对 React 的更改。我知道我在 React 仓库中看到了几个 PR 在其中一个 NextConf 之前的晚上合并，该会议有重要的 Next 版本公告（可能是 13.4 中的稳定 App Router？）。但是，仍然是 React 团队成员在做那项工作。
在这一点上，React 团队是分裂的。大多数仍在 Meta，但 Vercel 的成员对核心实现很关键。我读到"React 团队会议仍然和往常一样"，但我不会惊讶于这种分裂方式会有一些额外的复杂性。
尽管如此，我确实认为"Vercel 接管了 React"是错误的，更像是"React 核心的一部分迁移到 Vercel 并说服 Vercel 与 React 的愿景保持一致"。我也没有看到"Vercel"正在推动 React 设计的证据，或者对框架和 RSC 的强调是为了让 Vercel 赚钱的特定意图。
担忧2：React 只与 Next 配合工作
我在网上看到多个评论，人们说，无论是认真的还是疑惑的，"React 现在只与 Next 配合工作"。
这很容易被反驳。即使只是查看"开始新的 React 项目"页面也显示了其他不是 Next 的框架，以及有些臭名昭著的"我可以在没有框架的情况下使用 React 吗？"部分。
显然这是对 React 如何工作的完全误解。
但是，它也说明了围绕 React、"使用框架"和 Vercel 影响的消息传递变得多么困惑。
我会加上非常相关的"我应该使用 Next 还是 React？"问题，这也经常出现。字面阅读是"Next"和"React"是不同的东西。这也明显是错误的。Next 是一个使用 React 库的框架。它是一个超集，不是竞争对手。我假设大多数人的意思是"我应该使用 Next，还是像 CRA 或 Vite 这样的客户端 SPA？"，但他们没有词汇来清楚地表达这一点。
再次，这表明这里的边界有多么困惑。
担忧2：React 逐渐放弃对客户端应用的支持
我也看到这个反复出现。关注的是"如果 React 团队在需要服务器的功能上投入这么多强调和工作，这是否意味着有一天客户端功能可能会改变或消失？"
我可以理解为什么人们有这种恐惧。这是由 React 团队在语调和强调方面的巨大转变，以及他们在服务器端功能上投入的努力量所驱动的。
然而，这也显然不可能发生。React 的客户端渲染功能永远不会消失！仅仅 Meta 本身拥有数百万行现有 React 代码的事实就表明了这一点。除此之外，React 团队在代码级向后兼容性方面一直非常出色 - 描述破坏性更改，在最终删除之前保留已弃用的功能数年，提供迁移指南和代码转换工具。
也值得注意的是，React 19 和 19.1 中的许多功能都是仅客户端的。如果有什么的话，社区高估了投入服务器端功能的努力量，而错过了投入客户端功能的努力量。
担忧3：为什么 React 推动要使用上层框架？
这让我们来到下一个争论：为什么 React 团队如此坚定地让所有 React 用户使用框架，以至于告诉人们否则他们做错了？
这是一个我有更多同情和同意的关注。我刚刚说我不认为他们说"使用框架"的目标是"让人们使用 Next 并在 Vercel 上托管"，那么推理是什么？
React 团队对框架的意见
Andrew Clark 在 2023 年 1 月的推文中相当清楚地陈述了意图：
如果你使用 React，你应该使用 React 框架。如果你现有的应用程序不使用框架，你应该逐步迁移到一个框架。如果你正在创建一个新的 React 项目，你应该从一开始就使用框架。
你选择的 React 框架应该有数据获取、路由和服务器渲染的内置解决方案。框架不会将这些视为独立的关注 - 它们提供深度集成的解决方案，易于使用并产生出色的开箱即用性能。
如果你选择放弃框架，你真正选择的是构建你自己的定制框架，一个可能比你从现成的获得的要糟糕得多的框架。即使你认为你的定制框架今天比替代方案更好，一年后还会是这样吗？
跟上最新技术需要大量时间和精力。你准备好成为框架维护者了吗？或者你的时间有更好的事情要做吗？
自那时以来改变的主要事情是框架变得非常非常好。曾经纯 React + Webpack 与一体化框架一样好或更好。在我看来，这不再是真的。
问题不是是否可能在不使用框架的情况下构建 React 应用程序。你总是有这个选择。问题是你的自制设置是否能与行业领导者竞争 - 在功能、性能、开发体验方面。标准不断提高。
类似地，在 Dan Abramov 的解释为什么他们考虑 CRA 已弃用中：
Create React App 只解决了问题的一面。它提供了良好的（在当时！）开发体验，但它没有施加足够的结构来帮助你利用 Web 的强项来获得良好的用户体验。你可以尝试自己解决这些问题，但这会涉及"弹出"并显著定制你的设置，这违背了 Create React App 的目的。每个真正高效的 React 设置都是定制的、不同的，并且无法用 Create React App 实现。
这些用户体验问题不是 Create React App 特有的。它们甚至不是 React 特有的。例如，从 Preact、Vue、Lit 和 Svelte 的 Vite 主页模板创建的应用程序都遭受所有相同的问题。这些问题是纯客户端应用程序固有的，没有静态站点生成（SSG）或服务器端渲染（SSR）。
如果你用 React 构建整个应用程序，能够使用 SSG/SSR 是重要的。Create React App 缺乏对它们的支持是显而易见的。但这不是 Create React App 落后的唯一领域。
React 本身只是一个库。它不规定如何进行路由或数据获取。Create React App 也不是。不幸的是，这意味着单独的 React 和 Create React App，如最初设计的，都无法解决这些问题。如你所见，这不是关于单个缺失功能。这些功能 - 服务器端渲染和静态生成、数据获取、打包和路由 - 是相互关联的。
时代变了。现在越来越难推荐一个你被锁定在没有这些功能的解决方案。即使你不会立即使用所有这些功能，当你需要它们时，它们应该可用。你不应该必须迁移到不同的模板并重构所有代码来利用它们。类似地，并非所有数据获取或代码拆分都需要基于路由。但这是一个应该对大多数 React 应用程序可用的良好默认值。
我也与 React 团队进行了对话，他们直接告诉我，他们听到了很多关于 React 应用程序加载时间糟糕和整体性能差的外部抱怨。所以，框架强调是对此的直接回应，目标是让更多应用程序默认具有体面的性能。
基于此，我们可以总结 React 团队的立场为：
- 框架具有设计为协同工作的数据获取、路由和服务器渲染的内置方法
- 这些都是开箱即用提供的，所以你不必花时间挑选和选择可能无法很好地协同工作的片段
- 框架由于构建设置和更好的数据获取模式而默认导致更好的性能
- 此外，React Server Components 需要集成到框架中才能正常工作
- 这些关注对于 React 团队如何感觉 React 今天应该被使用是至关重要的
换句话说，这是意识形态立场、"这将为你节省时间和精力"的信念，以及"大多数 React 应用程序遵循相似模式并需要相似解决方案"的信念的结合。
框架、SSR 和 SPA
另外，注意对"服务器渲染"的特定提及。总的来说，React 团队和生态系统的其他关键成员（如 Remix / React Router 的 Ryan Florence 和 Michael Jackson）都非常强调需要进行服务器渲染以避免客户端数据获取的"瀑布"（如 <List> 获取一组项目，渲染其子组件，<ListItem> 在挂载后进行自己的获取等）。像 Next 和 Remix 这样的框架专门设计为开箱即用地支持服务器渲染。
围绕"更快的初始页面加载"、"客户端上更少的 JS"和"避免瀑布"的 SSR 理由都有合理的意义。我也同意客户端 SPA 在很多可能不应该使用的地方被使用了（与 Redux 真的一样），并且即使你现在不需要所有功能，从框架开始也是有意义的，这样当你决定需要这些功能时可以利用它们。
我会注意到 Next 和 Remix 确实有"SPA / 导出"模式，只是输出静态 JS/HTML 资产，所以可以使用它们创建纯客户端应用程序，而不需要 Node 服务器进程。然而，这些不是默认值，我假设大多数社区甚至不知道这是一个选择。
框架推动缺乏细致入微
考虑到所有这些：我理解为什么 React 团队决定推荐框架作为默认值。我认为这是一个合理的意见，以及改善平均 React 应用程序的有效意图。
但我也觉得"推荐" 已经变成了一个过于宽泛的处方，没有充分认识到 React 在整个生态系统中实际使用的各种方式。
有很多使用全栈 React 框架的好理由，但也有很多不使用的理由：
- 框架添加了许多额外的功能和特性，但这也是需要学习的额外复杂性，使它们不太适合只是试图掌握如何使用 React 的初学者
- 增加的复杂性也可能是一个陷阱，导致困惑，比如意外地在服务器组件中使用 Context 或 hooks（这会抛出错误）
- 许多公司可能没有运行 JS 后端，甚至可能有反对这样做的规则和限制
- 具有服务器功能的框架确实需要特定的托管来运行，而纯 SPA 可以在任何提供静态 HTML 和 JS 的地方轻松托管（包括 Github Pages 和 Amazon S3）
- 虽然需要挑选和选择你的库经常是 React 用户的挫折源，但它确实能够定制项目以满足你的特定需求。有意见的框架消除了做出大多数这些决定的需要，但也可能限制你以后定制行为的能力
- 对"服务器渲染"的强调明显帮助某些类型的应用程序，但不是全部 - 有很多只需要在客户端生活的应用程序
文档推荐很重要
React 团队说"文档是针对初学者的"，所以他们想保持推荐工具和选项的列表相当简单以避免困惑。这是一个非常合理的立场。
他们也说"任何有经验足以知道使用 Vite 的人无论如何都不需要在文档中看到它列出"（转述）。这在技术上是正确的。
然而，不仅仅是初学者阅读文档，文档推荐的内容确实作为官方批准的印章产生影响。这是 React 团队历史上避免推荐特定库或技术的很大一部分原因。
如果我们回到框架/构建工具使用统计数据，今天 Vite React 和 CRA 使用量超过了 Next，很明显 SPA 使用仍然至少是 React 生态系统的一半。文档推荐应该反映这种使用情况。
对生态系统的忽视
当新的 React 文档出现时，对非框架选项的唯一提及是一个标记为"我可以在没有框架的情况下使用 React 吗？"的可展开详细信息部分，其中有几段说"是的，但我们认为这不是一个好主意"。
在该部分的末尾埋藏着这个声明：
如果你仍然不相信，或者你的应用程序有这些框架无法很好服务的不寻常约束，并且你想要滚动自己的定制设置，我们无法阻止你 - 去做吧！从 npm 获取 react 和 react-dom，使用像 Vite 或 Parcel 这样的打包器设置你的定制构建过程，并根据需要添加其他工具用于路由、静态生成或服务器端渲染等。
所以，新的设置页面不仅没有列出 Create React App，而且最接近的等效工具（Vite）甚至没有在页面的外部部分中作为有意义的选项列出。相反，它被埋在这个可展开解释的底部作为仅仅的提及。
我也会说"不寻常约束"这个短语在这里非常糟糕。SPA 从一开始就是 React 社区的标准架构。CRA 和 Vite 被普遍使用。构建 SPA 怎么突然成为"不寻常约束"？从架构到业务原因到学习简单性，有很多想要 SPA 的原因。这些不是"不寻常的" - 这些都是常见用例。
除此之外...注意短语"我们无法阻止你"。这个短语对许多人来说很突出，作为糟糕的措辞，给人以对社区忽视的印象，以及 React 团队一夜之间将 SPA 降级为不受支持方法的指示。
作为这个例子，这里是 2023 年中期关于文档中"框架"强调的辩论中的一个引用：
在某些方面，React 正在经历其 AngularJS 时刻。团队正在利用这个不稳定和不确定的时间来寻找替代品。我们当然是。
React 很棒。令社区担忧的是强烈的服务器和框架对齐语调变化。使它成为今天的服务器中性方面突然感觉二等。（SPA 路由器和加载器是一团糟且服务不足！）
这不是关于 React 或 Vite。这是关于生态系统。意识到 React 不会像"新方式"那样强烈鼓励传统的"非框架"是痛苦的。"没有框架的 React"部分被藏在文档中并且令人沮丧。
作为一个非 Node 后端公司，我们看到这些文档作为我们不再与 React 的主要方向保持一致的标志。框架认可是一个足够大的变化，导致团队重新评估整个技术栈。React 很棒，但它的影响力在架构上有限制。React 朝这个方向发展并没有"错"。但我们不能假装非框架 React 使用现在是二等关注。多久直到它不再是一个可行的选择？这令人不安。所以，我们寻找更安全的选择。你会建议一个非节点后端公司做什么？
[x.com/vyrotek/sta...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fvyrotek%2Fstatus%2F1649097699696992256 "https://x.com/vyrotek/status/1649097699696992256")
修正推荐文档
当 React 团队最终在 2025 年初宣布 CRA 已弃用时（在我帮助推动他们修复它并使该弃用正式化之后），初始文档更新包括了一个新的"构建你自己的框架"页面。概念是选择你自己的路由器和数据获取方法等同于拼凑一个不如"真正"框架好的定制框架。
我理解这里的心理模型，但这也相当忽视了生态系统构建应用程序的方式，以及人们选择自己选项的能力。
例如，Vite 创建者 Evan You 发布了他的观点：
感觉 React 团队对 Vite（以及一般的构建工具）的犹豫是它如何与他们的 React 愿景（即 RSC 作为推荐范式）保持一致，以及他们与所述工具有多少影响/连接来确保集成按照他们设计的方式工作并能够适应设计迭代... 如果这不是 React 团队在想的，我道歉，但这是我的诚实猜测，因为我和许多 React 用户一样困惑，为什么 Vite 需要这么长时间才能被更好地承认为推荐工具。
我最终提交了一个草案 PR 来改革设置页面以改善语气，在推荐项目设置工具时添加细致入微，并提供关于选择方法的一些架构指导。该 PR 被关闭了，但 React 团队确实挑选了一些想法和措辞到新的 PR 中。
最终，他们得到了一个"从头开始构建 React 应用程序"设置页面，这是相当合理的。它承认 SPA 和选择你自己的工具作为有效方法，列出 Vite / Parcel / RSPack 作为建议的构建工具，指向一些路由器和数据获取库，并为试图设置项目的用户提供一些实际有用的指导。
不幸的是，我们花了多年时间才到达那一点 :( 如果 React 团队在新文档发布后不久就应用了一些社区推荐的措辞更改，很多困惑和焦虑本来可以避免的。
担忧4：Server Component 文档和解释
围绕 React Server Components 的一个大痛点和困惑源是官方文档和信息分散且遗憾地缺乏。
React 团队最初在 2020 年 12 月用解释视频宣布了 RSC，接着是一个冗长而详细的 RFC 文档解释 RFC。这些确实在解释背景和主要动机方面做得不错。
然而，RSC 的开发过程，结合由框架实施设计选择的事实，意味着实际的 React 文档从未有意义地记录 RSC。
Next 13.0 花了将近 2 年时间以新 App Router 的形式推出第一个 RSC 的官方测试版，又过了 6 个月直到 Next 13.4 正式宣布 App Router 为"稳定"并准备用于生产，在 2023 年 5 月。Vercel 和 Next 有一个相当大的开发者关系团队，到 Next 13.4 发布时，他们已经对 Next 文档进行了相当大的重写，以涵盖当时新的 App Router，作为"测试版"文档可用。这包括一些谈论使用 RSC 的文档页面，在"数据获取"类别下，以及后来的详细博客文章，如理解 React Server Components。这些是优秀的资源，对架构和概念有非常有帮助的解释。
然而，尽管 RSC 功能是 React 本身的一部分，React 文档没有关于 RSC 的任何信息。不是"什么是 RSC"，不是"我如何使用 RSC"，绝对不是"我如何将我的库与 RSC 集成"。Vercel 的团队在记录他们的实际产品和与 React 的一些重叠方面做得很好，但人们为什么在实际的 React 文档本身中没有关于 RSC 的信息或解释是极其困惑的（从时间线上看，刚刚在几个月前正式推出）。
来自个别 React 团队成员在社交媒体上有很多讨论，回应问题，支持 RSC 作为概念，并试图充实 RSC 的销售宣传。但截至今天，RSC 上唯一的官方核心文档页面是 API 参考：服务器组件。诚实地说，这个页面令人困惑且不是特别有帮助。它绝对不是内容方面的"API 参考"，内容没有任何真正的上下文介绍 RSC 或解释何时以及如何使用它们 - 它是一个随机主题的大杂烩。
有许多优秀的外部博客文章解释 RSC 的各个方面：
- Dan Abramov 写了许多解释 RSC 心理模型和它们解决的问题的精彩文章
- Vercel 发布了一篇很棒的"理解 React Server Components"介绍博客文章
- Daniel Saewitz 写了Server Components 给你选择性解释它们如何是你工具箱的补充
这就是应该在 React 核心文档中的信息类型 - RSC 概念的解释以及为什么你可能想要使用它们，独立于任何特定框架如何实施 RSC。
与此相关：社区得出了"RSC 是 React 的未来"的想法，以及"React 团队希望我们到处都使用 RSC"。实际上，我看到 React 团队成员在社交媒体上明确说"RSC 是可选的，我们只是希望人们正确理解它们"。考虑到这种困惑，似乎在文档中具体说明这一点很重要。
就个人而言，我希望看到一整个关于 RSC 的部分添加到 React 核心文档中，包括页面如：
- "RSC 介绍"
- 心智模型
- 用例/何时选择 RSC
- 技术数据流/架构
- 采用/迁移
- FAQ
- 框架实施者指南
拥有这些文档页面不会让所有问题消失。很多人首先甚至不阅读文档 :) 但是正式涵盖这些主题会使其可见，它会作为一个资源，可以用来在这些问题在社交媒体上出现时回答它们。
从社区担忧中得出的启示
我不认为 React 团队的工作是花费所有时间在互联网上消除用户的担忧。很多人会有意见，其中许多会是不同的或错误的。
也就是说，令人震惊的是有一个强烈一致的主题"所有这些对框架和服务器的强调都被强加给我们以赚取 Vercel 的钱"。这是错误的，但有足够的间接证据让人们相信这一点，React 团队的行动和声明在某种程度上强化了这种信念，而不是反驳它。不幸的是，在这一点上，它似乎是一个永久嵌入社区中的模因，我不认为我们会让它消失。
用户担心或假设 React 在未来可能如何改变或停止工作的潜在问题也真正令人担忧，特别是当这些担忧明显错误且容易反驳时。你可以继续完全按照你一直使用 React 的方式使用，所有 RSC / 服务器功能都是完全附加的和可选的。
互联网就是这样，即使在实际的 React 博客上明确反驳这些声明的博客文章也不会改变很多人的想法。但感觉像是也许其中一些最坏的情况本来可以通过来自 React 组织的更好的开发者关系工作避免 - 花更多时间阅读关注，承认它们存在并理解它们来自哪里，并试图澄清和回答它们。
我确实觉得对"框架"的推动是真正善意的，但也过于宽泛，最终忽视了生态系统中使用模式的多样性。是的，编写文档并提供提供细致入微的推荐很难，试图保持简单以针对初学者并推动生态系统朝更好方向发展是可以理解的...但成为维护者的一部分是认识和支持你的工具被社区使用的各种方式。
我们最终确实得到了一套合理的 React 项目设置文档，这些文档对自己设置项目有有用的说明，并承认这是一种有效方法。不幸的是，我们花了数年时间才到达那一点，React 团队基本上忽略了社区关于如何改善文档该部分的非常响亮的反馈。文档仍然真正受益于更多关于如何为你的应用程序选择适当工具和架构的建议。
类似地，缺乏关于 RSC 概念和权衡的官方核心文档信息助长了困惑。我强烈感觉涵盖这些主题将极大地改善人们对 RSC 的理解和由此产生的话语。
最后的想法
这希望回答了很多关于 React 如何以及为什么以它的方式发展，React 开发过程的影响是什么，React 团队的主要目标，以及 React 使用模式今天的状况的问题。
我也希望我能够消除一些关于 React 团队动机和朝特定方向推进原因的困惑和担忧。如果人们不同意技术方向，或决定他们不需要 React Server Components 或迁移到更大的框架，这是可以的。但 React 团队的意图在这里是有效和真诚的。
维护广泛使用的库并满足社区中需求和使用模式的多样性真的很难。我确实认为 React 团队总体上做得很好。不幸的是，沟通不良的地方和文档问题是社区中很多挫折和焦虑的重要贡献因素。
展望未来，我希望我们能找到改善沟通的方法，甚至可能让更多社区参与改善文档。