Web 组件究竟有何优势，我为何要采用？( 二 ) _Web

实际上，许多大企业往往并不在社交媒体平台如 Twitter、Reddit 等上积极推广 Web 组件或者提供相关教程。与此相对的是，社交媒体上却有大量技术达人在紧密跟踪 React 的每个小版本更新和其生态系统的新动态。这一现象的背后逻辑相当直接：大企业通常更注重内部沟通，而在公开场合相对低调；反观中小企业和自由职业者，他们则相对更活跃于社交媒体。因此，如果 Web 组件在企业内部获得了更高的接受度，单凭频繁浏览 Twitter 是难以察觉的。
那么，大型企业为何如此偏爱 Web 组件呢？首先，基于 Web 组件构建的设计系统具有跨环境的可运行性。在一个大型企业中，前端技术栈可能包括 React、Angular、Ember 以及静态 HTML，而这些都需要与企业的主题和品牌保持一致性。对于初创企业而言，进行大规模的代码重构或许是一种有益的尝试，但在企业层面，这样做并不现实。
因为企业通常维护着庞大的代码库，并且需要在更长的时间尺度上进行规划，这促使了其做出与众不同的技术决策。从我的观点来看，这正是企业更倾向于使用 Web 组件的根本原因：稳定性和可持续性。
考虑到常规的 React 代码库，你可能发现更新任何依赖项（例如 React Router、Redux 或 React 本身）会触发一系列破坏性变更，这要求你花费数周时间对代码进行重构。在这种环境下，即使一个细微的变更也可能激活 Hyrum 法则，影响数千个组件，甚至简单的小版本升级也需要数周的全面测试、验证和文档更新。在这个场景中，React 的小版本升级相当于一个复杂问题，而大版本升级则可能引发一场危机。

Hyrum 法则：如果一个 API 的实现细节发生了变化，可能会导致一些用户的程序出现问题，因为他们已经习惯了之前的行为。因此，API 的设计者和维护者需要考虑到用户的期望和依赖，尽量保持 API 的稳定性和兼容性。

相反，Web 平台的向后兼容性为稳定性提供了保障。举例来说，1996 年发布的 Space Jam 网站至今依然可运行。Web 组件强化了这种稳定性，对于那些不能频繁进行前端重写的企业来说，这是一个重要优势。
当你采用 Web 组件后，其功能和特性保持稳定，包括 Shadow DOM 的样式隔离等它所有的微妙之处也都是如此。你可以将代码逻辑委托给浏览器来执行，从而长期减少维护和验证的需求。事实上，这样做就相当于把维护的责任交给了 google、Apple 和 Mozilla 等浏览器厂商。
与 Web 平台的稳定性相符，企业通常也更加稳定、谨慎，并且注重规避风险。因此，可以理解为什么Web组件在企业界得到了如此广泛的应用和欢迎。
Web 组件的局限性
在讨论 Web 组件的优势的同时，我们也需要深入了解其不足。以下是 Web 组件的几个主要局限性：

服务端渲染（SSR）：当前在 Web 组件领域，服务端渲染仍然是一个悬而未决的问题。尽管存在如 Shadow DOM 这样的声明式解决方案，但这只解决了问题的一部分。至今尚无统一标准明确如何在服务器端渲染 Web 组件，导致各大框架在这方面的实践各异。例如，Lit SSR 尚处于“Lit 实验”的研发阶段。只有当未来服务器端能渲染多种 Web 组件框架，且确保这些框架能顺利集成和重新渲染，我才会认为这个问题解决了。然而，解决这个问题可能还需要数年的时间。
可访问性：在主文档中的 ARIA 属性可能无法轻易地引用或与 Shadow DOM 内部的元素进行交互，并且处理对话框和焦点也颇具复杂性。因此，如果你希望不损害可访问性，必须从设计之初就仔细规划你的组件结构。尽管有许多正在进行的工作试图解决这个问题，但必须承认，到了 2023 年，这方面仍面临很多挑战。

此外，还有其他一些问题，例如依赖问题（如依赖特定的框架、构建工具和测试运行器）、IE11 的遗留问题（这是一些开发者极力避免但无法摆脱的问题）以及开发者的平台疲劳（例如，“我已经熟练掌握了 React，不想再去学习其他新技术”）。对于这些问题，我能理解并非每个人都会觉得 Web 组件有吸引力。Web 是一个包罗万象的平台，各种应用和用途都能在此找到自己的位置，这也是它之所以令人赞叹的一方面。
【Web 组件究竟有何优势，我为何要采用？】总结
不论你是选择立即采用 Web 组件，还是选择观望，或是打算几年后再重新评估，届时网络标准和功能可能会更加完善。
我个人对 Web 组件持积极态度，但也明白这并非人人共识。我的目的并不是要过分强调其重要性，只是认为它是开发者工具集中的一个有用组成部分。关键在于如何最大化其优势，同时规避潜在不足。