很老的问题了，2024 年我站在自己的角度谈谈看法吧。（废话警告）

不算很久之前（大概是 2020-2021 年），当我初次在大学中接触前端领域时，周围的人都说想进大厂就学 React，并且互联网上也到处都是解析 React 函数式思想的文章——当时 React Hooks 推出才一两年，仍有大量项目基于 class component，而 Hooks 带来的更“纯粹”的“函数式编程”思想，在当时显得颇为独特与深奥。

显然，这只是前端娱乐圈现状的又一个缩影，在那会儿是“Everyone’s talking about React Hooks and Functional Programming”，前两年是“Everyone’s talking about signals”，今年又是“Everyone’s talking about Drizzle ORM, shadcn/ui, Bun, etc.”. 前端是我见过最有活力的社区，每天都热衷于造个全新的 next-gen game changing library——在许多人眼中，这看上去颇有些滑稽，我却不觉得这是什么坏事，这意味着更多人在“having fun”，而不仅仅是“coding for living”，这对社区的发展总是良性的。

话说回来。当时的 React 用户大多有种隐隐的优越感，毕竟自己在用一个更灵活和更加“功能强大”的框架，且 React 被认为“需要更好的基础才能驾驭”（事实的确如此，至少相比起 Vue 2，但究竟是不是好事就没人知道了），在做同一件事上也有非常多不同的选择，无论是路由、状态管理还是其他什么（相比之下，Vue 团队则把这些常见需求所需的库都一起开发了），挑得人眼花缭乱，UI 组件库也有远多于 Vue 和 Angular 的选择。

React 用户的“高傲”一定程度上是有依据的——这很大程度上要归功于 React 自身的流行度。无论你是否接受，React 实际上已经“代表”了 UI 框架（当然，“框架”这个词到底适不适合形容 React 有待考量，但咱们现在也找不到一个更好的词来形容 React、Vue、Angular、Svelte、Solid 这些东西），并且这些年里也成为了欧美前端开发的事实标准。这种“到处都是 React”的流行度是一旦接触英文前端社区就能扑面而来感受到的事情，大概习惯在 Google 上常年拿英文搜问题的人没几个会反驳。

如果你关注那些与 UI 框架相关的新轮子，它们几乎无一例外都优先考虑支持 React（像是 Tanstack 全家桶），甚至限于某个特定的 React 元框架（如 NextAuth.js，如今它成为了 Auth.js），然后它们才考虑逐渐从一个“React 特定”的库变成适用于各个 UI 框架的通用库。这种流行度的确为 React 带来了无与伦比的“繁荣”生态——自然也带来了它们质量参差不齐的问题，庞大的数量总是带来更难控制的质量，这并不令人意外。

React 的流行大概是许多偶然因素共同造成的，如今哪个因素发挥了最主要的作用或许已经不得而知了。自然，React 的流行也造成了组件库的多样性，一个国内几乎没什么声音但在英文社区具有相当知名度的新兴组件库 shadcn/ui 就是个 React 组件库，并且大概只考虑官方支持 React，连 Preact 也不打算支持（尽管社区显然可以并且已经开发了针对不同 UI 框架如 Svelte 和 Vue 的非官方 Port）。shadcn/ui 的大体思路是它不作为一个“真正的组件库”，而是提供一个代码生成器，帮助你把组件代码复制到你的项目里，同时绑定 Tailwind CSS. 这种生成的组件提供了高度自定义性——其实不算个很新鲜的思路，但对于快速开发项目相当好用，可以认为是 Tailwind CSS 思路上的进一步扩展，在组件的灵活性和易用性上达成了一个神奇的平衡。

谈到 shadcn/ui 其实只是想举个更具体的例子说明 React 在事实上的流行导致许多新尝试与新技术都优先从 React 开始——其实一个这样的库是很适合一开始就作为通用组件库而不是作为 React-only 组件库开发的（尽管事实上存在不少适用于其他 UI 框架的 Unofficial port）。很大程度上，React 已经成为了一种“惯性”，而各种库尝试兼容其他 UI 框架以变成一个“framework-agnostic”的库在某种程度上可能变成了一种“正确”或者纯粹出于造轮子的喜好——如果一个组件库（当然也包括其他非组件库）支持同时包括 React 在内的多个 UI 框架，那你最好不要期待它在其他 UI 框架上的表现，大概率是处于缺胳膊少腿并且没几个人提交 BUG 的状态——支持得好是惊喜，支持不好是常态。

