我们需要的不是“Web Components”
对 Web Components 的批评主要集中在其复杂性、语义薄弱，以及与现代 JavaScript 框架构建 UI 的实际方式不匹配；许多人认为它们增加了脆弱的规范，却没有解决状态管理、协调和样式等核心问题。评论者转而呼吁浏览器标准化开发者已经趋于一致的更底层原语——例如更好的 DOM diff、响应式机制和 UI 小部件——而另一些人则为 Web Components 辩护（通常通过 Lit 等库），认为它们是封装交互元素的一种有用、与框架无关的方式。讨论还扩展到了 JavaScript 生态的频繁更迭、重叠的标准如 Observables 和 signals，以及 Web 是否应走向更接近原生或二进制应用的模型。
标准、浏览器与治理
- 关于 Web Components 究竟是为谁而设计的争论：应用开发者，还是浏览器/标准工程师。
- 对 W3C 与 WHATWG 角色的分歧：有些人认为 W3C 只是在将 WHATWG 的事实标准正式化；也有人强调其中的摩擦（HTML 快照、隐私、会破坏现有内容的规格变更）。
- 担忧 HTML 规范及相关流程已经变得杂乱、缓慢，而且有时会破坏向后兼容性。
Web Components：优点与深度怀疑
- 支持者喜欢：
- 能定义可在各框架之间以及纯 HTML 中工作的自定义元素。
- 通过 Shadow DOM 和 ES modules 实现封装。
- 原则上可用于组件库和复杂应用（通常配合 Lit），而无需构建步骤。
- 批评者认为：
- 设计忽视了真实世界中的框架经验和用户态演进。
- 规范复杂、脆弱，并衍生出更多规范来修补 Web Component 特有的问题。
- 作为现代框架的基础构件并不合适（急切渲染、弱 SSR 故事、尴尬的组合方式、Shadow DOM 的意外行为）。
- 曾经推动 Web Components 的生态领导者已经转向其他方向。
- 一个许多人都认同它们有帮助的细分场景：封装型小部件和自定义表单控件，有点像更安全、更小的 iframe。
框架、生态更迭与兼容性
- 对 JS 前端复杂性的强烈不满：多层工具链（bundler、lint、TS、构建/转译）以及频繁的范式转变（classes → hooks → server components）。
- 也有人反驳说所有生态都会演化，而 JS 并不比例如 Python 打包或其他技术栈中的破坏性变更更糟。
- 更广泛的担忧是，JS 库和工具很少优先考虑稳定、共享的接口，导致“内部不兼容”和痛苦的升级。
响应式、Observable 与重叠的原语
- 大家都认同“响应式”和协调（reconciliation）是真问题，但尚无一致的设计方案。
- Signals、observables、streams 以及其他响应式原语有可能彼此重叠，形成不兼容的标准。
- 有些人欢迎浏览器层面的 observables；另一些人则担心会出现越来越多近乎重复的“感知变化”的方式。
WASM、原生应用与 Web 的角色
- 有些人希望浏览器直接运行原生二进制；另一些人则指出过去插件失败和安全问题的前车之鉴。
- 普遍共识是 DOM 操作主导了 UI 性能；WASM 主要有助于重计算，而不是典型的响应式 UI。
- 许多人认为 WASM 工具链在改善，但仍不如原生；虽然存在交叉编译工作流，但感觉笨重。