头图

CRA 被 React 官方 “抛弃” 了?别慌,真相在这儿!

前言

大家好,我是倔强青铜三。是一名热情的软件工程师,我热衷于分享和传播IT技术,致力于通过我的知识和技能推动技术交流与创新,欢迎关注我,微信公众号:倔强青铜三。欢迎点赞、收藏、关注,一键三连!!!

宝子们,今天要跟大家聊聊一个在 React 圈子里引起不小波澜的事情 ——Create React App(CRA)被 React 官方 “抛弃” 了!是不是很震惊?别着急,咱下面就来好好唠唠这到底是咋回事。

一、CRA 的 “发家史”

想当年,CRA 可是 React 开发者们的 “心头好” 啊。2016 年 7 月它一出道,就凭借着简单易用的特点,迅速在开发者社区里火了起来。对于那些刚接触 React 的小白来说,CRA 简直就是个 “神器”,一键生成项目,啥都不用管,直接就能开干,省去了好多配置环境的麻烦事儿。而且它内置了一整套的开发工具和流程,从代码编译到热更新,都给安排得明明白白的,开发者们只需要专注于写代码,其他的都不用操心,这可太香了!

而且,CRA 还有着很好的社区支持。官方文档详细且全面,遇到问题在社区里一搜,往往就能找到解决方案。在很多企业项目和开源项目中,CRA 也被广泛使用,成为了 React 项目搭建的标准方式之一。

二、CRA 的核心缺点大揭秘

可再好的东西,用的时间长了,也难免会暴露出一些问题,CRA 也不例外。

(一)配置不够灵活

CRA 对构建过程进行了高度的抽象,把 Webpack、Babel 这些核心工具的配置都封装了起来。一开始大家觉得这样挺好,省事儿。但后来随着项目越来越复杂,开发者们发现,有些时候需要对这些工具进行一些个性化的配置,可 CRA 的封装让这变得特别困难。比如说,你想优化一下 Webpack 的打包策略,减少打包时间或者减小打包后的文件体积,但在 CRA 里,你很难做到这一点。要是你想自定义配置,那就得执行 “eject” 命令,把自己从 CRA 的 “保护伞” 下脱离出来,自己去管理配置和依赖关系。可这样一来,后续的更新和维护就变得超级复杂,稍不注意就可能出问题。

(二)依赖管理是个 “老大难”

CRA 自带了一堆预定义的依赖,像 Webpack、Babel、ESLint 等等。虽然这在一开始省去了开发者手动配置这些工具的麻烦,但也带来了一个问题,那就是依赖关系变得特别复杂。这些依赖的版本更新速度都很快,而 CRA 自己的更新速度却跟不上。这就导致在开发过程中,经常会出现依赖冲突的情况。比如说,你更新了一个依赖的版本,结果发现和其他依赖不兼容了,整个项目都可能因此崩掉。而且,开发者还得自己操心这些依赖的更新和维护,稍不注意,项目就可能因为依赖问题变得一团糟。

(三)构建速度不够快

随着项目代码量的增加,CRA 的构建速度问题就越来越明显了。CRA 基于 webpack 构建,webpack 在处理大量模块时,会花费较长的时间进行解析和打包。在开发过程中,每次保存代码后的热更新时间也会逐渐变长,这对于开发者的开发体验来说,是非常不友好的。想象一下,你正在专注地写代码,改了一点内容,然后等待页面更新,结果等了好几秒甚至十几秒,这多影响心情和效率啊。
再看看 Vite,它采用了全新的构建理念。在开发阶段,Vite 利用浏览器的 ES Module 特性,直接加载源码,不需要像 webpack 那样进行复杂的打包操作,所以热更新速度极快,几乎是瞬间完成。在生产构建时,Vite 也进行了很多优化,构建速度相比 CRA 有了很大的提升。

(四)构建资源太大

CRA 的默认配置是优先考虑开发速度,这在开发阶段确实挺方便的,可到了生产环境,问题就来了。因为它没有对打包后的资源进行特别的优化,所以生成的包体积往往比较大,这就导致应用的初始加载时间变长。在如今这个互联网时代,用户可没那么多耐心等着页面慢慢加载,要是加载时间太长,用户很可能就直接走人了。而且,对于一些对性能要求比较高的项目来说,CRA 的这个缺点就更明显了。

(五)不支持 SSR 和 SSG

随着 Web 应用的发展,服务端渲染(SSR)和静态站点生成(SSG)变得越来越重要了。SSR 可以提高页面的加载速度,改善用户体验,还能提升搜索引擎优化(SEO)的效果;SSG 则可以让页面在构建时就生成静态文件,进一步提高加载速度和性能。可 CRA 从一开始就没怎么考虑过对 SSR 和 SSG 的支持,虽然理论上可以通过一些复杂的配置来实现,但那实在是太麻烦了,对于大多数开发者来说,根本就不太现实。

三、为啥 CRA 无法改进以至于被 “抛弃”?

