標準是親兒子，市佔卻是孤兒：Web Components 十三年推不動的替代帳

（本文回顧的事件：2026年8月26日，技術社羣掘金出現一篇長文〈Web Components 為什麼火不起來〉，重新引發對這個瀏覽器原生組件標準採用率的討論。）

一組數字先看時間成本：2013年 Google 首次提出 Web Components 概念，到文章發表的2026年，整整十三年。這是一個由 W3C 背書、三大瀏覽器引擎原生支援、不依賴任何第三方框架的組件化標準，由 Custom Elements、Shadow DOM 與 HTML Templates 三個底層 API 組成。按技術推廣的常規曲線，一個免授權費、免建置工具鏈、天然跨框架複用的開放標準，十三年足夠完成至少兩輪產業替代。但現實是，原文給出的觀察相當直接：絕大多數前端工程師仍在用 React 或 Vue 寫組件，Web Components 在實際商業專案中的採用率低到尷尬。

這則討論值得重看的原因，在於它是一個教科書級的案例：當技術上的正確，遇上演進曲線上的錯位，市場會如何投票。

同一個計數器，五倍的程式碼量

原文最有說服力的一段，是把同一個需求放在兩套體系下對照。一個可點擊的計數器組件，React 的寫法約三行程式碼：useState 管狀態，回傳一個帶事件綁定的按鈕，狀態驅動視圖。Web Components 的原生寫法則需要繼承 HTMLElement、手動 attachShadow、手動拼接 HTML 字串、手動綁定事件，且因為 innerHTML 重繪會銷毀舊 DOM 節點，每次渲染後必須重新綁定監聽器，狀態更新也得手動觸發重新渲染。原文估算，同樣功能的原生程式碼量是 React 的五倍以上。

五倍不是修辭，是工程成本結構的具體換算。假設一個十人前端團隊、每人每天有效產出固定的條件下，開發體驗的五倍落差直接乘進人力成本、交付週期與維護負債。這還只是計數器這種最簡單的場景；原文進一步指出，當組件狀態複雜化，例如一個包含二十個聯動欄位的表單，缺乏響應式機制意味着所有狀態與 DOM 的同步邏輯都要手寫，複雜度會隨欄位數量非線性膨脹。

替代曲線上的三道錯位

用技術替代曲線的透鏡看，Web Components 的困境可以拆成三層結構性問題。

第一層是時間點。Web Components 概念出現於2013年，彼時 jQuery 仍是主流，框架化浪潮尚未定型。但標準化的速度跟不上瀏覽器廠商的協調成本，等到 Custom Elements 與 Shadow DOM 在各引擎穩定落地，React 已憑虛擬 DOM 與單向數據流建立生態，Vue 也以漸進式框架與模板語法佔據了中文市場。替代窗口期一旦錯過，後來者要對抗的就不只是技術方案，還有圍繞既有方案長出來的整個工具鏈：路由、狀態管理、構建工具、除錯工具、元件庫、招聘市場。工程師履歷上寫 React 能換到的職缺數量，本身就是一項市場定價。

第二層是能力缺口。原文點出核心：Web Components 標準裡沒有任何內建響應式機制。React 有 useState，Vue 有 ref 與 reactive，狀態驅動視圖是框架的核心賣點；而原生標準下，修改屬性後 DOM 不會自動更新，工程師必須自行實作 attributeChangedCallback、自行查找節點、自行更新 textContent。用原文的形容，這等於用2026年的瀏覽器 API 寫2010年風格的 jQuery 程式碼。標準把最花錢的那一層抽象，留給了每個使用者自己造輪子。

第三層是補救方案的自我消解。Google 推出的 Lit 確實為 Web Components 補上了響應式與聲明式模板，大幅改善開發體驗。但原文的詰問切中要害：當你必須依賴一個第三方庫才能讓原生標準變得好用，這個原生標準的定位意義就被掏空了。用 Lit 寫 Web Components，與用 React 寫組件，本質上都在依賴一個框架，差別只剩輸出物是自訂元素還是框架組件樹。

誰受惠、誰承壓、傳導到哪裡

這條替代曲線的停滯，受益方與承壓方相當清晰。

受益的是框架陣營與其生態系廠商。React 背後有 Meta 的持續投入，Vue 有獨立開源社羣與商業化工具鏈，兩者的元件庫市場、教育培訓市場與人力市場都建立在「框架不可替代」的前提上。框架每多壟斷一年，轉換成本就再墊高一層：專案程式碼、團隊技能、面試題庫、課程體系，全部沉沒在同一套技術選型裡。

承壓的則是 Web Components 的理論受益者。一類是多元件框架並存的團隊，跨框架複用本是他們最強的使用動機，卻得先付出五倍的開發成本作為入場費。另一類是瀏覽器廠商與標準組織：W3C 與 Google 推動標準十三年，換來的是 API 普遍支援但使用率稀薄的結果，標準制定資源與實際工程採用之間的落差持續擴大。Lit 本身的定位也相對尷尬，它既是要拯救原生標準的橋樑，也是證明原生標準不足以獨立作戰的證據。

傳導機制很直接：開發體驗落差決定工程師選型，選型決定人才供給，人才供給決定企業專案預設技術棧，企業採用又回頭決定教育與社羣內容的產出方向。這是一個自我強化的迴圈，一旦成形，標準層面的「正確」難以單獨扭轉。

收束判斷

把時間軸拉長，這已經是開放標準對框架生態的第三次類似拉鋸，前兩次分別是 XHTML 對動態 HTML 實作、以及各類「Write Once, Run Anywhere」承諾的兌現落差。模式一致：標準追求通用與隔離，框架追求開發效率，而在工程資源有限的商業環境裡，效率的定價權幾乎每次都壓過通用性。

Web Components 不會消失，樣式隔離與跨框架嵌入這類場景仍有其不可替代的位置。但作為主流開發範式的替代者，它缺的那一塊從來不是瀏覽器支援度，而是把五倍程式碼量壓回一倍的那層響應式抽象；而這一層，十三年來始終由框架陣營持有。技術替代的帳，最終記在開發者每一行程式碼的時間成本上。