Web 组件究竟有何优势,我为何要采用?( 三 )


Web 组件和网络标准让一些细微的问题可以由浏览器自行处理,这点我非常喜欢 。组件如何组合、样式作用域如何限定、数据如何传递——这些问题可以放心交由浏览器解决 。这让我能够更专注于对终端用户确实重要的因素,如性能、可访问性和安全性 。
在网络开发领域,我常感到自己在与与业务目标无关的“附加复杂性”做斗争 。这可能包括管理 npm 依赖、调试状态管理器,或者解决测试运行器和代码检查工具的兼容性问题 。虽然有人可能觉得这些问题有趣,我也不时会陷其中,但这些最终只是低效的劳动,因为你的最终用户并不在乎你的打包器是否与你的 Type 转译器兼容 。
换句话说,在 2023 年,选择 Web 组件会带来一些附加的复杂性,如前面提到的 SSR 和可访问性问题 。在这些方面妥协可能会对你的最终用户造成实际上对他们很重要的伤害,所以这种权衡可能不值得你做 。我认为这种权衡通常是值得的,但同时也存在一些微妙的差异 。“专用 Web 组件来发挥其优点”虽然听起来不太吸引人,但在 2023 年,这仍是一个不错的选择 。
参考链接

  1. 《Web 组件究竟有何优势,我为何未采用?》:https://daverupert.com/2023/07/why-not-webcomponents/
  2. emoji-picker-element:https://Github.com/nolanlawson/emoji-picker-element/
  3. 复杂的单页应用(SPA):https://www.npmjs.com/package/emoji-picker-element?activeTab=dependents
  4. 支持 Web 组件:https://custom-elements-everywhere.com/
  5. 轻量级的适配代码:https://github.com/rstacruz/remount
  6. 更多地是基于直觉而非实证数据:https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/
  7. Cassondra Robert 在 CSS Day 上的精彩讲解:https://www.YouTube.com/watch?v=67bSCEEdaH8
  8. 根据某些统计数据:https://mastodon.social/@westbrook/110774427407999573
  9. 网页中的使用率约为 8%:https://almanac.httparchive.org/en/2022/JAVA
  10. 20%:https://chromestatus.com/metrics/feature/timeline/popularity/1689
  11. Hyrum 法则:https://www.hyrumslaw.com/
  12. 1996 年发布的 Space Jam 网站:https://www.spacejam.com/1996/
  13. 它所有的微妙之处:https://lamplightdev.com/blog/2019/03/26/why-is-my-web-component-inheriting-styles/
  14. 尚无统一标准:https://github.com/webcomponents-cg/community-protocols/issues/7
  15. Lit SSR:https://lit.dev/docs/ssr/overview/
  16. “Lit 实验”:https://lit.dev/docs/libraries/labs/
  17. 在主文档中的 ARIA 属性可能无法轻易地引用或与 Shadow DOM 内部的元素进行交互:https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/
  18. 对话框:https://nolanlawson.com/2022/06/14/dialogs-and-shadow-dom-can-we-make-it-accessible/
  19. 焦点:https://nolanlawson.com/2021/02/13/managing-focus-in-the-shadow-dom/
  20. 正在进行的工作:https://github.com/WICG/aom/pull/200
  21. 解决这个问题:https://github.com/WICG/aom/issues/199




推荐阅读