React 是否已过时？微软工程师万字警示引发的思考

一、React 的辉煌与争议

React 曾是前端开发界的明星框架，凭借高效的组件化开发方式赢得开发者青睐。然而，如今却备受争议，微软工程师 Alex Russell 更是直言 React 已过时，不应再用于新程序。

React 在前端开发领域曾经辉煌一时。它以其独特的组件化开发模式，迅速成为众多开发者的首选。这种模式使得代码的可维护性大大提高，不同的组件可以独立开发、测试和复用，极大地提高了开发效率。同时，React 引入的虚拟 DOM 技术，通过在内存中模拟 DOM 树的变化，减少了对实际 DOM 的操作，从而提高了页面的渲染性能。

然而，随着时间的推移，React 也暴露出了一些问题。一方面，它的性能在一些情况下并不理想。与 Vue、Svelte、Solid、Inferno 等工具相比，React 的性能称不上顶级水准。例如，在处理大量数据更新时，React 可能会出现性能瓶颈，导致页面卡顿。另一方面，React 的学习曲线也相对较陡。对于新手开发者来说，JSX 的语法可能会让人感到困惑，而且 React 中有一些独特的约束和毛病，需要开发者花费更多的时间去适应和理解。

此外，React 的包大小也是一个问题。React 的软件包相对臃肿，这不仅会增加项目的加载时间，还可能占用更多的客户端资源。而且，随着现代浏览器的安全升级，域之间的缓存共享受到限制，这使得 React 的包大小问题更加突出。虽然有 Preact 等替代方案，但 Preact 与 React 并非无缝对接，且其包大小与其他前端框架相比也没有太大优势。

在可扩展性方面，虽然 React 对应的企业应用规模较大，但其他主流前端框架，如 Vue、Svelte、Angular 和 Ember 等，也都拥有类似的大规模执行能力。它们的网站主页上也不乏一个个声名显赫的重量级客户徽标。因此，React 在可扩展性方面并没有特别突出的优势。

React 背后的社区规模虽然很大，但这也带来了一些负面影响。对于 “无倾向性” 框架而言，大社区可能会导致意见分歧较大，技术选型困难。而且，在解决问题时，开发者可能会面临大量的信息和不同的解决方案，这增加了决策的难度。

综上所述，React 在性能、学习曲线、包大小、可扩展性和社区等方面都存在一些问题，这使得它在当前的前端开发环境中备受争议。微软工程师 Alex Russell 的观点也反映了一部分开发者对 React 的担忧和不满。在新的项目中，开发者是否还应该选择 React，确实值得我们重新审视。

二、微软工程师的警示

1. React 的问题

React 在许多开发者眼中逐渐失去光辉，被视为过时技术。

随着时间的推移，React 曾经的辉煌不再，许多开发者开始质疑其在现代前端开发中的地位。React 虽然在过去以高效的组件化开发方式赢得了广泛赞誉，但如今却面临着诸多问题，逐渐失去了往日的光彩。

框架主义带来更多复杂性和性能问题，如代码冗余、性能不佳等。

基于 React 的技术栈往往会通过 NPM 包的合并，引入大量冗余的库和代码。像 core-js、lodash、underscore 等库，以及为已不存在的浏览器提供的 polyfill、用户空间的 ECC 库、moment.js 等类似的复杂库，不仅增加了文件的体积，还可能带来不必要的性能负担。例如，2024 年的 React 开发者在构建聊天机器人时，可能会被迫包含那些 2010 年代的遗留库，甚至还要加上笨重的 MathML 或 TeX 格式化库来显示公式，而这种需求往往只在极少数会话中才会出现。

过度依赖框架和组件化思维，与现代设计和构建技术不符。

React 和艺术作品一样，并没有展示当代的设计或构建技术。它们并非为了满足当前的需求或性能标准而构建，而是基于过去的过时方法，并且在那个时代这些方法曾经是最先进的、最昂贵的。React 本应简化开发流程，但如今因为过度依赖框架和组件化思维而备受争议。

2. 客户端复杂性最小化原则

服务器端代码成本可计算，性能和可用性由组织控制；客户端代码则受多种因素影响，开发人员难以控制。

在服务器上运行的代码完全计算出成本。服务器端系统的性能和可用性由提供服务的组织控制，延迟性则可以由开发人员和运维工程师主动管理。相比之下，运行在客户端的代码则是在 “魔鬼的计算机” 上运行。用户所体验到的延迟、客户端资源，甚至可用的 API，都不在开发人员的控制范围之内。

减少代码量是出奇有效的策略，优先使用 HTML 和 CSS 而非 JavaScript。

一个出奇有效的策略是减少代码量。实际上，这意味着开发者可以优先使用 HTML 和 CSS 而不是 JavaScript，因为 HTML 和 CSS 更加简洁，并且在压缩时能有效减小文件大小，同时也能优雅地在不同条件下降级工作。声明式编程的方式能够让开发者通过发送较少的字节来实现更多的功能性界面（UI）。这些优化不仅能提高网站的稳定性（韧性），还能降低开发和维护成本，而这种效果随着网站使用时间的增长会成倍放大。

React 技术栈与减少代码量策略相反，包含大量冗余库和代码，增加文件体积和性能负担。

基于 React、Angular 和其他一些遗留的、面向桌面的 JavaScript 框架的技术栈，通常采取的做法与减少代码量的策略相反。这些生态系统口头上承诺要防止不必要的客户端代码过多，但实际上，它们往往会通过 NPM 包的合并，导致代码中包含了大量冗余的库和代码。这些冗余的代码和库不仅增加了文件的体积，还可能带来不必要的性能负担。

三、Edge 弃用 React 的影响

