Web Components 是用于創(chuàng)建適合多種用途的 HTML 元素的 Web 技術(shù)。對(duì)這種現(xiàn)象有一種不同的態(tài)度：一些人相信 Web 組件的革命性潛力（盡管它們于 2011 年首次推出），另一些人仍然持懷疑態(tài)度并繼續(xù)使用 React。

許多開(kāi)發(fā)人員似乎對(duì) Web Components 消滅前端框架的想法感到威脅。但這不會(huì)發(fā)生，因?yàn)樗鼈兪菫榻鉀Q不同的問(wèn)題而生的。

背景

為什么我們需要 WebComponents？

使用 Web 組件的原因，我們可以從三個(gè)方面來(lái)看待這個(gè)問(wèn)題，一個(gè)是趨勢(shì)，一個(gè)是技術(shù)本身，另一個(gè)是商業(yè)成本。

首先我們從趨勢(shì)上來(lái)分析：

流行趨勢(shì)

盡管對(duì) Web 組件有一些普遍的保留意見(jiàn)，但還是有不少大公司充分利用了這項(xiàng)技術(shù)。這里是其中的一些：

1. 頭部案例

• Twitter：嵌入式推文
• YouTube：該站點(diǎn)是使用 Web Components 構(gòu)建的
• Electronic Arts：該站點(diǎn)也是使用 Web Components 構(gòu)建的
• Adobe Spectrum：該站點(diǎn)是一個(gè)基于 Web Components 的 UI 框架產(chǎn)品

另外還有維基百科、可口可樂(lè)、麥當(dāng)勞、IBM 和 通用電氣 等也使用基于Web 組件的技術(shù)和框架。

2. 整體數(shù)據(jù)

除此以上案例，還有大部分 未統(tǒng)計(jì)的案例。

下圖顯示了customElements.define至少調(diào)用一次的頁(yè)面加載百分比（在 Chrom e 中）。

使用 CustomElementRegistryDefine 的頁(yè)面加載百分比（在 Chrome 中）

（來(lái)源：https://chromestatus.com/metrics/feature/timeline/popularity/1689 ）

我們可以看到，在 Chrome 瀏覽器中查看的所有網(wǎng)站中，超過(guò) 15% 的網(wǎng)站至少注冊(cè)了一個(gè)自定義元素。相比之下，根據(jù) w3techs.com 的數(shù)據(jù)，只有 2.3% 的網(wǎng)站使用 React。

還有另外一個(gè)數(shù)據(jù)來(lái)反應(yīng) Web Components 的受歡迎程度，下圖是 Web組件在 Chrome 瀏覽器中查看的所有網(wǎng)站中的歷年增長(zhǎng)趨勢(shì)。

使用 CustomElementRegistryDefine 的頁(yè)面歷年變化趨勢(shì)（在 Chrome 中）

我們可以看到 Web組件的增長(zhǎng)趨勢(shì)是十分亮眼的。

技術(shù)優(yōu)點(diǎn)

1. 原生支持

原生支持意味著可以不需要任何框架即可完成開(kāi)發(fā)，同時(shí)也意味著這將有更好的用戶體驗(yàn)，更低的網(wǎng)絡(luò)請(qǐng)求，以及更穩(wěn)定的迭代前景。并且我們一直都有在使用這項(xiàng)技術(shù)，比如 input， video，select 等等，其實(shí)他們都是標(biāo)準(zhǔn)的原生組件，只是如今我們自己也可以使用這項(xiàng)技術(shù)去創(chuàng)造這些組件。

2. 無(wú)排他性

這是原生支持的一個(gè)延伸表現(xiàn)，作為瀏覽器原生支持也就意味著它可以在任何環(huán)境中使用，例如在 React，Angular，Vue 中使用他們。同時(shí)也意味著對(duì) Web Components 的支持無(wú)需大刀闊斧的顛覆現(xiàn)有邏輯體系，你可以從局部開(kāi)始進(jìn)行改造。

3. 無(wú)依賴性

這一點(diǎn)同樣是原生支持的一個(gè)延伸表現(xiàn)，通過(guò)提供連接特定 Web 組件的選項(xiàng)，而無(wú)需將框架的依賴項(xiàng)導(dǎo)入到項(xiàng)目中，您就可以擁有優(yōu)于流行框架的優(yōu)勢(shì)。

