React 老矣,我建议大家用用别的框架

如今,纵观各类招聘网站上的前端职位,大家往往都会看到一个熟悉的字眼:React。虽然企业雇主也经常会列出其他一些类似的前端框架选项,但 React 的地位几乎是雷打不动。

但面对这样的现实,请原谅我始终无法理解。除了流行,React 到底还有什么优势?

首先我想澄清一点,我对 React 没有任何敌意。我知道它挺好,而且如果需要开发庞大复杂的前端项目,我其实也并不抗拒使用 React。

React 的出现,为其他框架当前及未来的功能规划奠定了基础。Vue 3及其组合 API 明显是受到 React hooks 的启发。Svelte 中的很多约定就来自 React。至于我最喜爱的 Vue 框架 Nuxt,它的大部分设计思路都来自 React 的元框架 Next。总而言之,整个基于组件的前端设计和开发模型,特别是目前的整个生态系统,都离不开 React 的鼎力支持。

但就个人观点,我还是觉得 React 像是那种开创了流派的祖师级老电影、音乐专辑或者电子游戏。它的伟大体现在那个时间点上的开创性,但时至今日自身的绝对价值其实已经很有限了。

好吧,这话可能说得有点狠。毕竟一提到开创性的老电影,大家首先想到的就是《公民凯恩》,React 跟其他框架间的差距肯定不像《公民凯恩》相较于后来的经典佳作那么大。我的观点很简单:

React 已经老了,只是经常用它的朋友们还没有意识到它老到了什么程度、引发了哪些问题。

如果只用 React,那可能会觉得这框架不错啊,而且一直在努力改进。确实,React 在很多方面都是越来越好,但这并不能改变它的发展速度和功能上限已经长期跟不上同类方案的事实。

总之一句话,React 表现得不错,只是不像其他框架那么好。

工作中的最佳选项

假设大家身为某家科技初创公司的 CTO,或者是打算开发某网络软件新产品的个人创业者。

我们面前摆着新项目的蓝图,可以随意选择自己喜爱的技术进行构建。没有约束,也不设产品生命周期限制,那么你会选择哪一种前端框架?

(有些朋友可能会抬杠说,不用前端框架也行。但对于任何成规模、比较复杂的项目来说,不用前端框架肯定不是什么好主意。)

要做出选择,先要考虑以下几项条件:

性能学习曲线绑定包大小可扩展性社区与支持资金支持开发者体验人才供应

而有没有一种可能,从这么多角度来论证,其实 React 并不是什么好选择。

下面咱们逐一探讨。

性能

大家可以通过多种不同指标来衡量性能。但无论关注哪个具体方面,React 都称不上顶级水准。Vue、Svelte、Solid、Inferno 等工具的性能总体上都要好于 React。根据实际需求,大家甚至可以通过 Alpine 或者 Petite Vue 等让性能更上一层楼(虽然我觉得这两种跟其他框架并不算同一类方案)。

React 的性能不佳应该已经是个共识,所以这里无需继续赘述。所以我认为,如果大家希望让新项目拥有强大的性能表现,那 React 就可以直接被排除在外。

学习曲线

假设你对前端框架一无所知,那 React 也绝对不是最好学、最容易上手的选项。

JSX的实质,就是笨拙地把 HTML 硬塞进 JavaScript 函数返回。你以为这就够糟了?不,更糟的是你在 React 里不用 JSX。

除了 JSX,React 本身也有不少独特的约束和毛病(比如提供两种完全不同的语法,但二者完全无法互操作)。

在 React 中,其他前端框架能够帮我们轻松打理的小事,往往还是需要手动干预或者借助大量样板文件(甚至二者兼有)。

几乎每种前端框架都把用户设想成普通人,但 React 不同,它最早是专为 Facebook 的工程师们打造的。虽然经过多年发展,它已经成为一种比较通行的市场化产品,但即使到现在,这样的出身仍然给 React 留下了深深的烙印。我们还是可以看到其中留下的早期决策与优化痕迹。

至于其他问题,那可太多了。万恶之源 useEffect,不能在 JSX 中使用某些标准 HTML 属性(因为 JSX 无法区分 React prop 和 HTML 属性),记忆化,只能靠短路运算符模仿出来的虚假条件,以及要求开发者自己防止无限循环等等……其实连这里的循环都是假的,必须靠数组方法才能实现。不说了,说不完。

