今天小编为大家带来的是社区作者 卡颂 的文章，让我们一起来学习 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 在 React 体系下的定位，再来看看 Vite 能否在这个定位下取代前者。CRA 诞生的时期（2016 年），是 SPA（单页应用）最火热的时期。在当时，他很好的解决了两个痛点：这点不用过多介绍，执行如下命令后就能生成一个 CSR（客户端渲染）的 React 项目：CRA 将当时的一些工程化最佳实践都封装在 react-scripts 包下，并抹平这些工具不兼容的地方。开发者既享受了开箱即用的最佳实践，又不用担心某些工具升级后对项目造成的影响（CRA 会处理）。后来的很多优秀脚手架工具（比如 Vite、Parcel），也都沿用了这种开箱即用的理念。除了以上两点，随着 CRA 的走红，React 团队还将他作为新特性的快速分发渠道，比如：- Fast Refresh（针对 React 的热更新，不会丢失组件状态）
依托 CRA 庞大的装机量与使用量，这些集成到 CRA 的特性可以快速部署到开发者的项目中，达到快速提高普及率的目的。试想，如果没有 CRA 的推动，Hooks 的 lint 规则很难在开发者中有这么高普及率，Hooks 的理念也就不会这么快席卷整个前端框架领域。从以上三点来看，Vite 完全可以成为比 CRA 性能更优的替代品。虽然 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 时请求数据，这又会陷入请求瀑布问题。类似的问题还有很多，比如 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 团队首要考虑的问题。
点击左下角阅读原文，到 SegmentFault 思否社区 和文章作者展开更多互动和交流，“公众号后台“回复“ 入群 ”即可加入我们的技术交流群，收获更多的技术文章~
关注公众号：拾黑（shiheibook）了解更多
赞助链接：
关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/
关注网络尖刀微信公众号
微信扫码关注公众号