那 React 官方为啥不干脆对 CRA 进行改进,让它继续为开发者们服务呢?主要有这么几个原因。

(一)社区发展太快

React 社区现在发展得实在是太快了,各种新的工具和框架层出不穷。像 Vite、Next.js、Remix 这些,都比 CRA 更先进,更符合现代 Web 开发的需求。React 官方一看,与其花大力气去改进 CRA,还不如直接推荐这些更优秀的工具,让开发者们用起来更顺手,也能更好地跟上技术发展的潮流。

(二)维护成本太高

CRA 的代码已经比较复杂了,要对它进行全面的改进,那得投入大量的人力和时间。而且,改进之后还得保证和现有的项目兼容,这难度可不是一般的大。React 官方也犯不着为了一个逐渐被淘汰的工具去浪费这么多资源,还不如把精力放在更有前景的项目上。

四、替代品大比拼

那 CRA 被 “抛弃” 了,咱们 React 开发者以后该用啥呢?别担心,React 官方给咱们推荐了好几个替代品,下面咱就来好好比比它们的优缺点。

(一)Vite

Vite 可以说是 CRA 的一个绝佳替代品。它底层使用的是 esbuild,构建速度比 CRA 快了好几倍,开发服务器的启动速度也是秒开,这可太适合那些追求开发效率的开发者了。而且,Vite 的配置非常灵活,你可以轻松地自定义 Webpack 和 Babel 的配置,再也不用像在 CRA 里那样被封装得死死的了。比如说,你想优化 Webpack 的打包策略,或者调整 Babel 的转译规则,Vite 都能让你轻松搞定。

Vite 还支持热模块替换(HMR),这意味着在开发过程中,你可以实时看到代码更改的效果,而不需要每次都刷新整个页面,这可大大提高了开发效率。而且,Vite 提供了原生 ES 模块支持,无需使用 Babel 或其他转换器,这进一步简化了开发流程。

最重要的是,Vite 与 React 的结合非常紧密,它不会在项目层面强制使用任何特定的 React 功能、库或配置,从而赋予了开发者更多的灵活性和自主权。开发者可以根据项目需求选择适合自己的 React 辅助库,如路由、数据获取、状态管理及测试工具。

(二)Next.js

Next.js 是另一个非常受欢迎的 React 框架,特别适合需要服务端渲染(SSR)或静态站点生成(SSG)的项目。Next.js 内置了对 SSR 和 SSG 的支持,这使得它在性能和 SEO 方面表现得非常出色。比如说,你可以轻松地为每个页面生成静态文件,这样用户访问时就能更快地加载页面,提升用户体验。

Next.js 的配置也非常简单,它提供了一套默认的配置,你可以直接使用,也可以根据需要进行自定义。而且,Next.js 还提供了很多实用的功能,比如自动代码分割、动态导入、路由管理等,这些都能帮助你更高效地开发项目。

(三)Remix

Remix 是一个相对较新的 React 框架,它的设计理念是“全栈开发”,这意味着你可以用它来同时开发前端和后端。Remix 提供了一套完整的开发体验,从路由到数据获取,再到错误处理,都做得非常细致。比如说,Remix 的路由系统非常强大,你可以轻松地定义各种复杂的路由规则,而且它还支持服务器端的数据获取,这使得开发体验非常流畅。

Remix 的另一个特点是它对开发者体验非常友好。它提供了一个非常直观的开发环境,你可以实时看到代码更改的效果,而且它还提供了详细的错误提示,帮助你快速定位和解决问题。

(四)CodeSandbox 和 StackBlitz

CodeSandbox 和 StackBlitz 是两个云开发平台,它们提供即时的编码环境,让你可以快速开始开发,而不需要在本地设置开发环境。CodeSandbox 支持 Docker,可以满足各种复杂的开发需求,还集成了 VS Code,让你有熟悉的编码体验。StackBlitz 则提供了流畅的 GitHub 集成,预配置的环境,以及快速的部署选项,非常适合快速原型开发和在线协作。

五、总结

虽然 CRA 被 React 官方 “抛弃” 了,但这并不意味着 React 开发者们就无路可走了。相反,现在有更多优秀的工具和框架可以选择,比如 Vite、Next.js、Remix、CodeSandbox 和 StackBlitz。这些工具各有各的优点,适合不同的开发需求和场景。如果你是初学者,Vite 可能是一个不错的选择,因为它简单易用,配置灵活。如果你需要 SSR 或 SSG,Next.js 是一个非常强大的工具。如果你想要一个全栈开发的体验,Remix 值得一试。如果你需要快速原型开发或在线协作,CodeSandbox 和 StackBlitz 都是非常好的选择。

总之,虽然 CRA 被 “抛弃” 了,但这并不影响我们继续使用 React 进行开发。相反,我们可以利用这些新的工具和框架,提升开发效率,开发出更优秀的项目。所以,大家不要慌,继续加油!

最后感谢阅读!欢迎关注我,微信公众号倔强青铜三。欢迎点赞收藏关注,一键三连!!!

倔强青铜三
36 声望0 粉丝