Published on

Web Components：一个美好的"谎言"？为什么它没能统一前端？

Authors
  • avatar
    Name
    青雲
    Twitter

你是否也曾有过这样的疑问：为什么我们不能拥有一套标准的、跨框架的组件方案，从而告别如今前端圈因 React、Vue、Angular 等框架而形成的“生态割裂”？

这几乎是前端圈的“天问”之一。我们都曾幻想过一个理想世界：无论是 dialog 还是 toast，都只需要一个标准的 <custom-dialog> 标签就能搞定，无需关心项目用的是什么技术栈。

这个梦想的承载者，就是 Web Components。它的初衷无比宏大：一次编写，到处运行。通过浏览器原生支持的组件化能力，彻底终结“一个框架一套组件库”的混乱局面。

然而，多年过去，Web Components 依旧“不温不火”，甚至许多开发者从未在生产环境中使用过它。理想与现实的巨大鸿沟背后，究竟隐藏着怎样的原因？

为什么 Web Components 未能成为主流？

要理解 Web Components 为何未能一统江湖，我们需要从技术本身的“硬伤”、生态环境的“包袱”以及历史进程的“无奈”三个维度进行深入剖析。

1. 技术本身的“硬伤”与“不便”

Web Components 的核心由四项技术组成：Custom Elements（自定义元素）、Shadow DOM（影子 DOM）、HTML Templates（HTML 模板）和 ES Modules。这套组合拳听起来威力十足，但实战中却显得“磕磕绊绊”。标准在 2014 年左右由 Polymer 团队率先推动，直到 2020 年 Safari 14 才补齐 Shadow DOM 支持，整个生态一直处在“规范领先、落地滞后”的尴尬节奏。

  • 过于“原始”，开发者体验欠佳 Web Components 提供的是一套极其底层的 API。它仅仅解决了 UI 的封装和复用，但对现代前端开发至关重要的状态管理、数据绑定、路由等核心问题，它选择了“袖手旁观”。

    想象一下，在 React/Vue 中，我们习惯了 useState 或 ref 带来的数据驱动视图更新的丝滑体验。但在原生的 Web Components 里，你必须手动操作 DOM 来同步状态，仿佛一夜回到 jQuery 时代，代码冗长且容易出错。虽然可以自行封装，但这无异于“重复造轮子”。

  • Shadow DOM：一把锋利的双刃剑 Shadow DOM 提供了近乎完美的 CSS 隔离，组件内外的样式互不干扰，彻底解决了全局 CSS 污染的噩梦。但这种“绝对隔离”也带来了新的麻烦：

    • 外部样式注入困难：当你想从外部微调组件内部样式时（例如，改变一个按钮的颜色），会发现异常困难。尽管有 ::part 和 ::theme 等 API 用于暴露特定部分的样式，但其灵活性和便利性远不如一个简单的 CSS 选择器，且高度依赖组件作者的“预留”。
    • 全局样式共享隔绝：项目中的全局主题、CSS 变量或基础样式（如 normalize.css）默认无法穿透 Shadow DOM。这意味着每个组件都可能需要重复引入或特殊处理这些共享样式，增加了复杂性。

  • 服务端渲染 (SSR) 的“阿喀琉斯之踵” 在诞生之初的很长一段时间里，Web Components 对 SSR 的支持几乎为零。Shadow DOM 是一个纯粹的浏览器端 API，在 Node.js 环境中无法执行。这导致依赖 Web Components 的页面无法在服务端被完整渲染为 HTML 字符串，对于追求 SEO 和首屏性能的应用而言，这是致命的。直到 2022 年 Chrome 才正式支持 Declarative Shadow DOM，Firefox 仍处在实现计划中，生态库也鲜少把它当做一等公民，开发者只能依赖自研渲染管线或放弃 SSR。

2. 生态与历史的“包袱”

  • 生不逢时，错失先机 Web Components 的标准化进程漫长而曲折。就在它还在努力弥合浏览器差异、蹒跚学步之时，React (2013) 和 Vue (2014) 以“虚拟 DOM”为利器横空出世。2015 年 Redux、Vue Router、Create React App 等配套工具如雨后春笋般涌现，从构建、调试到状态管理都被打磨得足够顺手，开发者几乎没有理由等待一个“尚未跨浏览器落地”的规范。

    面对能更快、更爽解决实际问题的框架，开发者们自然“用脚投票”，Web Components 不幸沦为了那个“起了个大早，赶了个晚集”的角色。

  • 主流框架的“虹吸效应” 一旦 React、Vue、Angular 形成庞大的社区，就会产生巨大的向心力。海量的教程、开源库、招聘岗位都围绕它们构建。这形成了一个强大的正向循环：公司为了招聘和维护选择主流框架，开发者为了就业和成长学习主流框架，进一步挤压了其他技术的生存空间。

  • “跨框架”的美好伪命题 “跨框架”是 Web Components 最大的卖点，但在实践中却常常碰壁。一个 React 团队很少会引入基于 Vue 的组件库，反之亦然；不同框架拥有独特的设计哲学和数据流模式，强行混用反而会引入新的复杂性，得不偿失。与其投入人力维护一套“所有技术栈都能用”的组件，团队更乐于采用与框架深度整合的解决方案（Ant Design、Element Plus、Angular Material），因为它们连同 CLI、默认样式、无障碍支持一起打包交付，真实成本更低。

