每次在任何文章或评论中提到一组Web组件标准时，都会发生几乎相同的事情：通常对所涉风险不甚了解的人们开始分享“专家”意见。 每次，讨论都滑入一个相同的场景，其名称与“ rook”一词押韵。 我非常希望积极，建设性地过渡到实际应用问题。 在本文中，我将尝试立即回答绝大多数典型问题，并驳斥最多的常见误解。 随后，在困难的情况下，将有可能以一个链接开始。 所以走吧
基础知识
Web组件是由以下基本元素组成的一组现代规范：
自定义元素 -创建具有指定行为，外观和您自己的内部标记的HTML标记的本机功能。
影子DOM-组件内部结构的分离，封装了内部样式和文档的其余部分。
模板 -一个特殊的标签，允许您存储标记片段，应用它们并在必要时重复使用。
HTML导入 -导入其他HTML文件中存储的HTML块的功能
以上所有内容均可通过本机CSS变量，本机ES模块和HTTP / 2服务器推送进行调味。 还有插槽，自定义属性，自定义事件和其他详细信息。 稍后，当我们继续练习时，介绍一下他们。
是的，您的这些Web组件几乎在任何地方都不受支持。
空号是工程师最好的朋友。 让我们从这个角度看“几乎无处”：
自定义元素 -78.71％
暗影DOM -79.12％
模板 -89.61％
HTML导入 -69.16％
如我们所见，以上技术适用于绝大多数用户的浏览器。 HTML导入会稍微破坏图片，但我们没有义务使用全套工具（我更喜欢使用本机ES模块将所有内容分解为方便的块），即使是单独使用，您也可以在此列表中找到很多“美味”的东西。
我强烈建议不要盲目相信我，而要遵循提供的链接。 例如，在此处，您可以看到这些规范的当前状态，以及自
版本63开始 ，自定义元素和Shadow DOM
已在Firefox中获得完全支持的事实。 当大多数狐狸用户升级到此版本时，这一刻指日可待，整体人数将变得更加诱人。 此外，您可能已经注意到Safari中“自定义元素”和“影子DOM”的“不完全支持”。 苹果浏览器不允许您从内置本机浏览器元素（例如按钮，选择等）继承组件。 使用Shadow DOM时，Safari在CSS选择器中也有一些细微差别。 在实践中，很可能忍受它而不会感到悲伤。 显然，按照传统，Microsoft Edge在现代浏览器中是局外人。 开发人员声称正在实施支持。 我们在等
那么，其余20％的用户该怎么做？
多文件可以用来支持这些人。 是的，它对多聚体的工作会稍微慢一些，但是肉眼看不到。 但对于其他所有人-将会更快。
我们五年前曾尝试做一个关于Polymer的项目。 一切都非常缓慢。
在那些“遥远”的时代，标准（v0）的草稿日趋猖,，仅在Chrome中实现了对它的支持。 从那时起，情况发生了很大的变化：采用了该标准的新版本v1，在各种浏览器中实现了本机支持，重写了多义字，并且良好的实践一直持续到解决。 Polymer本身已经从技术预览演变为一个可以正常使用的解决方案，这很不错。
一些聚合物……这是怎么回事？
Polymer是用于创建Web组件的库。 它支持我们在使用流行的前端框架时所惯用的所有“糖”：动态数据绑定，用于数组的转发器等。目前，第三个稳定版本已经发布。这个图书馆。 在Chrome开发人员的积极参与下进行开发。 生态系统由Google维护。
开发商的胡须总长度为...何时使用网络组件？
如果需要UI组件的通用共享库。 生活中的一个案例：一个项目，其中主应用程序是用React编写的，后台是用Angular编写的。 我想要代码库的相同性和各种重用。 Web组件
在不同的生态系统中感觉很好。
如果您接近浏览器中的设计方法 。 您可以创建而无需不断地重建应用程序，而无需不必要的依赖关系。 这使原型设计成为一种非常令人愉悦的体验，并使您的应用程序可以从原型状态平稳地发展到生产版本状态。 我喜欢那个
如果您喜欢旧的OOP ，请执行以下操作：通过从HTML元素继承来创建类，在其中实现所需的功能和包子，然后从中继承专用组件的类。 现在您有了自己的微框架。 美女！
如果您讨厌BEM ：Shadow DOM会隔离组件样式。 无需多层怪异的命名，也无需导航到通用CSS堆中的声明。 一切都紧凑地封装在一个组件中：样式，布局，逻辑。
如果您正在开发基于Electron的应用程序。 当前版本的Electron中的Chromium已经支持您所需的一切。 尽管版本普遍滞后。
如果要编写框架/库。 Web组件是此类实验的极佳组成基础。
如果您需要一种混合方法：您可以使用
SPA元素实现经典的网页 ：自定义标记可以与任何服务器模板引擎一起使用，它们可以只是常规标记的一部分，并在适当的时候确定您的目的。 您可以在服务器上呈现的内容与客户端上可以显示的内容之间保持微妙的平衡。
如果您的用户使用现代浏览器。 本身。
如果您正在开发PWA ：主要的移动平台支持开箱即用的所有功能。 为了快速
入门 ，有一个
pwa-starter-kit 。
如果您对提高应用程序安全性感兴趣，那么详细的依赖项审核将对您不利。 这里的一切都很简单：更少的依赖关系-更少的不受控制的漏洞。
如果您是狂热的优化人员并且喜欢使用DOM API ：Web组件是DOM API的一部分，具有普通DOM元素的所有标准功能。
如果您热衷于破坏库版本的向后兼容性 ：当所有内容都基于硬核标准时，它以某种方式更加可靠。
什么时候不应该使用Web组件
当您的项目有需求时，就需要支持旧版本的浏览器。 在这种情况下，您通常不会被羡慕。 吊con
当您开发具有较短生命周期的简单产品时，无需开发单个代码库。当您主要处理遗留代码时。当您和您的同事只使用一些时髦的东西而又不想了解其他任何东西时。为什么我需要所有这些？ 我有React / Vue / Angular /等，对我来说足够了...
然后，JavaScript在流行的库和框架中所做的大部分工作都可以转移到较低级别的浏览器实现中。 为了速度起见，减少了过多的依赖关系，减少了对依赖关系的依赖。 为了好。