Web Components曾被忽视，但因框架疲劳和原生API优势正被重新发现。它们提供简洁、互操作性强，浏览器原生支持，适用于设计系统。开发者正重新认识其价值。
译自：Web Components Are the Comeback Nobody Saw Coming
作者：Alexander T. Williams
多年来，Web Components一直是Web开发领域角落里默默的天才——技术卓越、广泛支持却几乎完全被忽视。
每个人都忙着追逐当红框架，在抽象之上堆叠抽象，并将每个按钮都变成一个导入了半个互联网的React组件。
现在，随着对臃肿的打包文件和工具链混乱的厌倦逐渐加深，开发者们正在重新发现简洁的力量。突然之间，一度显得古朴的原生浏览器API，再次展现出未来的面貌。
Web Components为何最初未能普及
当Web Components首次出现时，它们理念正确，但时机不对。开发者们已经深陷于AngularJS、Backbone和一波承诺将开发者从意大利面条式代码中解救出来的框架之中。
使用自定义元素、Shadow DOM和HTML模板等原生API的想法显得优雅——但生态系统尚未成熟。早期采用者往往依赖使用专用主机来管理复杂的polyfill和依赖项，这进一步减缓了采用速度。
曾经拥抱复杂性的开发者，现在正在质疑它。
再加上框架的文化惯性，你将面临一场艰难的战斗。团队需要工具、生态系统和清晰的模式——而不是简陋的API。框架为他们提供了一应俱全的功能：状态管理、路由和社区插件。而Web Components，则感觉像一个DIY工具包。它们快速且原生，但缺乏开发者所期望的完善度。
然而，如今风水轮流转。曾经拥抱复杂性的开发者，现在正在质疑它。无休止依赖项带来的性能负担正促使团队回归原生解决方案——这正是Web Components大放异彩的地方。
框架疲劳症因素
框架不会消失，但它们的热潮正在消退。每一代框架都承诺更轻量的构建和更快的渲染，却随着时间的推移，积累了同样的臃肿。
Webpack配置日益庞大，转译器层出不穷，突然之间，你的开发环境有一半只是为了服务一个简单的UI。开发者们正在意识到，许多这样的开销所解决的问题，浏览器本身已经原生解决了。
Web Components完全避开了这一团乱麻。它们不需要React、Vue或Svelte来处理生命周期钩子或封装。浏览器本身已经完成了这些工作。Shadow DOM无需CSS-in-JS库即可隔离样式。自定义元素无需虚拟DOM差异算法即可处理响应性。结果是更精简、更快、更具可移植性的代码——并且它可以在任何运行JavaScript的地方工作。
这无关对过去简单时光的怀旧。它关乎实用主义。钟摆正在摆回，从重度抽象转向实用的可维护性。开发者希望一次构建，随处部署，而不是花一半时间调试构建管道。
互操作性：无声的杀手级特性
Web Components相对于框架的最大优势之一是它们不关心你身处哪个生态系统。一个Web Component在React应用、Vue应用或根本没有框架的环境中以相同的方式工作。在当今碎片化的前端格局中，这种中立性是一种超能力，因为团队经常在不同产品之间处理多个技术栈。
想象一下，你只需构建一次自定义日期选择器或图表，然后无需修改即可将其放入五个不同的代码库中。这不是理论——而是使用Web Components的实际现实。它们不仅连接框架；它们超越了框架。这种互操作性也与向微前端的转变完美契合，其中大型应用程序被分解成可独立部署的单元。
不再需要在不同技术栈之间重新实现相同的UI，或等待框架兼容层成熟。
对于组织而言，这意味着巨大的节省。不再需要在不同技术栈之间重新实现相同的UI，或等待框架兼容层成熟。对于开发者而言，这意味着自主性和灵活性——在现代前端开发中是一种罕见的组合。
浏览器终于跟上了
当Web Components首次出现时，浏览器支持参差不齐。开发者不得不依赖缓慢且脆弱的polyfill。如今，所有主流浏览器都原生支持它们——而且不是部分支持。API是稳定、标准化并针对性能进行了优化的。时机再好不过了。
与此同时，Web API本身也已发展。现代JavaScript提供了模块、模板字面量和异步模式，它们与自定义元素完美结合。曾经吓退开发者的痛点——例如样式、依赖管理和状态共享——现在都可以通过原生工具进行管理。甚至打包工具也已成熟到可以优雅地处理自定义元素。
这种成熟改变了一切。Web Components不再感觉像是实验性的。它们已准备好投入生产，Lit和Stencil等成熟的生态系统正在弥补其不足，同时保持轻量。结果是控制与便利之间的平衡，这是框架很少能达到的。
设计系统和原生UI的崛起
Web Components复兴背后的另一个隐形力量是设计系统的爆发式增长。企业已经意识到，产品之间的一致性并非可选项；它是一种品牌必需品。Web Components非常适合这项任务。它们提供封装性、可重用性和框架独立性——一个设计系统在不同团队和平台间扩展所需的一切。
Salesforce（使用Lightning Web Components）和微软（使用Fluent UI）等巨头已经押注于这种模式。甚至初创公司也在为内部库采用Web Components，因为它们简化了使用不同技术栈的开发者之间的协作。一个React开发者、一个Angular团队和一个由CMS驱动的营销网站都能毫无阻碍地使用相同的按钮组件。
Web Components作为原生组件，不受框架更迭的影响。
这不仅仅关乎一致性；它还关乎持久性。基于框架构建的设计系统其有效期与其依赖项紧密相连。Web Components作为原生组件，不受框架更迭的影响。随着网络的发展，它们也能优雅地演进。
开发者体验：下一个前沿
尽管Web Components拥有诸多优势，但仍面临认知挑战。它们被视为需要更多样板代码、开发者舒适度较低的底层工具。但这种情况正在迅速改变。Lit等库使组件的定义几乎和编写React hooks一样符合人体工程学。开发者工具、热重载和TypeScript支持都在逐月改进。
开发者体验的差距正在缩小，在某些情况下甚至正在逆转。使用Vite和Web Components设置项目只需几分钟而非几小时。无需状态管理库或CSS模块——一切都能通过原生API正常工作。
结论
每隔几年，前端世界就会重新发现旧事物并宣称其为新。但这一次，Web Components并非昙花一现——它们是一场清算。开发者正在重新审视复杂性的成本，并意识到网络的原生功能足以满足大多数现代应用的需求。
框架在大型应用程序和快速原型设计中仍将占有一席之地。然而，基线正在发生变化。随着性能预算收紧和架构债务越来越难以证明其合理性，Web Components精简、通用的特性感觉越来越正确。
网络不需要另一次革命——它只需记住它已知的一切。Web Components证明，我们一直期待的逆袭故事，其实早已深植于浏览器之中。