破局之路：Web Components 的新定位

那么，Web Components 是否就一无是处了呢？并非如此。它只是没有成为“主角”，但在一些特定领域，它找到了自己不可替代的价值，成为了一个优秀的**“底层技术补充者”**。

它的最佳应用场景包括：

  1. 构建真正的“原子”设计系统 (Design System) 对于需要跨技术栈、跨团队共享 UI 的大公司而言，Web Components 是构建底层原子组件（如按钮、输入框）的理想选择。这些组件不与任何框架绑定，可以在 React, Vue, Angular 甚至原生 JS 项目中无缝使用。Google 在 Material Web 3 中直接提供 web component 版本，Microsoft 的 Fluent UI Web Components 也被 Teams、Office 扩展等多条产品线复用。

  2. 微前端与嵌入式内容 当需要在应用中嵌入一个由不同技术栈开发的独立模块时，Web Components 是完美的“隔离沙箱”。每个模块可以被封装成一个独立的 Web Component，主应用只需像插入一个普通 HTML 标签一样使用它，实现真正的技术无关和团队解耦。许多微前端体系（如 single-spa、Bit Micro Frontends）都提供了直接输出 Web Component 的适配器用来完成跨框架挂载。

  3. 渐进式增强现有 HTML 有时，你只是想为某个 HTML 标签增加一些特定行为，而不是构建一个复杂的单页应用。例如，创建一个能自动格式化时间的 <time-ago> 标签或为 CMS 注入互动卡片。在这种轻量级、功能增强的场景下，Web Components 标准、无依赖的特性优势尽显。

回到最初的拷问：现实项目该如何取舍？

既然 Web Components 无法一统江湖，我们就需要在具体项目里做策略级的取舍，而不只是感叹“依赖太多”。

  1. 以 Web Components 打造跨栈底座，再用框架包装体验层。 当目标是统一一套设计语言或控件时，可以用 Web Components 落地最底层的可复用单元，再通过 Lit、Stencil、Vue/React wrapper 提供更友好的开发体验和类型支持。这种“双层架构”既发挥了标准化的价值，也兼顾日常迭代效率。

  2. 在系统边界使用 Web Components，内部保持框架一致。 对大规模应用而言，真正的痛点往往是团队协作和微前端解耦。把 Web Components 用在模块边界——例如内嵌第三方营销组件、老系统共存模块——能够减少框架之间的耦合，而核心业务仍可由主流框架接管，避免全面迁移带来的风险。

  3. 如果只是想减轻工程负担，可选择“更轻”的框架或 Headless 方案。 很多时候我们抱怨 Web Components 的原因，其实是希望找回“更原生、更可控”的感觉。Svelte、Solid 这类编译型框架在运行时接近原生，又提供了完善的开发体验；Headless UI、Radix 之类的逻辑层库也能让我们在 React/Vue 继续“减脂”，减少对臃肿组件库的依赖。

结语：标准未死，只是换了战场

Web Components 之所以没有成为主流，本质上是因为它试图解决的问题，被后来的框架以一种对开发者更友好的方式更彻底地解决了。 它在与 React/Vue 的竞争中，输在了开发体验、生态节奏和配套工具链上，于是只能退居幕后，在设计系统、微前端等“基础设施位”持续发挥价值。

换句话说，它并没有失败，而是找到了更合适的战场：为跨栈 UI 提供最低公共分母，让框架专注于上层体验。理解这一点后，我们便能在项目需求、团队能力、上线节奏之间做出更清醒的技术决策，而不是陷入“神话或失望”的二元想象。

展望：当 Web Components 遇上 AI，会发生什么？

真正有可能改变现状的，或许不是下一代框架，而是正在重塑开发模式的 人工智能 (AI)。AI 的崛起，尤其是代码生成能力的成熟，为我们最初的那个“天问”——如何实现真正的技术统一和开发简化——提供了全新的答案。

  1. AI 抹平开发体验的鸿沟。 过去我们嫌弃 Web Components API 繁琐、样板代码众多。未来的 AI 搭档可以即时生成生命周期、Shadow DOM 结构与样式桥接层，极大降低上手门槛。
  2. AI 让“跨框架”上升到描述层。 “一次描述，到处生成”意味着我们用自然语言定义组件需求，让 AI 输出 React、Vue、Svelte 甚至原生 Web Component 的实现。跨框架的梦想可能以更具想象力的方式达成。
  3. AI 暗示“后框架时代”。 当 AI 能自动为不同场景选择最优实现时，开发者只需关注体验和业务，底层选择是 Web Components 还是特定框架，将逐渐淡出决策视野。

前端世界总是在摇摆中螺旋上升。今天我们还在争论标准与框架，明天我们或许将见证 AI 如何重塑创造范式。届时，Web Components 可能不再背负“一统江湖”的期望，而是作为一块坚实的乐高积木，随时等待被新的构建方式重新启用。

Discuss on Twitter • View on GitHub