5 月份，微软的 Edge 浏览器团队推出了 WebUI 2.0，旨在通过采用原生 Web 组件取代 React 组件来提升浏览器的响应速度。其核心策略是通过“标记优先的架构”来减少对 JavaScript 的依赖，这意味着客户端需要处理的代码量将减少，从而为用户带来更加流畅的体验。
为了了解 WebUI 2.0 项目的进展情况——包括它的灵感来源和最终目标——我采访了微软 Edge 团队负责人 Andrew Ritz。
首先，我们先快速解释一下 Web 组件的概念。WebComponents.org 社区网站将其定义为“一套 Web 平台 API，使你能够自定义封装可复用的 HTML 标签，用于 Web 应用。”Ritz 向他的团队这样解释这一 Web 开发范式：“每当你打算开发一个新的控件，并且需要写 JavaScript 时，请先停下来去问问有经验的工程师，看看是否可以通过使用 HTML 和 CSS 来解决问题。”
Ritz 说，他的团队的目标是在今年年底前将 Edge 浏览器中现有的约 50% 基于 React 的 Web UI 转成 Web 组件。
那么，发起这个项目的原因是什么——他们为什么决定逐步放弃 React？Ritz 解释说，这始于他的团队收到的工单——“帮助改进 Chromium 项目，包括外部和内部的请求。”
“……我们采用了 React 框架，并且可能以一种最糟糕的方式使用 React。”——微软 Edge 团队负责人 Andrew Ritz
一个具体的例子是 Excel Web 应用，它采用了 Canvas 元素。因此，他们面临的一个关键问题是：“我们该如何提升 Canvas 的性能？”HTML 中的元素允许通过脚本动态绘制图形，而这通常是通过 JavaScript 来实现的。
为了帮助团队处理这类需求，Ritz 希望采取一种更具“主观能动性”的策略，同时又能解决 Web 应用性能低下的问题。
“因此，我们着手调研公司内部所有采用了 Web 技术的地方——也就是所有的内部 Web UI，发现它们的运行速度确实令人难以接受地慢。”
为什么慢？因为 React。
“我们意识到它们的性能表现相当糟糕，尤其是在低端设备上——这主要是因为我们采用了 React 框架，并且我们可能以一种最糟糕的方式使用 React。”
在微软内部，随着时间的推移，越来越多的团队开始采用 React 来构建他们的用户界面，导致 React 的使用逐渐累积，最终形成了一个“所有人都依赖的巨大捆绑包”。Ritz 指出，这是 Web 应用之间依赖关系混乱的体现。
“这给用户带来了糟糕的体验，尤其是在低端的机器上，”Ritz 说。“我们发现，一些本应即点即用的本地应用启动时间竟然需要几秒钟，这确实令人震惊。”
Ritz 说，Edge 浏览器中大约有 50 到 100 个 Web UI 组件，“每一个都像是一个独立的 Web 小应用。”在 Web UI 2.0 项目启动之前，大约三分之二的 Edge Web UI 是基于 React 构建的。有趣的是，Edge 团队最初使用 React 是为了使 Edge 与 Chrome 有所区别。
“在将浏览器移植到 Chromium 内核的过程中，为了与 Chrome 有所区别，团队认为需要添加独特的用户界面元素——因此在移植过程中重度使用了 React。”
因此，从某种意义上说，当前的 Web UI 2.0 项目实际上是在对 Edge 最初开发工作中采用 React 的部分进行回溯。
Ritz 的团队负责其中一个 React Web UI 组件：“浏览器扩展”。在 Edge 浏览器中，用户可以通过点击工具栏上的心形图标来激活这个功能。它会打开一个侧边栏，这个侧边栏成了实验场，可用于测试用 Web 组件替换 React 组件后，能够为 UI 带来怎样的性能提升。
