《前端暴走团》,喜欢请抱走~大家好,我是团长林语冰。
前端社区里有一个女粉问我,为什么都在说 React 比 Vue 难?
事实上,我不知道这个说法算是客观事实呢,还是"思想钢印"。
但是我第一反应就是盲猜一手,"React 比 Vue 难"这个说法可能源于后端攻城狮的主观评价,因为传统后端编程语言经典的面向对象编程思维和函数式 React Hook 八字不合。

但是除此之外,还有一大坨前端程序猿也或多或少同意"React 比 Vue 难"的说法,这又是为什么呢?
我确信背后一定有更深层次的原因,为此我翻云覆雨、彻夜难眠,索性重温了几部纪录片,考古了几份历史材料,终于睡着了。
前 React 时代
噫吁嚱,危乎高哉!框架之难,难于上青天!
在"前 React 时代",前后端分离并非主流,前端圈举目望去大抵皆为全栈攻城狮。当时的前端框架市场中,AngularJS 1 人气最高、独领风骚,然后 React 说我不服。
彼时还没有 TS,微软为了开发 VS Code 的雏形,TS 团队被迫孵化了 TS,这也是微软第一个开源项目,可谓出道即巅峰。在那之前,开源这块又臭又硬的金子还没有发光,行业普遍认为开源缺乏商业价值,免费开源软件容易被山寨和盗版非法竞争,最终导致"劣币驱逐良币"。

TS 横空出世之后,AngularJS 2 + TS 在前端生态的自然选择中牵手成功,互利共生。由于大部分前端人只对动态类型的 JS 一心一意,所以部分 AngularJS 的拥趸被 TS 的"类型体操"劝退,分流到了 React 社区。
React 之所以找到了"流量密码",一来是有大厂背书和资本注入,二来是 AngularJS 2 想要在应用层而不只是框架内部拥抱静态类型,以满足谷歌大型项目开发的刚需,但部分前端程序猿学不会"类型体操",只能被迫切换赛道,和 AngularJS 2 "和平分手"。
关于 AngularJS 2 还有一个冷笑话,AngularJS 2 最终版发布,是的没错,这可能也是 AngularJS 的最终版,因为它和 Angular 1 一龙一猪。
起初,React 只是 Facebook 内部一个非开源项目。虽然 React 源码内部也使用了另一套静态类型方案 Flow,但 React 应用层的用法并没有像 AngularJS 那样强制用户拥抱静态类型,所以 React 受到 JS 爱好者的青睐,趁机蚕食了部分前端框架市场。
彼时"Vue 之父"尤大还在谷歌实验室当打工仔,一来觉得 AngularJS 太过前卫,二来 React 没有真正提高前端人的生活质量,当时市面上的前端框架都美中不足,没法真正解放尤大的生产力。

于是乎,凭借"用户至上"的设计哲学和"用爱发电"的开源精神,尤大决定开发了一个原本名为 Seed.js 的玩具框架。出师未捷身先死,世界上最困难的事情,除了脱单,就是取名字。尤大第一次提交代码时,发现 Seed 的名字在 npm 上已经被注册占用了,所以被迫将框架重命名为 View。
尤大不懂 Vue,直接命名为 View 又很直接,所以遇事不决谷歌翻译,最终使用了 View 的法语 ------ Vue。
他那时还太年轻,不知道这三个短小精悍的字母,早就在未来标注好了"看涨"。
那时 Vue 还在猥琐发育,所以不存在谁比谁难的说法。除了 jQuery,大部分前端框架都有点难度,AngularJS 2 + TS 的"类型体操"用了头大,React Hook + "泛函编程"用了烧脑......
至于 Vue 的难度,在于难以预测,因为 Vue 最初是由一位独立开发者凭借一己之力创造出来,既没有大厂背书,也没有团队的技术支持,更没有基金会的资本注入,所以 Vue 爱好者往往对使用 Vue 犹豫不决。
后 React 时代
截至目前为止还是暴风雨前的宁静,因为前端框架的"诸神之战"还在酝酿,尚未正式打响。比较意外的是,战争的导火索不是来自前端社区,而是来自 PHP 社区。
PHP 社区的大佬泰勒,不是泰勒·斯威夫特那个泰勒,而是"Laravel 之父"那个泰勒。大佬在勇闯 React 新手村的时候一脸懵逼。
我猜可能是因为后端编程语言普遍拥抱面向对象编程,虽然 React 早期支持类组件的写法,React 16 之后提出的 React Hook 则拥抱函数式编程,所以对于后端工程师而言,React Hook 入门比较反直觉,学习曲线比较陡峭。
换位思考,如果你是先从前端入门编程,再切换赛道进军经典后端编程语言,你会头皮发麻,比如面向对象编程和静态类型系统的违和感会特别违和。
其次,Vue SFC(单文件组件)和 React JSX 都涉嫌违背"关注点分离"的开发原则,前端社区对此先质疑、后端社区对此再质疑。
Vue 官方文档对此也补充了"免责声明":

传统前端开发中,习惯将 HTML + CSS + JS 分而治之,结构、样式和逻辑在不同的文件类型中对症下药,这被认为是一种"关注点分离"的最佳实践。
而 Vue SFC 和 React JSX 却将这三者都耦合到各自 DSL(领域驱动语言)的单一文件中中。在这个问题上,React JSX 更加反直觉,因为 JSX 的设计哲学是"万物皆可 JS",相信你已经看过这个经典的公式:UI = f(x)
。

