HTML Web Components

HTML Web Components vs JS 框架

• 支持者认为，自定义元素是一种“增强”原生 HTML 的方式，而不是替代它，这与渐进增强和长期可维护性相一致。
• 批评者则认为它们使用起来笨拙，通常还需要额外的库（例如 Lit），而且仍然无法解决状态管理、路由或数据获取等核心应用问题；在这些方面，React/Vue/Angular 更出色。
• 有些人认为 web components 尤其适合跨框架设计系统和生命周期较长的企业级 UI；另一些人则说，现代 JS 框架已经提供了更可复用、更可移植的组件。

Shadow DOM vs Light DOM

• Light DOM / “HTML web components” 因其声明式、可观察、并且易于渐进增强而受到赞赏（例如增强 <details> 或 <img>）。
• Shadow DOM 因其封装性和样式隔离而受到重视，但很多人抱怨它让样式、测试、可访问性以及组件之间的协调变得更复杂，并且会导致“未定义自定义元素闪现”。
• 也有人提到真实世界中的痛点：难以为嵌套子元素设置样式、工具支持较差，以及与 ARIA 和表单的交互脆弱。

SSR、性能，以及“在 JS 之前先渲染”

• 支持者声称它有一个独特优势：HTML web components 可以在任何 JS 运行之前先渲染出有用的回退内容。
• 反对者则指出，类似 React 的系统也可以 SSR 成 HTML，并与水合后的 UI 保持一致，而且初始用户体验往往比一个裸回退内容更好。
• web components 的 SSR 被认为还不成熟，尤其是在 Shadow DOM 和声明式 shadow DOM 的浏览器支持不完整的情况下。
• 争论的焦点在于：究竟什么更重要——感知到的渲染速度，还是可交互时间和整体 JS bundle 大小。

状态、路由，以及“开箱即用”

• 许多人指出，web components 是低层级的：它们并不能解决应用层问题；你必须自己添加模式或微型库。
• 一些人欢迎这种做法，尤其是在 MPA/服务器渲染应用中（可能再结合 htmx、Turbo 等）；另一些人则认为这是一种倒退，回到了“DOM 汤”式和 jQuery 风格的拼接。

开发者体验、采用情况，以及替代方案

• 有些人赞赏框架在 DX、可组合性以及清晰心智模型方面的优势（单一 render 函数 vs 生命周期回调）。
• 怀疑者则表示，“HTML web components” 大多只出现在演示中，而不是大型生产应用中；缺乏足够复杂、具有代表性的实例也被提出来讨论。
• 对于 web components 是“失败的标准”，还是一个会缓慢成熟并延续到当前 JS 框架之后的层，有不同看法。