这种“React 惯性”真的是正确的吗？前端圈向来很擅长“反思”什么已有的流行的东西并推出一个又一个 next-gen lib 成为“game changer”，React 这边也不例外。

一个批评在于 React Hooks 需要手动传入 deps 带来的样板代码问题——React 社区甚至开发了 ESLint 插件来提示你在 deps 中把所有依赖手动加上，可既然 ESLint 都能告诉我要在 deps 中写什么东西，为什么 React 自己不能把依赖给我自动加上？这个问题在过去似乎非常 Trivial——因为 useState 或其他同类东西拿到的是一个值，在运行时代码中直接跟踪一个值以实现响应性是不可能的，至少得需要个编译器才能完成这项跟踪工作。理所当然的，后来人们发觉让编译器完成这项工作不是唯一的解决方案，也可以干脆换一种写法，与其直接使用值，不如使用一个 Getter，而 Getter 自然就可以在运行时直接被跟踪以实现响应性，而不需要编译器参与，无论 Vue 的 .value 还是 Solid 直接返回 Getter 的做法都只是这种想法的一个实现，这被称为 Signals——这其实也只是新瓶装旧酒，Vue 3 一开始就是这个思路，可 Signals 这个说法要到前两年才炒起来。

React 的另一个问题在于组件的生命周期初看起来并不那么直观——在 React 中（至少 Hooks 之后），组件 (Component) 只是一个返回组件实例 (Element) 的工厂函数，函数式组件每次渲染时都会从头到尾跑一遍以得到新元素，而不是直觉上的“函数式组件是定义组件的代码，仅在创建实例时运行一次以初始化”——事实上后来 Solid 就是这么做的。这也导致了很多新手一不留神就往组件定义里塞了一些耗时操作导致性能问题，并且也导致创建高性能 React 组件需要时刻留意耗时操作并用 useMemo 之类的东西将它们惰性化，这导致了更严重的样板代码问题。

还有其他同类的像需要手动 memo 的问题，也一直以来被诟病为“React 创造的问题”。也有一些较小的点，比如传递 ref 的复杂性。有时人们会半开玩笑地说“React 先故意把框架做得很烂，然后引入一些小改进解决这些本就不该存在的问题让大家感觉 React 团队又实现了什么巨大进步”——说实话我越来越觉得真是这么回事。

抛开写法上的缺陷，再谈谈一个避不开的的问题——生态。React 显然是前端 UI 框架中生态最“繁荣”的一个，这一方面要归功于 React 自身的流行度，另一方面则要归功于 React 团队仅做核心而不参与周边生态开发的做法。这导致 React 生态中仅状态管理和路由两块就有数不清的社区实现，状态管理更是难绷到让 Redux 这么个完全不好用的库统治了许多年——直到以一种不能更简单的方式实现的 Zustand 流行起来大家才发现原来 Redux 这么难用不是因为 React 状态管理本就复杂（在很长一段时间以来这还是个具备统治力的观点），而只是因为 Redux 过度封装把事情搞得太过复杂。

自然的，也产生了许多观点为 React 辩护，以解释“为什么 React 这么烂大公司还是选择它”。我记得前几年有个说法被很多人提及——大公司需要对页面每一次渲染细粒度控制，并且宁愿投入更多人力在这种“开手动档”的事情上，而不是依赖于框架自动管理渲染时机，React 就提供了这种灵活性。这可能（值得怀疑地）部分解释了大公司们采用 React 的原因，但没有解释为什么如今数之不清的小公司仍优先选择 React.