作为一个资深的"数学笨蛋",这里我就不展开讲状态机了,因为我也不知道怎么讲。
此外,React 社区甚至提出了"CSS-in-JS"的方案,继续颠覆前端程序猿和后端攻城狮的认知,"前端三幻神"乱成一锅粥。
行文至此,作为一个前端爱好者,我可以像"诺贝尔物理学奖"获得者费曼先生一样很有把握地说,React 类似于量子力学,就算不难,恐怕也不会那么简单。
总而言之,为了防止沉没成本,PHP 大佬及时止损,像苹果放弃十年造车计划转战 AIGC 一样及时,直接切换赛道到 Vue。
彼时 Vue 的选项式 API 趋近类式风格,不像 React Hook 或 Vue 3 组合式 API 那么泛函,与后端攻城狮的面向对象思维模型不谋而合。
最后,PHP 大佬用得得心应手,直呼绝绝子,就在朋友圈给 Vue 点赞,PHP 社区因此开始关注到了 Vue。这就是 Vue 早期的主力用户,Vue 顺水推舟正式出道。后来尤大也受邀到 PHP 大会发表演讲,Vue 社区则继续在前后端双线程滚雪球。
因此,所谓"React 比 Vue 难"的说法,对于后端攻城狮而言,大约指的是,从面型对象编程切换到函数式编程,需要克服范式转变和路径依赖的阻力。对于前端程序猿而言,则是 React 在泛函编程和关注点分离的道路上,走得比 Vue 更远,入门门槛更高。
前端开发现状
抛开前端简史不谈,如今 React 之难,更多可能体现在生态系统的复杂性。
Vue 生态目前有且仅有一个状态管理插件,有且仅有一个人气爆棚的元框架;反观 React 生态,状态管理神仙打架,元框架也搞窝里斗。

举个栗子,我们初学 Vue,只需要学一个 Pinia,就能同时兼容 Vue 2 + Vue 3 的状态管理。但如果我们学习 React,就需要学习 Redux,然后慢慢就会发现 Redux 在 React 中用得头大,我们真正需要的可能是 React Redux。
为什么是可能需要呢?因为当你掌握了 React Redux,就会再次慢慢发现,使用 React Redux 好像不如使用其他 React 状态管理库那么香,包括但不限于:
- Mobx
- Recoil
- tanstack-query
- Jotai
- Zustand
- valtio
随着你在 React 世界里从"走码观花"到"下码看花",又双叒叕会慢慢发现,"Redux 之父"在辅助推广 Mobx,而不是自家的 Redux;"Zustand 之父"既是"Zustand 之父",又是"Jotai 之父",还是"valtio 之父"......
CSS 方面,除了前文提及的"CSS-in-JS"之外,还有其他方案,虽然其中某些方案一般不会和框架强耦合。

元框架方面,Next 14 的服务端操作众口嚣嚣,有人说这是在飚前后端不分离的历史倒车,有人说这是全栈攻城狮的"文艺复兴"。React 最新 RSC 范式提出了服务器组件和客户端组件,而 Vue 有且仅有组件。
诚如那个前端梗所说,前端生态每周都有一个新的轮子诞生。更多的选择不仅意味着更丰富的生态系统,也意味着更高的学习成本。
React 初学者很容易因为选择困难而决策瘫痪,直呼学不动了,所以"React 比 Vue 难"。
当我们看到"React 比 Vue 难"时,这首先是一句中文,而 Vue 因为其作者的中文比较好,所以 Vue 官方文档的中文翻译也比 React 相对优秀。更接地气的中文文档可以有效地降低开发者的学习成本。
事实上,PHP 大佬也在朋友圈提及 Vue 的英文文档更加优秀。
另一个误区是,如果你读过 React 的官方文档,就会发现,React 其实不是框架,只是一个工具库。库少做的事情,就需要转嫁成本,要求用户自己来做,比如显式传递依赖、自己实现响应式等。这也是 React 生态更加丰富的原因之一。

而 Vue 的产品定位是渐进式框架,直接安排了 Vue 全家桶开发的一条龙服务,你不需要跳出 Vue 的条条框框,而要反其道而行之,拥抱 Vue 的思维模型。
此外,React Native 也在移动端占有一席之地,涉及知识面更广,对开发者的要求自然更高。
高潮总结
综上所述,我的个人心证是,博古通今,考虑前端简史到开发现状,所谓"React 比 Vue 难"的说法,存在以下原因,仅供粉丝参考:
- 习惯面向对象的后端攻城狮不习惯 React 的泛函编程
- 习惯关注点分离的前端程序猿不习惯 React JSX 的关注点不分离
- 选择更多的 React 生态导致 React 初学者选择困难
- React 是库不是框架,转嫁成本要求用户像框架一样使用库
- 中文爱好者或"英语笨蛋"背诵 React 文档难度较高
本期话题是 ------ 你觉得 React vs Vue 谁更难,难在哪里?欢迎在本文下方自由言论,文明共享。
坚持阅读,自律打卡,每天一次,进步一点。
《前端暴走团》,喜欢请抱走!我是团长林语冰。谢谢大家的点赞,掰掰~
