您当前的位置:首页 > 电脑百科 > 程序开发 > 框架

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

时间:2022-09-15 14:21:53  来源:  作者:·InfoQ

 

如今,纵观各类招聘网站上的前端职位,大家往往都会看到一个熟悉的字眼: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



Tags:React   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
浅析五种 React 组件设计模式
作为一名 React 开发者,你可能会面临下面几个问题: 如何构建一个高复用度性的组件,使其适应不同的业务场景? 如何构建一个具有简单 API的组件,使其易于使用? 如何构建一个在 UI 和...【详细内容】
2024-01-09  Search: React  点击:(84)  评论:(0)  加入收藏
Vanilla Design,新一代 React UI 库
这几天做需求,一堆 UI 库实在是不知道选哪个,各种角色的同事争论不休;还总有新轮子冒出来,所以我来插一脚,并借此来领悟写代码的哲学:The best way to write secure and reliable...【详细内容】
2024-01-04  Search: React  点击:(90)  评论:(0)  加入收藏
如何设计更优雅的 React 组件?
在日常开发中,团队中每个人组织代码的方式不尽相同。下面我们就从代码结构的角度来看看如何组织一个更加优雅的 React 组件!1. 导入依赖项我们通常会在组件文件顶部导入组件所...【详细内容】
2023-12-21  Search: React  点击:(101)  评论:(0)  加入收藏
浅析 Preact Signals 及实现原理
介绍Preact Signals 是 Preact 团队在22年9月引入的一个特性。我们可以将它理解为一种细粒度响应式数据管理的方式,这个在很多前端框架中都会有类似的概念,例如 SolidJS、Vue3...【详细内容】
2023-12-18  Search: React  点击:(109)  评论:(0)  加入收藏
八种在 React 中实现条件渲染技术的方法
条件渲染是React中的一个强大功能,它允许开发人员根据某些条件控制组件的显示。它在创建动态和交互式用户界面方面发挥着至关重要的作用。然而,了解条件渲染在 React 中的工作...【详细内容】
2023-12-06  Search: React  点击:(123)  评论:(0)  加入收藏
怎么理解 React Server Component 和 Next.js 的关系
最近Next.js v14发布,发布会的各种梗图刷爆了国外前端社区。Next.js的诸多特性(比如Server Action、App Router),都是在RSC(React Server Component)基础上衍生出的。从名字可以看...【详细内容】
2023-11-16  Search: React  点击:(210)  评论:(0)  加入收藏
十个 React UI 组件库你不会还不知道吧?
前言 大家好我是小卢,在快速变化的前端开发世界中,React 凭借其简洁明确的设计思想和强大的性能表现独占鳌头,赢得了全球开发者的广泛青睐...【详细内容】
2023-11-02  Search: React  点击:(241)  评论:(0)  加入收藏
打造高质量Web应用程序:React 和 Vue 框架对比和实践经验总结
React 和 Vue 是两个目前非常流行的JavaScript框架,用于构建高质量的Web应用程序。它们都有自己的优点和适用场景,并且都被广泛使用。下面将对React和Vue进行对比,并总结一些实...【详细内容】
2023-10-27  Search: React  点击:(289)  评论:(0)  加入收藏
构建高性能 React Native 跨端应用—图片与内存
在浏览器构建的 web 中开发者可能不用花费太多精力关注图像上,但是在移动应用中,对于图像的关注显得非常重要。因为在 RN 应用中,无论是图片还是动图,或者是视频都是非常耗内存...【详细内容】
2023-09-04  Search: React  点击:(255)  评论:(0)  加入收藏
2023 年值得考虑的10大 React 静态站点生成器!
今天给大家带来的主题是2023 年值得考虑的10大静态站点生成器,话不多说,直接开始!前言在不断发展的 Web 开发环境中,静态站点生成器 (SSG) 已成为开发人员快速高效地创建网站的...【详细内容】
2023-08-16  Search: React  点击:(339)  评论:(0)  加入收藏
▌简易百科推荐
Qt与Flutter:在跨平台UI框架中哪个更受欢迎?
在跨平台UI框架领域,Qt和Flutter是两个备受瞩目的选择。它们各自具有独特的优势,也各自有着广泛的应用场景。本文将对Qt和Flutter进行详细的比较,以探讨在跨平台UI框架中哪个更...【详细内容】
2024-04-12  刘长伟    Tags:UI框架   点击:(1)  评论:(0)  加入收藏
Web Components实践:如何搭建一个框架无关的AI组件库
一、让人又爱又恨的Web ComponentsWeb Components是一种用于构建可重用的Web元素的技术。它允许开发者创建自定义的HTML元素,这些元素可以在不同的Web应用程序中重复使用,并且...【详细内容】
2024-04-03  京东云开发者    Tags:Web Components   点击:(8)  评论:(0)  加入收藏
Kubernetes 集群 CPU 使用率只有 13% :这下大家该知道如何省钱了
作者 | THE STACK译者 | 刘雅梦策划 | Tina根据 CAST AI 对 4000 个 Kubernetes 集群的分析,Kubernetes 集群通常只使用 13% 的 CPU 和平均 20% 的内存,这表明存在严重的过度...【详细内容】
2024-03-08  InfoQ    Tags:Kubernetes   点击:(17)  评论:(0)  加入收藏
Spring Security:保障应用安全的利器
SpringSecurity作为一个功能强大的安全框架,为Java应用程序提供了全面的安全保障,包括认证、授权、防护和集成等方面。本文将介绍SpringSecurity在这些方面的特性和优势,以及它...【详细内容】
2024-02-27  风舞凋零叶    Tags:Spring Security   点击:(54)  评论:(0)  加入收藏
五大跨平台桌面应用开发框架:Electron、Tauri、Flutter等
一、什么是跨平台桌面应用开发框架跨平台桌面应用开发框架是一种工具或框架,它允许开发者使用一种统一的代码库或语言来创建能够在多个操作系统上运行的桌面应用程序。传统上...【详细内容】
2024-02-26  贝格前端工场    Tags:框架   点击:(47)  评论:(0)  加入收藏
Spring Security权限控制框架使用指南
在常用的后台管理系统中,通常都会有访问权限控制的需求,用于限制不同人员对于接口的访问能力,如果用户不具备指定的权限,则不能访问某些接口。本文将用 waynboot-mall 项目举例...【详细内容】
2024-02-19  程序员wayn  微信公众号  Tags:Spring   点击:(39)  评论:(0)  加入收藏
开发者的Kubernetes懒人指南
你可以将本文作为开发者快速了解 Kubernetes 的指南。从基础知识到更高级的主题,如 Helm Chart,以及所有这些如何影响你作为开发者。译自Kubernetes for Lazy Developers。作...【详细内容】
2024-02-01  云云众生s  微信公众号  Tags:Kubernetes   点击:(51)  评论:(0)  加入收藏
链世界:一种简单而有效的人类行为Agent模型强化学习框架
强化学习是一种机器学习的方法,它通过让智能体(Agent)与环境交互,从而学习如何选择最优的行动来最大化累积的奖励。强化学习在许多领域都有广泛的应用,例如游戏、机器人、自动驾...【详细内容】
2024-01-30  大噬元兽  微信公众号  Tags:框架   点击:(68)  评论:(0)  加入收藏
Spring实现Kafka重试Topic,真的太香了
概述Kafka的强大功能之一是每个分区都有一个Consumer的偏移值。该偏移值是消费者将读取的下一条消息的值。可以自动或手动增加该值。如果我们由于错误而无法处理消息并想重...【详细内容】
2024-01-26  HELLO程序员  微信公众号  Tags:Spring   点击:(88)  评论:(0)  加入收藏
SpringBoot如何实现缓存预热?
缓存预热是指在 Spring Boot 项目启动时,预先将数据加载到缓存系统(如 Redis)中的一种机制。那么问题来了,在 Spring Boot 项目启动之后,在什么时候?在哪里可以将数据加载到缓存系...【详细内容】
2024-01-19   Java中文社群  微信公众号  Tags:SpringBoot   点击:(86)  评论:(0)  加入收藏
站内最新
站内热门
站内头条