讓我們想象一個(gè)場(chǎng)景：如果您喜歡用 React 創(chuàng)建的小部件，并且想將其包含在您的項(xiàng)目中，則必須首先包含整個(gè) React 庫(kù)，然后才能導(dǎo)入您喜歡的小部件。相反，如果您選擇使用 Web 組件創(chuàng)建的小部件，您可以立即將其插入到項(xiàng)目中——這一切都?xì)w功于這項(xiàng)技術(shù)的原生特性。

4. 性能優(yōu)勢(shì)-優(yōu)先邏輯無(wú)阻塞

Web Components 的優(yōu)勢(shì)在于頁(yè)面網(wǎng)絡(luò)請(qǐng)求時(shí)即可開(kāi)始進(jìn)行對(duì)自定義組件的注冊(cè)，當(dāng)然也可以在加載完成之后完成自定義組件的注冊(cè)，即可以理解為組件是異步執(zhí)行與渲染的，同時(shí)還可以結(jié)合 ES6 Module 來(lái)輕松的完成組件的按需加載。

我們以，對(duì) React 組件的 Web Components 化為例，一個(gè)普通的 React 組件在初次執(zhí)行時(shí)需要一次性走完所有必須的節(jié)點(diǎn)邏輯，而這些邏輯的執(zhí)行都同步占用在 js 的主線程上，那么當(dāng)你的頁(yè)面足夠復(fù)雜時(shí)，一些非核心邏輯就將會(huì)阻塞后面的核心邏輯的執(zhí)行。

比如首次加載時(shí)，你的頁(yè)面中有一個(gè)復(fù)雜的交互組件，交互組件中又包含 N多邏輯和按鈕等小組件，此時(shí)頁(yè)面的首次加載不應(yīng)該優(yōu)先去執(zhí)行這些細(xì)節(jié)邏輯，而首要任務(wù)應(yīng)當(dāng)是優(yōu)先渲染出整體框架或核心要素，而后再次去完善那些不必要第一時(shí)間完成的細(xì)節(jié)功能。 例如一些圖像處理非常復(fù)雜，但你完全沒(méi)必要在第一時(shí)間就去加載他們。

當(dāng)我們使用 Web Components 來(lái)優(yōu)化 React的時(shí)候，這個(gè)執(zhí)行過(guò)程將會(huì)變得簡(jiǎn)潔的多，比如我們注冊(cè)了一個(gè)復(fù)雜的邏輯組件，在 React 執(zhí)行時(shí)只是執(zhí)行了一個(gè) createElement 語(yǔ)句，創(chuàng)建它只需要 1-2 微秒即可完成，而真正的邏輯并不在同時(shí)執(zhí)行，而是等到“核心任務(wù)”執(zhí)行完再去執(zhí)行，甚至你可以允許它在合適的時(shí)機(jī)再去執(zhí)行。

document.createElement('my-element')

我們也可以簡(jiǎn)單的理解為，部分邏輯在之后進(jìn)行執(zhí)行然后被 render 到指定 id 的 Div 中的，那么為什么傳統(tǒng)的組件為什么不能這么做呢？而非得 Web Components 呢？那就不得不提到它所包含的另一個(gè)技術(shù)特性：Shadow DOM。

它使得每個(gè)組件都有自己的根節(jié)點(diǎn)，因此它可以做到對(duì)主 DOM 沒(méi)有侵害性，所以相對(duì)而言異步執(zhí)行并不會(huì)造成性能破壞，同時(shí)相對(duì)混合 React 而言同時(shí)還能降低 Diff 成本。

5. 性能優(yōu)勢(shì)-組件隔離（Shadow Dom）

Shadow DOM 為自定義的組件提供了包括 CSS、事件的有效隔離，不再擔(dān)心不同的組件之間的樣式、事件污染了。 這相當(dāng)于為自定義組件提供了一個(gè)天然有效的保護(hù)傘。

Shadow DOM 實(shí)際上是一個(gè)獨(dú)立的子 DOM Tree，通過(guò)有限的接口和外部發(fā)生作用。 我們都知道頁(yè)面中的 DOM 節(jié)點(diǎn)數(shù)越多，運(yùn)行時(shí)性能將會(huì)越差，這是因?yàn)?DOM 節(jié)點(diǎn)的相互作用會(huì)時(shí)常在觸發(fā)重繪（Repaint）和重排（reflow）時(shí)會(huì)關(guān)聯(lián)計(jì)算大量 Frame 關(guān)系。

而對(duì) CSS 的隔離也將加快選擇器的匹配速度，即便可能是微秒級(jí)的提升，但是在極端的性能 情況下，依然是有效的手段。

