为什么会有人使用 WCB？

WebComponent 基类以尽可能轻的重量提供完整的组件开发体验：用最少的代码提升生产力。

WCB 的存在有五个理由：

1. 它是你能买到的最廉价的运行时响应式方案。 以最小的体积提供完整的开发体验：声明式模板、带类型的 prop⇄attribute 同步、生命周期钩子，以及保留状态的重新渲染。Lit 和 FAST 在体积上（brotli 压缩后）要贵 2 到 4.7 倍。如果你的预算是“一个用于基本静态页面的组件”，那么在 Lit 和 FAST 是体积负担最重的地方，WCB 正合适。
2. 真正的零工具链。 无需编译器、无需装饰器、无需构建步骤：在 <script type="module"> 中从 CDN 一次 import 即可在现代浏览器中运行。整个心智模型就是 static props + template + 四个钩子，发布的源码可以一口气读完。运行时经 brotli 压缩后为 2.6 kB（已实测）。
3. 以属性（attribute）为先的响应式是 HTML 原生的。 因为 props 会序列化为属性，初始状态可以由任意服务端以纯 HTML 渲染（无需集成任何 JS 框架的 SSR），并且组件在开发者工具中仍然可以像普通属性一样被检查和调试。
4. 默认使用 Light DOM。 全局样式表、表单和第三方 CSS 都能正常工作；而当你需要封装时，只需一个静态字段即可启用 Shadow DOM。
5. 体积门槛是受治理的值。 每新增一个字节都必须在 体积变更记录 中说明理由，并由 CI 中的 size-limit 预算强制执行。智能差异对比（diffing）是项目历史上最大的一次单项新增，代价是 0.43 kB。

什么时候 WCB 不是正确的选择

诚实地做出选择：

• 有状态项的可重排列表：patch 是基于位置而非 key 的；被保留的焦点/动画会跟随位置，而不是跟随该项本身。Lit 的 repeat 或 FAST 能正确处理这种情况。
• 大型树上的高频更新：WCB 每次 prop 写入都会同步重新渲染，并对整个 vnode 树做差异对比；Lit/FAST 则在批量调度下只更新受影响的绑定。
• 带客户端水合（hydration）的 SSR：WCB 在 connectedCallback 之后于客户端渲染，因此没有水合步骤。如果你需要在服务端渲染标记并原地水合，请使用 Lit（@lit-labs/ssr）。
• 大团队、长周期的设计系统：WCB 是由个人维护、故意保持小体量的库。如果需要大型组织的支持和生态系统，请选择 Lit（OpenJS 基金会）或 FAST（微软，为 Fluent UI 提供支持）。

关于支撑这些说法的实测数字和逐能力对比，参见 WCB 与同类库对比。