Web Components 消除 JavaScript 框架锁定

Web Components 的角色与承诺

• 被视为一种基于标准的方式来封装 UI，使其能够跨框架复用（React、Vue、Angular、Svelte），或作为“islands”嵌入静态/SSR 页面中。
• 有助于在框架之间进行渐进式迁移，或将某个框架特定的小部件包装后在别处使用。
• 一些人认为它们非常适合叶子组件、设计系统、高交互或内部有状态的小部件，以及不需要构建步骤的简单应用。

局限性、缺口与 Shadow DOM 问题

• 许多评论者认为 Web Components “半成品”：单独使用时 ergonomics 令人别扭，通常需要辅助库（例如 lit、Stencil），这又会重新引入类似框架的锁定。
• Shadow DOM 尤其有争议：从外部难以样式化、依赖 ::part、难以匹配设计师驱动的布局，以及在 shadow 边界之间处理表单和 ARIA 时存在问题。
• 链接的 W3C 文档列出了许多缺失或令人痛苦的部分（表单参与、可访问性、样式、作用域注册表等），表明还需要更多规范。
• 有人认为 Shadow DOM 以拙劣方式重复了 iframe 或 CSS 作用域；少数人认为它是一个应该重新设计的错误。

与 React 及其他框架的关系

• 普遍认同 Web Components 是低层原语或一种“ABI”，而不是替代那些处理路由、状态管理和模板的框架。
• 一派强调 React 的核心价值：一种将 UI 视为应用状态（大体上）纯函数的模型。另一派则反驳说，这种模式早于 React，而 JSX/模板便利性以及 Facebook 的推广才是更大的因素。
• 对 React 的批评：很重、对许多应用来说过度设计、hooks 复杂、虚拟 DOM 假设与现代浏览器不匹配，以及“框架专家”式的孤岛。
• 对 React 的辩护：生态成熟、招聘池强大、SSR 方案完善，并且在能力与可维护性之间仍有不错的平衡。也讨论了其他替代方案（Solid、Svelte、Vue、Angular、lit）在某些维度上更合适。

实际使用与最佳实践

• 使用 Web Components 进行生产的实践者建议：
  • 更适合自包含的小部件；不要仅靠裸 Custom Elements 构建整个应用，除非再加一层模板化。
  • 对应用级组件可以考虑避免使用 Shadow DOM，或使用某些模式（CSS parts、template viewport、base-style mixins）来减轻样式化困难。
  • 每个应用尽量只保留一个主框架，以获得更好的性能和一致性；在必要时在边界处使用 Web Components。

组织与生态系统考量

• 技术栈选择在很大程度上受招聘难易度、团队一致性以及现有代码库影响。
• 有些人希望未来依赖更少、原生能力更多；另一些人则认为趋势是向更多工具和更高层抽象发展，而这些抽象将建立在框架和 Web Components 之上。