在我的观点中这更多还是源于一种历史惯性，并且 React 还没有比其他 UI 框架“明显糟糕”到不能接受的程度，因此大多数公司没有换掉 React 想法，而这造就了 React 生态的继续繁荣——和国内公司习惯于跟着阿里用 MyBatis 比较类似，大公司用什么我就跟着用，只是因为前面的人帮我把坑趟过了，有比较齐全的周边配套代码和大厂退下来熟悉这套技术的员工，小公司没必要选择自己用国内环境里不常用的生态，也是图一个安稳。

在开头，我反复强调了 React 生态有多繁荣，似乎在吹 React，刚才又批评了 React 的一些问题，似乎把它贬得一无是处——其实我只是相对客观地评论着 React，也许带了些主观偏见，但大体应当并不偏激。那么 React 难道没有优点吗？显然也不是的。

不可否认的是，React 的确为前端带来了一些“新”的东西。在 Hooks 之前，“函数式编程”这个如今被说烂了的概念在大多数前端人眼里还只是个“可望而不可及”的东西，它从象牙塔中带来了一些似乎有用的东西，但若你想从一些“先行者”那里了解些更多的东西，则会被他们张口就是 Monad 的热情劝退——或许他们也不是想故意把别人劝退，只是已经习惯了这些外人看来可能颇为晦涩的概念。React 以一种在现在许多人看来颇有些半吊子的方式，将函数式编程的一些基本概念以颇有些炒作的形式带到了大众的眼中（得益于 React 自身的流行度，不管官方是不是有意炒作，React 发布任何一个新功能后总是会看起来像是炒作了一番）——许多人第一次认识到，原来在代码里几乎全用 const 和只用 Immutable 对象也可以很好地开发应用，区分副作用也可以很好地控制难以预测事件的发生。这些对“函数式编程”的普及或许太过浅显到以至于让许多人觉得“不达本质”而不屑一顾，但至少起到了很不错的引导作用，让许多人第一次知道还存在另一种写代码的方式。

React 这个每次渲染都跑一遍组件定义函数的做法也不是只有坏处。这其实很大程度上让 Hooks 的封装变得简单和透明了，除了 useState 那几个有限的内置 Hooks，自己封装 Hooks 其实没太多额外的黑魔法在里头，就只是简单的把一段代码替换成一个函数以方便复用，仅此而已。这也带来了其他许多事情的简单性，如子组件只需通过一个没有任何 Magic 的 .children 就可以直接传递，而 Solid 和 Vue 等都需要额外的手段（children helper function 或 <slot>）来高效处理子组件的传递问题。React 的 props 也不存在解构丢失响应性的问题——每次渲染时组件都会重跑一遍，会有新的不同的值传进来。某种意义上，React 的这个看似别扭的做法维持了一种统一的简单性和一致性，使框架没有在背后做太多难以预测的“魔法”——这又回到了那个老生常谈的问题，框架在背后做了太多工作到底是简化了用户的心智负担还是实质上反而加重了心智负担？框架要做到什么程度才能达到这种心智负担的平衡？这就是个没有答案的见仁见智的问题了。

然后要谈到 React 的另一个特点——JSX，或者说特定于 React 的 JSX. React 在 JSX 上的做法基本就是直接将其一比一与运行时代码替换，编译器在其中只做了一些简单的工作——相比之下，Vue、Svelte 等基于模板方案的 UI 框架则大量依赖编译器实现较复杂的转换工作，尤其是在处理响应性上，而 Solid 尽管使用了 JSX，其编译器仍旧在背后做了不少工作，而不是像 React JSX 基本上只做代码替换。React 这种处理 JSX 的方案其实天生使其和 TS 有很不错的相性，并且带来了 React 最被广泛认同的特性——灵活性。

如果你用过一些 React 组件库，会发现其中不少地方允许你直接传入一个 React Element（也就是一个 JSX 元素）作为参数，例如典型的传递 <XxxIcon />. 在模板语法下这则是个不那么容易的事情，因此我们通常在 Vue 中传递组件 (Component) 而非元素 (Element)。对于 React 中的 <Button icon={<XxxIcon />}> 在 Vue 中的同类写法常常是 <Button :icon=\