6. 性能優(yōu)勢(shì)-Tagged Template VS jsx

ES6 中的 template + tagged template 也是 Web Components 的標(biāo)準(zhǔn)特性之一，作為瀏覽器的原生支持，相比于 JSX 不僅無(wú)需預(yù)編譯預(yù)處理，并且還有這更強(qiáng)的擴(kuò)展能力。在性能上原生支持有著更優(yōu)的處理性能。而 JSX 在每次 render 時(shí)，都需要完整的構(gòu)造一個(gè)虛擬DOM，并且它還需要 JSS 將 CSS-in-JS 轉(zhuǎn)換為樣式表。因此同樣功能的 JSX 將占用更多的 CPU 運(yùn)算。

以下是在 Moto G4 手機(jī)上的 React 頁(yè)面 和 混合頁(yè)面 （React + Web Components）上運(yùn)行網(wǎng)頁(yè)測(cè)試的平均運(yùn)行重復(fù)視圖結(jié)果?？梢钥吹筋愃频内厔?shì)，React 頁(yè)面中的腳本比混合頁(yè)面占用更多的 CPU。

Performance comparison of the React Page and Web Component Page on PC

下面的火焰圖顯示了用于 React 頁(yè)面和 Web 組件頁(yè)面的腳本、布局和繪制時(shí)間的 CPU 模式。

Flame chart for React Page

Flame chart for Web Component Page

專項(xiàng)性能分析參考：https://medium.com/@spkamboj/web-components-basics-and-performance-benefits-f7537c908075與 Web 組件頁(yè)面相比，React 頁(yè)面在 JS 中花費(fèi)的 CPU 時(shí)間多 7 倍。在 React 頁(yè)面上，額外的 CPU 成本來(lái)自 JS 包的編譯、React 在其協(xié)調(diào)步驟期間花在虛擬 DOM 比較上的時(shí)間、JSS 將 CSS-in-JS 轉(zhuǎn)換為 CSS 樣式表并將其插入到文檔中的時(shí)間。而 Web 組件實(shí)現(xiàn)不會(huì)產(chǎn)生任何框架包編譯成本、虛擬 DOM 協(xié)調(diào)成本或任何 CSS-in-JS 轉(zhuǎn)換成本。與 React 頁(yè)面相比，具有較低 CPU 成本的 Web 組件頁(yè)面將更快地具有交互性，并且可以更快地響應(yīng)使用操作。

由于使用了 Template 技術(shù)，模版節(jié)點(diǎn)操作的對(duì)象是一個(gè) DocumentFragement，而并非是真實(shí) DOM 的一部分，相比 JSX 產(chǎn)生的 JS 堆棧其內(nèi)存占用更小。

尤其當(dāng) VDOM 較大時(shí)，性能邊界就尤其明顯，大體積的 VDOM 與 tagged template 相比或差 1-2 個(gè)量級(jí)水平。

7. 性能優(yōu)勢(shì)-原生的生命周期控制

Web Components 具有原生的組件生命周期回調(diào)支持，當(dāng)其與文檔的連接與段開(kāi)時(shí)無(wú)需額外的外部狀態(tài)標(biāo)記，這使得當(dāng)組件被移動(dòng)或被移除等場(chǎng)景無(wú)需通過(guò)鉤子函數(shù)即可獲取，同時(shí)也無(wú)需 VDOM 去應(yīng)對(duì) Diff 元素變化。即回歸純粹，又更優(yōu)于性能。

8. 更高的可靠性

Web Components 更符合 OO思想，同時(shí)也很好的優(yōu)化開(kāi)發(fā)者對(duì)開(kāi)閉原則的運(yùn)用。強(qiáng)約束將使得組件與組件之間做到充分的獨(dú)立功能與擴(kuò)展，從而改變開(kāi)發(fā)者松散的設(shè)計(jì)習(xí)慣，更利于使得生產(chǎn)出的產(chǎn)品具有良好的可靠性和穩(wěn)定性。

我們常常把代碼約束理解為不便利，這也是阻礙 Web Components 更加流行的一項(xiàng)原因，但是我們需要知道，性能和可靠性的確是需要付出成本的，而這個(gè)成本相對(duì)可靠性來(lái)說(shuō)一定是很值得的。

9. 良好的可讀性

使用 Web Components 的另一大優(yōu)勢(shì)是項(xiàng)目代碼的組織和調(diào)試。

