微軟的 Edge 瀏覽器團隊正在努力用原生 Web 平臺組件替換 React UI 組件。我們與團隊負責人進行了交談。

譯自How Microsoft Edge Is Replacing React With Web Components，作者 Richard MacManus。

當微軟 Edge 瀏覽器團隊發布 WebUI 2.0時，該項目旨在用原生web components替換 React 組件，其主要目標是讓 Edge 瀏覽器對最終用戶來說更快。核心思想是采用“標記優先架構”將減少產品對 JavaScript 的依賴，這意味著客戶端需要處理的代碼更少，從而為用戶提供更好的體驗。

為了了解 WebUI 2.0 項目的進展，包括項目的靈感來源和最終目標，我采訪了Andrew Ritz，他是微軟 Edge 基礎團隊的負責人。

但首先，讓我們快速澄清一下什么是 web components。社區網站 WebComponents.org將其描述為“一組 Web 平臺 API，允許您創建新的自定義、可重用、封裝的 HTML 標簽，以便在網頁和 Web 應用程序中使用。” Ritz 在建議自己的團隊如何處理這種 Web 開發范式時這樣說：“任何時候你想做一個新的控件，并且發現自己正在編寫 JavaScript 代碼，請暫停，停止，與高級工程師交談，并詢問如何用 HTML 和 CSS 解決這個問題？”

為什么微軟 Edge 決定放棄 React？

Ritz 表示，他的團隊的目標是在今年年底之前將 Edge 中大約 50% 的現有基于 React 的 Web UI 轉換為 web components。

但這個項目的動力是什么？為什么他們決定需要在 Web 界面中遠離 React？Ritz 解釋說，這源于他們觀察到 Edge 瀏覽器“Web 桌面”團隊收到的工作請求——“包括外部請求，以幫助改進 Chromium 項目，以及內部請求。”

“…我們 [微軟] 采用了 React 框架，并且我們可能以最糟糕的方式使用了 React。”

– Andrew Ritz，微軟 Edge 基礎團隊合作伙伴總經理

后者的一個例子是 Excel 網頁應用程序，它使用 Canvas 元素。因此，他們必須考慮的一個問題是，“我們如何才能提高 Canvas 的性能？” HTML<canvas>元素用于通過腳本動態繪制圖形——通常使用 JavaScript 完成。

為了幫助 Web 桌面團隊處理此類請求，Ritz 希望采用更“有主見的方法”，這也將解決 Web 應用程序速度慢等問題。

“因此，我們開始查看內部所有使用 Web 技術的地方——也就是我們所有的內部 Web UI——并意識到它們的速度真的慢得無法接受。”

為什么它們速度慢？答案是：React。

“我們意識到，我們的性能，尤其是在低端機器上，非常糟糕——這是因為我們采用了 React 框架，并且我們可能以最糟糕的方式使用了 React。”

隨著越來越多的團隊使用 React 來構建 UI，微軟內部對 React 的使用隨著時間的推移不斷增加。因此，該公司最終得到了“一個巨大的捆綁包，每個人都依賴它”，Ritz 說。這是 Web 應用程序之間捆綁包依賴關系的一團糟。

“這是一種糟糕的體驗，尤其是在低成本、低端機器上，”Ritz 說。“我們看到啟動時間長達數秒，而這本該是本地化的。這真是，你知道，令人震驚。”

Edge Web UI

Ritz 說，Edge 本身有 50 到 100 個 Web UI，“每個 UI 都像一個小的 Web 應用程序。” 在 Web UI 2.0 項目開始之前，大約三分之二的 Edge Web UI 是用 React 構建的。有趣的是，Edge 團隊最初使用 React 的目的是為了與 Chrome 區分開來。

“該團隊在將 Edge 移植到 Chromium 的過程中，決定，好吧，我們需要添加一些 UI 區別——與 Chrome 不同——因此，在這個過程中，他們進行了這種大規模的 React 轉換。”

因此，當前的 Web UI 2.0 項目在某種程度上是對 Edge 上完成的原始開發工作的回溯。

Ritz 的工程團隊負責其中一個 React Web UI：“瀏覽器擴展”。當您使用 Edge 時，它可以通過點擊瀏覽器欄中的心形圖標激活，這會打開一個側邊欄。然后，它成為測試平臺，用于查看使用 web components 替換 React 組件可以為該 UI 帶來哪些性能改進。

Edge 瀏覽器要點（右側）

Web Components 太難了嗎？

最近，社交媒體上又爆發了一場關于 Web 組件與框架組件的爭論。SolidJS JavaScript 框架的創建者Ryan Carniato發表了一篇博文，標題頗具挑釁意味，名為“Web 組件并非未來”。他的主要觀點是，像 SolidJS 這樣的框架在某些情況下比 Web 組件能做更多的事情，而且更容易實現。他將 Web 組件斥為“徹頭徹尾的妥協”。

針對 Carniato 的觀點，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 時代的發展。

“如果我們能找到一個有意義的外部合作伙伴，他們愿意與我們合作——我們當然會很高興。”