讯享网

 <p class="f_center"><img src="http://dingyue.ws.126.net/2024/1027/5d8e3d8cg00slzt3b0082d200hs002sg00it002x.gif"/><br/></p><p id="34FP6L82">作者丨 Richard MacManus</p><p id="34FP6L83">译者丨明知山</p><p id="34FP6L84">策划丨Tina</p><p id="34FP6L85">5 月份，微软的 Edge 浏览器团队推出了 WebUI 2.0，旨在通过采用原生 Web 组件取代 React 组件来提升浏览器的响应速度。其核心策略是通过“标记优先的架构”来减少对 JavaScript 的依赖，这意味着客户端需要处理的代码量将减少，从而为用户带来更加流畅的体验。</p><p id="34FP6L86">为了了解 WebUI 2.0 项目的进展情况——包括它的灵感来源和最终目标——我采访了微软 Edge 团队负责人 Andrew Ritz。</p><p id="34FP6L87">首先，我们先快速解释一下 Web 组件的概念。WebComponents.org 社区网站将其定义为“一套 Web 平台 API，使你能够自定义封装可复用的 HTML 标签，用于 Web 应用。”Ritz 向他的团队这样解释这一 Web 开发范式：“每当你打算开发一个新的控件，并且需要写 JavaScript 时，请先停下来去问问有经验的工程师，看看是否可以通过使用 HTML 和 CSS 来解决问题。”</p><p id="34FP6L8A">Edge 为什么要放弃 React？</p><p id="34FP6L8D">Ritz 说，他的团队的目标是在今年年底前将 Edge 浏览器中现有的约 50% 基于 React 的 Web UI 转成 Web 组件。</p><p id="34FP6L8E">那么，发起这个项目的原因是什么——他们为什么决定逐步放弃 React？Ritz 解释说，这始于他的团队收到的工单——“帮助改进 Chromium 项目，包括外部和内部的请求。”</p><p><blockquote id="34FP6L9V">“……我们采用了 React 框架，并且可能以一种最糟糕的方式使用 React。”——微软 Edge 团队负责人 Andrew Ritz</blockquote></p><p id="34FP6L8F">一个具体的例子是 Excel Web 应用，它采用了 Canvas 元素。因此，他们面临的一个关键问题是：“我们该如何提升 Canvas 的性能？”HTML 中的元素允许通过脚本动态绘制图形，而这通常是通过 JavaScript 来实现的。</p><p id="34FP6L8G">为了帮助团队处理这类需求，Ritz 希望采取一种更具“主观能动性”的策略，同时又能解决 Web 应用性能低下的问题。</p><p id="34FP6L8H">“因此，我们着手调研公司内部所有采用了 Web 技术的地方——也就是所有的内部 Web UI，发现它们的运行速度确实令人难以接受地慢。”</p><p id="34FP6L8I">为什么慢？因为 React。</p><p id="34FP6L8J">“我们意识到它们的性能表现相当糟糕，尤其是在低端设备上——这主要是因为我们采用了 React 框架，并且我们可能以一种最糟糕的方式使用 React。”</p><p id="34FP6L8K">在微软内部，随着时间的推移，越来越多的团队开始采用 React 来构建他们的用户界面，导致 React 的使用逐渐累积，最终形成了一个“所有人都依赖的巨大捆绑包”。Ritz 指出，这是 Web 应用之间依赖关系混乱的体现。</p><p id="34FP6L8L">“这给用户带来了糟糕的体验，尤其是在低端的机器上，”Ritz 说。“我们发现，一些本应即点即用的本地应用启动时间竟然需要几秒钟，这确实令人震惊。”</p><p id="34FP6L8M">Edge Web UI</p><p id="34FP6L8N">Ritz 说，Edge 浏览器中大约有 50 到 100 个 Web UI 组件，“每一个都像是一个独立的 Web 小应用。”在 Web UI 2.0 项目启动之前，大约三分之二的 Edge Web UI 是基于 React 构建的。有趣的是，Edge 团队最初使用 React 是为了使 Edge 与 Chrome 有所区别。</p><p id="34FP6L8O">“在将浏览器移植到 Chromium 内核的过程中，为了与 Chrome 有所区别，团队认为需要添加独特的用户界面元素——因此在移植过程中重度使用了 React。”</p><p id="34FP6L8P">因此，从某种意义上说，当前的 Web UI 2.0 项目实际上是在对 Edge 最初开发工作中采用 React 的部分进行回溯。</p><p id="34FP6L8Q">Ritz 的团队负责其中一个 React Web UI 组件：“浏览器扩展”。在 Edge 浏览器中，用户可以通过点击工具栏上的心形图标来激活这个功能。它会打开一个侧边栏，这个侧边栏成了实验场，可用于测试用 Web 组件替换 React 组件后，能够为 UI 带来怎样的性能提升。</p><p class="f_center"><img src="https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2024%2F1027%2F070ee1d0j00slzt3b0024d200u000hkg00id00aq.jpg&thumbnail=660x&quality=80&type=jpg"/><br/></p><p id="34FP6L8S">Web 组件没有未来？</p><p id="34FP6L8T">最近，社交媒体上再次掀起了关于 Web 组件与框架组件优劣的激烈讨论。SolidJS 框架作者 Ryan Carniato 发表了一篇颇具挑衅性的博文，标题为“Web 组件不是未来。”他的核心观点是，像 SolidJS 这样的框架在某些特定场景下能够完成 Web 组件无法完成的任务，并且实现起来更为简便。他认为 Web 组件只是一种“彻头彻尾的妥协”。</p><p id="34FP6L8U">作为回应，Shoelace 作者 Cory LaViska 提出了反驳，他认为 Web 组件在提供稳定性和跨框架互操作性方面具有明显优势。</p><p id="34FP6L8V">LaViska 指出：“开发者对框架的不断变化感到疲惫。他们厌倦了上个月写的代码这个月就过时了。他们想要稳定，希望今天构建的东西明天还能用。”</p><p id="34FP6L90">LaViska 还指出，Web 组件没有做到框架组件所能做到的所有功能是“因为它们是对互操作性元素的一种更为底层的实现”。</p><p id="34FP6L91">这场在社交媒体上永无休止的争论——虽然现在已经从日常信息流中淡出，但可以肯定的是，一两个月后又会卷土重来。不管怎样，我问了 Andrew Ritz 关于他的团队如何适应 Web 组件以及它们是否真的像一些批评者所说的那样难以部署。</p><p id="34FP6L92">“我们的策略其实很直接，就是尽可能利用浏览器内置的功能，”他回答说。“也就是说，尽可能使用浏览器中原生的元素，这样做并没有想象中那么困难。”</p><p><blockquote id="34FP6LA0">“……努力让 Web 组件表现良好绝对是一个问题。”——Ritz</blockquote></p><p id="34FP6L93">Ritz 提到，Edge 开发者得益于微软自家的 Fluent UI 框架，这个框架包含了 React 组件和 Web 组件（以及其他多种类型的组件，比如专为 iOS 和 Android 设计的组件）。但他也承认，即便是使用公司统一的框架来实现 Web 组件也并非易事。</p><p id="34FP6L94">“在某些情况下，内置控件需要大量的定制工作——当中有许多我们可能并不需要的 polyfill，或者诸如此类的东西——因此，努力让它们表现良好确实是一个问题。”</p><p id="34FP6L95">关于 Ritz 所说的围绕 Web 组件的“开发敏捷”（其他人可能称之为“开发者体验”），他表示，“我们实际上看到了一些相当不错的改进。”例如，专注于 HTML 和 CSS 意味着开发人员和设计师能够更好地保持一致——因为他们使用的是相同的语言。</p><p id="34FP6L96">“开发人员可以专注于使用 HTML 和 CSS，基本上消除了整个翻译层（可能有人需要将线框图转换成其他形式，这对开发者生产力来说是一个巨大的障碍）。”</p><p id="34FP6L97">关于 Web 组件的广泛采用</p><p id="34FP6L98">可以说，对于微软的浏览器团队来说，采用 Web 组件比一般的 Web 开发团队要来得更为容易。除了能够利用微软自家的 Fluent UI 框架，Edge 团队还在开发一个只需适配单一浏览器的产品：他们自己的浏览器。相比之下，其他 Web 开发团队需要确保他们的产品能够在多种不同的浏览器上良好运行，包括 Chrome、Edge、Safari、Firefox 等。</p><p id="34FP6L99">“我们可能更容易一些，因为我们只依赖 Edge 浏览器处理我们的本地事务，”Ritz 解释道。“而对于其他 Web 开发者来说——他们可能还得支持 Safari，或者其他……这无疑增加了复杂性。”</p><p><blockquote id="34FP6LA1">“如果我们能让微软内部一些更大的非 Web 组件网站迁移过来，那将是一个很好的证明。”——Ritz</blockquote></p><p id="34FP6L9A">尽管如此，微软计划将部分 WebUI 2.0 包以及一套“Web 平台模式”开源。然而，Ritz 指出，许多外部开发者可能并不打算完全模仿微软的做法——例如，许多开发者可能倾向于选择一个不同于 Fluent UI 的样式框架。但至少，Ritz 的团队能够为其他人提供“学习模式”作为参考。</p><p id="34FP6L9B">一个可能的中间步骤是尝试说服微软的其他 Web 产品转向使用 Web 组件。</p><p id="34FP6L9C">“我不知道微软的其他团队会怎么做，”Ritz 说。“但 Edge 团队正努力建立一个公共库……但我认为如果能让微软内部一些更大的非 Web 组件网站迁移过来，那将是一个很好的证明。”</p><p id="34FP6L9D">但他也补充说，他们对与外部合作伙伴合作持开放态度，希望一起引领一个超越 React 框架的 Web 开发新时代。</p><p id="34FP6L9E">“如果我们能找到一个在这个领域有共同愿景并愿意合作的合作伙伴——毫无疑问，我们会非常乐意。”</p><p id="34FP6L9G">https://thenewstack.io/how-microsoft-edge-is-replacing-react-with-web-components/</p><p id="34FP6L9H"><strong>声明：本文为 InfoQ 翻译，未经许可禁止转载。</strong></p><p id="34FP6L9R">2024 年收官之作：12 月 13 日 -14 日，AICon 全球人工智能开发与应用大会将在北京举办。从 RAG、Agent、多模态模型、AI Native 开发、具身智能，到 AI 智驾、性能优化与资源统筹等大热的 AI 大模型话题，60+ 资深专家共聚一堂，深度剖析相关落地实践案例，共话前沿技术趋势。大会火热报名中，详情可联系票务经理  咨询。</p>