绑定包大小

这一点跟速度类似,但我觉得还是有必要区分开来。哪怕下载包大一点,但实际使用时性能更好,那也没啥问题。但 React 可不是这样。

React 软件包相当臃肿,这个大家都知道了,我也不多废话。

我想强调的是,有些人觉得 React 大多数情况下会从缓存中加载,所以绑定包大小无所谓。这种认知最早是假的,后来现代浏览器让它成了真,可最近的安全升级开始阻止域之间的缓存共享,所以又成了假的。

另外,Preact 虽然表现不错,但还没办法跟 React 无缝对接。而且 Preact 的包大小跟其他前端框架比也没有太大的优势。

可扩展性

虽然 React 对应的企业应用规模肯定是最大的,但我觉得吧,数量跟质量并不是一回事。

从 Vue 到Svelte,再到Angular和 Ember,每一款主流前端框架都拥有类似的大规模执行能力。他们的网站主页上,也不乏一个个声名显赫的重量级客户徽标。

所以 React 没什么特别的,只是案例最多罢了。

如果大家有很强的从众心理,那我也无话可说。但客户多真的不代表 React 就一定更优秀,它只是出现在了充满机会的时代。

社区与支持

没错,React 背后的社区规模最大,但这还是不足以支撑 React 就最好的结论。

大社区也有负面影响,特别是对 React 这类“无倾向性”框架而言。社区过大可能对应着太多可供选择的套餐,太多相互冲突、彼此对抗的观点,逼着用户在其中站队,然后承受随之而来的一切。

不仅如此,社区太大,甚至不一定能让产品越变越好。

最初,更多的参与者确实能不断带来好的功能特性。但这里存在一个收益递减点(即不断上升的沟通成本,逐渐开始减慢、而非加快项目发展速度)。除此之外,社区的参与人数和社区质量间也没有必然关联。

当然,我理解想要去爆满的餐厅吃饭那种心情,这似乎能给人一种安全感。毕竟哪怕不好吃,还有那么多人跟我一起上当呢,这波不亏。但哪怕人再多,都无法改变“不好吃”这个基本事实。这跟愿意来吃的人是多是少,真的没什么关系。所以我们用不着非往最火爆的餐厅去挤,挑一家适合自己的、安静享受一顿美食,不就足够了?

资金支持

有些人总担心自己使用的框架,会在某一天突然消失,由此失去支持和维护。对他们来说,出自 Facebook 系的 React 天然值得信任。但问题是,其他前端项目的资金支持有那么不堪吗?

Angular 的背后可是谷歌,Vue 则是历史上最成功、资金也最充裕的开源项目之一。Vercel 目前至少雇用了两位 Svelte 维护者(其中包括 Svelte 的缔造者)全职负责项目管理。至于 Solid,已经拥有超过 100 名贡献者和至少六家主要企业赞助商。

所以,资金支持对各大主流前端框架来说都不是问题,React 在这方面同样不算占优。

开发者体验

React 确实是应用范围最广的前端框架,知名度也是一时无两。但在今年的 JS 现状调查报告中,React 的开发者满意度已经不及 Solid 和 Svelte。至于受关注度,React 落后于 Svelte、Solid 和 Vue,甚至已经跌破 50%。

多年以来,React 的用户满意度和关注度一直在稳步下降,采用率也停滞不前。

当然,这类调查问卷只能作为参考,在问题的表述方式上稍做手脚就能得出不同的答案。但其他同类调查也发现了类似的趋势。在 Stack Overflow 的调查中,React 的受欢迎度远低于 Svelte,仅略微高于 Vue。

有趣的是,Scott Tolinski 最近提到,他的一位开发者放弃了薪酬丰厚的 React 职位,宁愿拿一半的工资也要加入 Tolinski 领导的 SvelteKit 项目。

当然了,并不能用这个例子证明开发者连钱都愿意放弃,就为了离 React 远一点。但至少能够看出,React 带给开发者的使用感受实在称不上好。

人才供应

这方面,React 确实堪称一骑绝尘。如果想让新人快速理解之前的开发资产,那 React 的优势可太明显了。

但是吧,我觉得单这一点不足以让 React 脱颖而出。

鉴于选择 React 之后,应用程序的绑定包本身就更大、速度更慢而且复杂性更高,用这么多弊端来换取所谓项目接管期间的一点点便利,无疑是在牺牲长远收益寻求眼下省事。翻译翻译,这不就是典型的技术债务吗?

