转自：InfoQ
作者丨 Richard MacManus
译者丨明知山
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 来解决问题。”
Edge 为什么要放弃 React？
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 说。“我们发现，一些本应即点即用的本地应用启动时间竟然需要几秒钟，这确实令人震惊。”
Edge Web UI
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 带来怎样的性能提升。
Web 组件没有未来？
最近，社交媒体上再次掀起了关于 Web 组件与框架组件优劣的激烈讨论。SolidJS 框架作者 Ryan Carniato 发表了一篇颇具挑衅性的博文，标题为“Web 组件不是未来。”他的核心观点是，像 SolidJS 这样的框架在某些特定场景下能够完成 Web 组件无法完成的任务，并且实现起来更为简便。他认为 Web 组件只是一种“彻头彻尾的妥协”。
作为回应，Shoelace 作者 Cory LaViska 提出了反驳，他认为 Web 组件在提供稳定性和跨框架互操作性方面具有明显优势。
LaViska 指出：“开发者对框架的不断变化感到疲惫。他们厌倦了上个月写的代码这个月就过时了。他们想要稳定，希望今天构建的东西明天还能用。”
LaViska 还指出，Web 组件没有做到框架组件所能做到的所有功能是“因为它们是对互操作性元素的一种更为底层的实现”。
这场在社交媒体上永无休止的争论——虽然现在已经从日常信息流中淡出，但可以肯定的是，一两个月后又会卷土重来。不管怎样，我问了 Andrew Ritz 关于他的团队如何适应 Web 组件以及它们是否真的像一些批评者所说的那样难以部署。
“我们的策略其实很直接，就是尽可能利用浏览器内置的功能，”他回答说。“也就是说，尽可能使用浏览器中原生的元素，这样做并没有想象中那么困难。”
“……努力让 Web 组件表现良好绝对是一个问题。”——Ritz
Ritz 提到，Edge 开发者得益于微软自家的 Fluent UI 框架，这个框架包含了 React 组件和 Web 组件（以及其他多种类型的组件，比如专为 iOS 和 Android 设计的组件）。但他也承认，即便是使用公司统一的框架来实现 Web 组件也并非易事。
“在某些情况下，内置控件需要大量的定制工作——当中有许多我们可能并不需要的 polyfill，或者诸如此类的东西——因此，努力让它们表现良好确实是一个问题。”
关于 Ritz 所说的围绕 Web 组件的“开发敏捷”（其他人可能称之为“开发者体验”），他表示，“我们实际上看到了一些相当不错的改进。”例如，专注于 HTML 和 CSS 意味着开发人员和设计师能够更好地保持一致——因为他们使用的是相同的语言。
“开发人员可以专注于使用 HTML 和 CSS，基本上消除了整个翻译层（可能有人需要将线框图转换成其他形式，这对开发者生产力来说是一个巨大的障碍）。”
关于 Web 组件的广泛采用
可以说，对于微软的浏览器团队来说，采用 Web 组件比一般的 Web 开发团队要来得更为容易。除了能够利用微软自家的 Fluent UI 框架，Edge 团队还在开发一个只需适配单一浏览器的产品：他们自己的浏览器。相比之下，其他 Web 开发团队需要确保他们的产品能够在多种不同的浏览器上良好运行，包括 Chrome、Edge、Safari、Firefox 等。
“我们可能更容易一些，因为我们只依赖 Edge 浏览器处理我们的本地事务，”Ritz 解释道。“而对于其他 Web 开发者来说——他们可能还得支持 Safari，或者其他……这无疑增加了复杂性。”
“如果我们能让微软内部一些更大的非 Web 组件网站迁移过来，那将是一个很好的证明。”——Ritz
尽管如此，微软计划将部分 WebUI 2.0 包以及一套“Web 平台模式”开源。然而，Ritz 指出，许多外部开发者可能并不打算完全模仿微软的做法——例如，许多开发者可能倾向于选择一个不同于 Fluent UI 的样式框架。但至少，Ritz 的团队能够为其他人提供“学习模式”作为参考。
一个可能的中间步骤是尝试说服微软的其他 Web 产品转向使用 Web 组件。
“我不知道微软的其他团队会怎么做，”Ritz 说。“但 Edge 团队正努力建立一个公共库……但我认为如果能让微软内部一些更大的非 Web 组件网站迁移过来，那将是一个很好的证明。”
但他也补充说，他们对与外部合作伙伴合作持开放态度，希望一起引领一个超越 React 框架的 Web 开发新时代。
“如果我们能找到一个在这个领域有共同愿景并愿意合作的合作伙伴——毫无疑问，我们会非常乐意。”
原文链接：
https://thenewstack.io/how-microsoft-edge-is-replacing-react-with-web-components/