1. 性能大幅提升

Edge 浏览器放弃 React，采用 Web Components，性能大幅提升，响应速度加快。

微软 Edge 浏览器通过减少对 React 的依赖，转而采用 Web Components 技术，实现了性能的大幅提升。对于 Edge 用户来说，速度提升了 42%，而对于那些没有 SSD 或者内存小于 8GB 的设备用户来说，速度提升更是高达 76%。这一改变使得浏览器的基本功能界面响应速度更快，用户体验更加流畅。

减少对 JavaScript 的依赖，构建以 HTML 为先的全新架构，提高 UI 响应性能。

Web Components 技术以 HTML 为先，减少了对 JavaScript 的依赖。通过减少用 JavaScript 代码渲染的界面部分，网页加载速度更快。这种全新架构提高了 UI 的响应性能，为用户带来更好的使用体验。

2. 拥抱 Web Components

Web Components 具有可重用性、独立性、跨浏览器兼容性等优势。

Web Components 具有诸多优势，如可重用性，就像搭积木一样，可以轻松地构建网页界面，而且这些 “积木” 还可以反复使用。它还具有独立性，不同的组件可以独立开发、测试和复用。此外，Web Components 具有跨浏览器兼容性，在不同的浏览器中都能良好运行。

微软计划将 WebUI 2.0 的组件开源，让更多开发者受益。

微软在构建 WebUI 2.0 时，采用了 Web Components 技术。并且，微软计划将 WebUI 2.0 的组件开源，这将让更多的开发者受益。开发者可以学习和借鉴微软的技术，使用开源的组件快速构建网页界面，提高开发效率。同时，这也有助于推动 Web Components 技术的发展和普及。

四、React 过时了吗？

1. 不同观点的碰撞

有人对 React 是否过时存在不同的看法。一方面，有人认为 React 已经过时，主要有以下原因：

性能问题：与 Vue、Svelte、Solid、Inferno 等工具相比，React 的性能称不上顶级水准。在处理大量数据更新时，可能会出现性能瓶颈，导致页面卡顿。
过度依赖框架：基于 React 的技术栈往往会通过 NPM 包的合并，引入大量冗余的库和代码，增加了文件的体积和性能负担。而且 React 的学习曲线相对较陡，JSX 的语法可能会让人感到困惑，还有一些独特的约束和毛病。

另一方面，也有人坚持认为 React 是 “现代” 技术框架，具有一定的价值：

广泛的应用：React 在前端开发领域曾经辉煌一时，以其独特的组件化开发模式，迅速成为众多开发者的首选。许多大型项目都在使用 React，这证明了它的可靠性和稳定性。
持续的改进：React 一直在不断发展和改进，新的版本不断推出，解决了一些性能和可用性问题。

2. React 的替代方案

随着对 React 的质疑声越来越多，一些替代方案也逐渐受到关注。

Svelte：

性能好：Svelte 使用起来非常简单，相对易于学习，在几乎任何情况下性能都更好。速度很快，基本能跟性能最强的框架相媲美。
易于学习：Svelte 的语法与 React 相似，对于已经掌握 React 的开发者来说，学习起来相对容易。
贴近 Web 平台：Svelte 尽可能贴近 Web 平台，概念不会太过偏离普通开发者的认知。
捆绑包小：Svelte 在构建期间，用不上的东西都会被剥离出去，代码则被转译成普通 JavaScript。所以 Svelte 的捆绑包只相当于 React 的几分之一。

Vue：

性能比 React 好：Vue 的性能要比 React 好得多，而且更注重 UI。
模板语言接近 HTML：Vue 使用的是更接近默认 HTML，而非 JSX 的模板语言，这使得在模板文件中编写条件与循环变得更轻松，不必借助 map 和三元组等变通方法。
生态系统规模大：Vue 背后的生态系统规模堪称业界第二，Nuxt 元框架跟 Next 类似，也一直受到良好的维护并随时添加新功能。

Solid：

以 React 为起点重新设计：Solid 本质上以 React 为起点，之后重新做了设计规划，消除了复杂性、性能问题和大量样板。
提出 Signals 概念：Solid 提出了 Signals 的概念，消除了组件渲染和生命周期方面最让人头痛的混乱和陷阱。
性能强：Solid 是运行速度最快的框架选项之一，性能要强得多。

五、结论

React 是否过时仍存在争议，但微软工程师的警示引发了我们对前端开发技术的重新审视。在选择框架时，应根据项目需求综合考虑性能、学习曲线、可扩展性等因素，选择最适合的技术方案。

一方面，React 在前端开发领域曾辉煌一时，但如今也暴露出了一些问题。其性能在某些情况下不理想，与 Vue、Svelte、Solid、Inferno 等工具相比称不上顶级水准。同时，React 的学习曲线较陡，包大小相对臃肿，可扩展性方面也没有特别突出的优势。此外，React 背后的大社区也带来了意见分歧较大、技术选型困难等负面影响。

另一方面，虽然有人认为 React 是 “现代” 技术框架，具有广泛的应用和持续的改进，但微软工程师 Alex Russell 指出 React 已过时，不应再用于新程序。他认为框架主义带来了更多复杂性和性能问题，如代码冗余、性能不佳等。而且 React 过度依赖框架和组件化思维，与现代设计和构建技术不符。

对于 React 的替代方案，Svelte、Vue 和 Solid 等框架逐渐受到关注。Svelte 使用起来简单，性能好，易于学习，贴近 Web 平台，捆绑包小。Vue 的性能比 React 好，模板语言接近 HTML，生态系统规模大。Solid 以 React 为起点重新设计，提出 Signals 概念，消除了组件渲染和生命周期方面的混乱和陷阱，性能强。