现在省下的几个礼拜,未来可能需要几个月甚至几年来偿还。所以虽然 React 在这方面占优,但大家最好还是认真核算一下,没办法无脑选它。

另外,了解 React 的朋友想上手其他前端框架,应该不是什么难事。没错,不同框架间总有一些细微差别和小怪癖,但其中遵循的设计理念还是大体相同的。任何熟悉 React 的优秀开发者,也都能在其他框架上获得同样的工作成效。

我承认,商业世界从来没有好坏,只有权衡取舍。开发速度很重要,前面提到的每一点也都很重要。所以,您的实际情况可能证明,哪怕是 React 速度更慢、绑定包更大、复杂度更高,它也仍然值得选择。是的,我都理解。

但大家做出的选择,最终也将成为与竞争对手在市场上搏杀时的一张牌。选得好就是好牌,反之亦然。如果大多数对手也选择 React,那大家就是烂牌对局、菜鸡互啄。

而如果能选得更好,也许就能压制对方的牌形。

批评了半天,React 为什么还是傲视同侪?

因为很多人在做选择时,往往是比较草率的。React 之所以现在受欢迎,就是因为 React 之前受欢迎。

在真正占领市场之前,人们其实是出于其他理由去选择 React 的。也许因为它能解决开发者面对的实际问题,也许因为它比较新奇有趣,或者是其他什么原因。但可以肯定的是,当时人们选 React 绝不是看中它更好就业,或者是市场普及率最高的框架。而时过境迁,现在大家再选择它,唯一的理由就是它够老、够踏实。

企业选它,因为人才市场上懂 React 的群体很大;求职者学它,是因为人才市场上企业想要招聘 React 开发者。这是个自我强化的循环,一个自我实现的预言。

于是 React 成了默认选项,只要没有充分的理由,更多人只会以无所谓的态度接着用。

while (reactIsPopular) {

reactIsPopular = true

}复制代码

“毕竟没人会因为用了 React 而被解雇”,这话倒也没错。React 是个安全的选择,可能不是每个人的最爱,但至少不会惹出大麻烦。它,还是能干活的。

所以只要没有强烈的业务需求,求职者和招聘方都可以接受围绕 React 建立起来的行业现状。只要能把双方对接起来,React 的作用就已经达到了。

这一切会改变吗?如何改变?

我其实一直在关注事态的变化。

但要说答案,我也没有。根据之前提到的几份调查报告,React 的采用率确实出现了停滞。也不能说不再增长,只能说 React 的增长跟不断扩大的市场本体之间保持了同步,三年来份额一直维持在 80%左右。

但终有一天,我相信这种循环会中断。但我不知道具体的导火索会是什么。

也许是个量变引发质变的过程。回想起来,很多趋势来得看似突然,但实际上一直在随时间推移而积蓄力量。也许其他前端框架更好地证明了自己,并逐渐削平了 React 在人才储备方面的优势,于是企业开始向其他方案敞开怀抱。

也可能会有部分企业触及 React 的性能上限,并结合业务需求转向性能更强的选项。比方说,如果公司的业务对移动端性能有着极高要求,而且必须能够在设备配置差、网络不稳定的区域内提供良好体验,那 React 差出的这部分性能就足以促成改变。

但对大多数企业来说,情况还没那么极端。大部分旧项目实在没必要做迁移,性能困扰虽然偶然出现,也绝不至于要因此推动大规模重构。所以继续用 React 完全没有问题,它在很多场景下已经完全够用了。

所以没准市场就固化在了这一刻,再没有谁能真正挑战 React 的统治地位。等到它真正宣布退位的时候,也许我们已经彻底抛弃了前端框架,那时候主流浏览器、特别是 JS 已经扩展到了不需要它们的地步。这就是所谓后框架时代。

还有一种可能,React 在事实上已经过时了,只是在宏观统计上还体现不出来。目前人才市场上的招聘需求,反映的是企业在很久之前做出的框架选择。正如核酸测试体现的是几天、甚至几周之前的区域内疫情状况一样,目前的招聘态势也许也存在滞后。

我不知道未来的前端会是什么样子,应该没人能做出准确的预言。但可以肯定的是,React 还能风光上好一阵子。