例如，當(dāng)你嘗試在 DOM 中查找 React 制作的組件時(shí)，您在 DOM 中看到了什么？Div, div, div... 我的 **Heade 在哪里？所以在 DOM 中查找 JSX 代碼的反射可能會(huì)很頭疼。對(duì)于 Web 組件，如果您定義了my-super-header **而你將直接在 DOM 中看到你的組件。非常方便調(diào)試。

商業(yè)成本優(yōu)勢(shì)

1. 供應(yīng)商鎖定

供應(yīng)商鎖定是指切換到不同供應(yīng)商的成本如此之高以至于人們基本上被原始供應(yīng)商所束縛的情況。

眾所周知，軟件行業(yè)是發(fā)展最快、變化最快的行業(yè)之一。這伴隨著軟件工程中的許多變化和創(chuàng)新。假設(shè)明年有人會(huì)發(fā)布最終的前端框架，這將使任何現(xiàn)有的框架黯然失色。

同時(shí)越來(lái)越多的開(kāi)發(fā)人員正在采用新框架。而切換到新框架的成本將非常昂貴，因?yàn)槟悴坏貌幻總€(gè)前端組件都必須遷移到新框架上來(lái)，并且可能會(huì)中斷業(yè)務(wù)運(yùn)營(yíng)。

假設(shè) React 將不再高效，尋找優(yōu)秀的 React 開(kāi)發(fā)人員也變得越來(lái)越復(fù)雜和昂貴。

2. 安全成本

如果有特定原因，你可能會(huì)選擇 Web 組件。例如，它適用于項(xiàng)目對(duì)安全級(jí)別要求較高的情況（比如金融行業(yè)產(chǎn)品），因此不應(yīng)使用第三方庫(kù)，必須使用原生技術(shù)，并且必須控制導(dǎo)入庫(kù)的全部?jī)?nèi)容。對(duì)于像 React 這樣的大型庫(kù)，很難不斷地從一個(gè)版本到另一個(gè)版本審核所有庫(kù)錯(cuò)誤和漏洞。簡(jiǎn)而言之，你一定會(huì)存在一種情況是你不想依賴第三方框架或外部庫(kù)。

3. 其它工具可以負(fù)擔(dān)的起 HTML

如果你計(jì)劃使用來(lái)自其他非 Web 原生編程語(yǔ)言（如 Java 或 Kotlin）的 HTML，則 Web 組件特別有用。

4. 協(xié)同效應(yīng)

安德魯·坎貝爾等(2000）在《戰(zhàn)略協(xié)同》一書(shū)中說(shuō)：“通俗地講，協(xié)同就是‘搭便車’。當(dāng)從公司一個(gè)部分中積累的資源可以被同時(shí)且無(wú)成本地應(yīng)用于公司的其他部分的時(shí)候，協(xié)同效應(yīng)就發(fā)生了”。

2021 除了最火的元宇宙，Web3.0 也將是一場(chǎng)時(shí)代變革。我們需要看到的是互聯(lián)網(wǎng)誕生的第一性原理是什么？——“數(shù)據(jù)共享”。而當(dāng)前的互聯(lián)網(wǎng)數(shù)據(jù)都集中在少數(shù)寡頭手里，這完全違背了互聯(lián)網(wǎng)的初衷，因此 Web3.0 抱著這樣的使命而誕生的。

同樣，Web Components 的使命也是如此。我們可以在一個(gè)統(tǒng)一的 Web 中共享我們的 Web 組件不是很好嗎？我們可以選擇最好的 UI 組件而不必關(guān)心框架。這將使我們獨(dú)立于 JavaScript 框架。使用 Web Components 將大大降低在它們之間進(jìn)行更改的成本。

回歸 Web第一性原理，讓共享變?yōu)榭缭绞降哪芰?，不僅對(duì)行業(yè)本身的收益是呈現(xiàn)不斷增加的，甚至是對(duì)整個(gè)世界各行各業(yè)的的收益都是一個(gè)正向影響。

最后

正向影響。 再次重申 Web Components 并非是為了完全替代任何現(xiàn)有框架而生，它其實(shí)是一組技術(shù)的運(yùn)用，為了解決 Web組件的重用和共享問(wèn)題，并使得 Web生態(tài)保持持續(xù)的開(kāi)放和統(tǒng)一。 雖然它也并非是完美的，但是它確實(shí)在該領(lǐng)域有著不可比擬的優(yōu)勢(shì)，尤其是對(duì)重用度很高的基于 Web的組件應(yīng)用來(lái)說(shuō)，使用 Web Components 是再好不過(guò)的選擇了。