社区精选｜React 为什么不将 Vite 作为默认推荐？

今天小编为大家带来的是社区作者 卡颂 的文章，让我们一起来学习 React。

---

大家好，我卡颂。

在 React 文档中，对于构建新的 React 应用，首推的方式是 CRA（create-react-app）。

CRA 推出于 2016 年，彼时还没有成体系的 React 脚手架工具供大家使用，再加上这是官方工具，一经推出就受到了欢迎。截止当前，CRA 仓库已经收获快 10wstar。

但是，随着时间的推移，出现了很多优秀的替代品，比如 parcel、vite 提供的 React 模版。

而 CRA 本身的进步速度却在放缓，其上一次提交要追溯到去年 9 月 8 日：

此外，CRA 对一些流行工具的支持也不是很好，比如在 TailwindCSS 文档中就不推荐使用 CRA：

近日，油管 10w 粉丝的前端网红 Theo 就在 React 文档仓库发起了一个 PR ，号召 React 文档不要再默认推荐 CRA，而是应该将 Vite 作为构建应用的首选。

看这围观群众的数量就知道大家对这种敏感问题有多关心了：

那么，React 团队是如何看待这个问题的呢？他们会将 Vite 作为构建应用的首选项么？

本文来聊聊 Dan（React 核心成员）对这一问题的看法。

CRA 的定位

既然众矢之的是 CRA，那么首先我们需要明白 CRA 在 React 体系下的定位，再来看看 Vite 能否在这个定位下取代前者。

CRA 诞生的时期（2016 年），是 SPA（单页应用）最火热的时期。在当时，他很好的解决了两个痛点：

0 配置初始化项目

这点不用过多介绍，执行如下命令后就能生成一个 CSR（客户端渲染）的 React 项目：

npx create-react-app 项目名

集成工具链

CRA 将当时的一些工程化最佳实践都封装在 react-scripts 包下，并抹平这些工具不兼容的地方。

开发者既享受了开箱即用的最佳实践，又不用担心某些工具升级后对项目造成的影响（CRA 会处理）。

后来的很多优秀脚手架工具（比如 Vite、Parcel），也都沿用了这种开箱即用的理念。

除了以上两点，随着 CRA 的走红，React 团队还将他作为新特性的快速分发渠道，比如：

• Fast Refresh（针对 React 的热更新，不会丢失组件状态）
• Hooks 推出后的一系列 lint 规则

依托 CRA 庞大的装机量与使用量，这些集成到 CRA 的特性可以快速部署到开发者的项目中，达到快速提高普及率的目的。

试想，如果没有 CRA 的推动，Hooks 的 lint 规则很难在开发者中有这么高普及率，Hooks 的理念也就不会这么快席卷整个前端框架领域。

从以上三点来看，Vite 完全可以成为比 CRA 性能更优的替代品。

但是，React 团队的考量不仅如此。

脚手架工具的不足

虽然 CRA 开箱即用，但他提供的能力并不全面，比如他并不提供：

• 状态管理方案
• 路由方案
• 数据请求方案

为什么不提供呢？因为在 CRA 发展的时期，这些方案还未形成最佳实践。

随着时间发展，开发者逐渐摸索出解决这些问题的最佳实践。比如请求瀑布问题，考虑如下组件：

function App() {
  const [data, update] = useState(null);
  useEffect(() => {
    fetch('http://...').then(res => update(res.json()))
  }, [])
  
  return <Child data={data}/>
}

只有当 App 组件渲染后才能开始请求数据，这个请求时机是比较滞后的，如果 Child 依赖 data 来请求自己的数据，那么由于 App 请求的滞后导致 Child 的请求也滞后了，这就是请求瀑布问题。

这个问题常见的解决方法是 —— 将请求数据的逻辑收敛到路由方案中。

再比如，随着业务不断迭代，业务代码体积越来越大，常见的优化手段是懒加载组件。

但是，手动执行懒加载常常会产生意料之外的问题。比如，页面中有个图表组件<Chart/>，如果开发者懒加载了这个组件，但是该组件在 on mount 时请求数据，这又会陷入请求瀑布问题。

要彻底解决这个问题，需要配合 3 类技术方案：

• 数据请求方案（解决数据流向问题）
• 路由方案（解决数据请求时机问题）
• 打包方案（解决懒加载的实现问题）

类似的问题还有很多，比如 CSR 首屏渲染速度慢的问题（需要通过 SSR 解决）。

可见，CRA 仅仅提供了 CSR 环境下一个开箱即用的模版，但是随着项目变得越来越复杂，一些业务细节问题 CRA 是没有提供开箱即用的解决方案的。

从这个角度看，即使切换到 Vite 还是会面临同样的问题。

新时代的框架

随着各种常见问题的最佳实践被探索出来，逐渐诞生了一些以 React 为基础，集成各种业务问题最佳实践的框架，比如 Next.js、Remix。

其中，Remix 就是以 React-Router（路由解决方案）为基础，逐渐发展出来的囊括路由、数据请求、渲染为一体的全栈框架。

那么，能否将 CRA 迭代为类似 Next.js、Remix 这样的全栈框架，一劳永逸解决 CRA 对各种最佳实践的缺失呢？

React 团队认为，这样做需要极高的开发成本，而且随着时代发展，总会出现更多 CRA 不支持的最佳实践（就像他当前面临的问题一样），那么 CRA 终有一天会被再度淘汰。

所以，这个方案不可取。

既然这个方案不可取，那么用 Vite 取代 CRA 的方案也不可取。因为单纯使用 Vite 并没有解决最佳实践的缺失，必须在此基础上实现那些最佳实践（比如路由、数据请求...），那又回到了开发一个全栈框架。

最终，React 团队更倾向如下解决方案：将 CRA 作为一个脚手架工具，启动后会根据用户的不同场景需要（比如是 SSR 还是 CSR）推荐不同的框架，再将 CRA 作为不使用框架情况下的兜底方案。

并且，在实现上，可能将兜底方案中的 webpack 切换为 Vite。

总结

从 React 团队的思考可以发现，React 始终将自己定位为一个状态驱动 UI 的库。

随着时代的发展，单独使用这个库已经不能满足日常开发需要，基于底层使用 React + 实现各种最佳实践模式的框架会越来越流行。

最近，Next.js 达到了 10wstar 成就，成为 Github 中 star 排名第 14 的仓库，间接印证了这种趋势。

回到开篇的问题：React 为什么不将 Vite 作为默认推荐？

如果是用 Vite 取代 webpack 作为 CRA 的打包工具，未来可能会。但是，这不是最首要的问题。

如何协助上层的框架更好的服务开发者，才是 React 团队首要考虑的问题。

React 不死，他只会逐渐移居幕后。 

---

点击左下角阅读原文，到 SegmentFault 思否社区 和文章作者展开更多互动和交流，“公众号后台“回复“ 入群 ”即可加入我们的技术交流群，收获更多的技术文章~

- END -