如果大家正在学习前端开发,想用这个为自己找份工作或提升职业水平,那 React 是个不错的选项、也是非常安全的方向。

但我也希望能有越来越多的开发者积极探索其他选项,也希望企业能给他们更多尝试的机会。近年来,前端开发领域的惊喜都来自 Vue 和 Svelte。以我个人的感受和经验,React 只是能干活,并没让工作变得更有趣。

而且越来越多的开发者也意识到了这个问题,开始尝试接触其他框架、体验它们的不同特性,也反过来意识到 React 是有多么老迈和迟钝。即使单纯从推动未来前端开发者多样性的角度出发,我也真心建议大家用用别的框架方案。

原文链接:

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-of-react

原文地址:https://www.toutiao.com/article/7143416339464553000/

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


react 中的高阶组件主要是对于 hooks 之前的类组件来说的,如果组件之中有复用的代码,需要重新创建一个父类,父类中存储公共代码,返回子类,同时把公用属性...
我们上一节了解了组件的更新机制,但是只是停留在表层上,例如我们的 setState 函数式同步执行的,我们的事件处理直接绑定在了 dom 元素上,这些都跟 re...
我们上一节了解了 react 的虚拟 dom 的格式,如何把虚拟 dom 转为真实 dom 进行挂载。其实函数是组件和类组件也是在这个基础上包裹了一层,一个是调...
react 本身提供了克隆组件的方法,但是平时开发中可能很少使用,可能是不了解。我公司的项目就没有使用,但是在很多三方库中都有使用。本小节我们来学习下如果使用该...
mobx 是一个简单可扩展的状态管理库,中文官网链接。小编在接触 react 就一直使用 mobx 库,上手简单不复杂。
我们在平常的开发中不可避免的会有很多列表渲染逻辑,在 pc 端可以使用分页进行渲染数限制,在移动端可以使用下拉加载更多。但是对于大量的列表渲染,特别像有实时数据...
本小节开始前,我们先答复下一个同学的问题。上一小节发布后,有小伙伴后台来信问到:‘小编你只讲了类组件中怎么使用 ref,那在函数式组件中怎么使用呢?’。确实我们...
上一小节我们了解了固定高度的滚动列表实现,因为是固定高度所以容器总高度和每个元素的 size、offset 很容易得到,这种场景也适合我们常见的大部分场景,例如...
上一小节我们处理了 setState 的批量更新机制,但是我们有两个遗漏点,一个是源码中的 setState 可以传入函数,同时 setState 可以传入第二...
我们知道 react 进行页面渲染或者刷新的时候,会从根节点到子节点全部执行一遍,即使子组件中没有状态的改变,也会执行。这就造成了性能不必要的浪费。之前我们了解...
在平时工作中的某些场景下,你可能想在整个组件树中传递数据,但却不想手动地通过 props 属性在每一层传递属性,contextAPI 应用而生。
楼主最近入职新单位了,恰好新单位使用的技术栈是 react,因为之前一直进行的是 vue2/vue3 和小程序开发,对于这些技术栈实现机制也有一些了解,最少面试...
我们上一节了了解了函数式组件和类组件的处理方式,本质就是处理基于 babel 处理后的 type 类型,最后还是要处理虚拟 dom。本小节我们学习下组件的更新机...
前面几节我们学习了解了 react 的渲染机制和生命周期,本节我们正式进入基本面试必考的核心地带 -- diff 算法,了解如何优化和复用 dom 操作的,还有...
我们在之前已经学习过 react 生命周期,但是在 16 版本中 will 类的生命周期进行了废除,虽然依然可以用,但是需要加上 UNSAFE 开头,表示是不安...
上一小节我们学习了 react 中类组件的优化方式,对于 hooks 为主流的函数式编程,react 也提供了优化方式 memo 方法,本小节我们来了解下它的用...
开源不易,感谢你的支持,❤ star me if you like concent ^_^
hel-micro,模块联邦sdk化,免构建、热更新、工具链无关的微模块方案 ,欢迎关注与了解
本文主题围绕concent的setup和react的五把钩子来展开,既然提到了setup就离不开composition api这个关键词,准确的说setup是由...
ReactsetState的执行是异步还是同步官方文档是这么说的setState()doesnotalwaysimmediatelyupdatethecomponent.Itmaybatchordefertheupdateuntillater.Thismakesreadingthis.staterightaftercallingsetState()apotentialpitfall.Instead,usecom