乍一看，我对此感到失望。也许当我花更多时间使用 Web Components 后，我的想法会改变，但对我来说，HTML 导入是一个非常关键的特性。ES6 模块很棒，但据我所知，它们只打包 JS。能够打包一个 Web Components（模板和所有相关资源）并在没有进一步依赖关系的情况下分发它，不仅具有吸引力和便利性，而且也是使 Web Components 整体成功的关键因素。

我知道调和 ES6 模块和 HTML 导入可能是必要的步骤，但我希望 Mozilla 在经过一些考虑并与社区和其他供应商进行对话后，最终重新考虑实现 HTML 导入。

1. dima

   至少有一个 polyfill 可以实现它，为什么您需要它与浏览器一起发布？您认为它会快很多吗？我不这么认为。

   此外，Polymer 项目构建了一个名为“vulcanize”的工具，它将所有 HTML 部分粘合在一起：这将避免额外的网络请求，而网络请求实际上是您应该避免的。

   2014 年 12 月 15 日 下午 13:07
   1. laurentj

      一个 polyfill + 另一个 polyfill + 又一个 polyfill + …… 由于某些浏览器不支持某些技术，网站变得越来越臃肿。

      似乎一些 Web 开发者（和浏览器开发者）没有在现实生活中（例如，在大部分时间连接不良的情况下）对他们的网站进行移动测试。

      2014 年 12 月 15 日 下午 14:33

   2. Ivan

      有 jQuery，为什么您需要在浏览器中添加像 querySelector 这样的“原生函数”？

      我们可以永远使用 IE6 + jQuery！哇……

      jQuery > ALL

      /讽刺…

      2014 年 12 月 16 日 下午 04:21

   3. Erik isaksen

      关于 vulcanize — 我理解的是，一旦我们都使用 http2，拼接就不像现在这样必要了。从这个角度来看，vulcanize 是目前一个临时但必要的解决方案。也许我遗漏了什么，但这就是我的看法。ES6 模块与导入有截然不同的目的，因为它们只打包 JS。可移植性是 Web Components 的一项非常重要的功能。

      2014 年 12 月 17 日 上午 02:11

   4. Adam

      据我所知，polyfill 无法像原生 HTML 导入一样并行下载 Web Components。这就是为什么它们应该原生实现的原因。

      2014 年 12 月 18 日 下午 15:44

2. Erik Isaksen

   我同意 HTML 导入非常有吸引力。尽管有一些相似之处，但它与 JS 模块有截然不同的目的。

   2014 年 12 月 17 日 上午 02:06

您好！

我非常高兴看到 Mozilla 正在考虑继续推进 Web Components。

我同意 HTML 导入不是严格的要求 — 它可以通过各种其他技术来实现，尽管可能不会是那么大的事情。

我希望看到 Mozilla 发布原生 Shadow DOM — 遵循 Chrome 的做法将会对其他供应商产生影响。对相关样式问题的进展将非常受欢迎。

谈到我自己在标准化机构（尤其是 W3C）的经验，我希望开发团队能够大胆地遵循自己的意见，即使并非所有事情都在标准中得到解决。我发现起草和实现您自己的解决方案并将它们作为工作示例带回工作组的效果更好。我认为这种方法对标准化流程的影响往往比争论文字更大。

由于Html Imports是Web组件的核心部分，我认为你应该实现它。我同意也许可以稍等一下，直到事情得到更好地理解，比如es6模块加载器和html导入交互的关系。html导入的去重部分需要一些工作，因为这让我担心每个Web组件都有10个相同库捆绑包的副本，而且因为它们来自不同的URL，所以它们不会被去重。

所以，是的，我们需要将依赖项管理与 JavaScript 和 HTML 的良好解决方案相协调。Polymer 项目严重依赖 html 导入，因为它是一个 Web 组件规范，因此应该实现它，但这并不意味着你不能建议更改规范。

要点是，一旦规范最终确定，你应该遵守它。由于浏览器制造商无法达成一致，不得不处理不同的代码真的很糟糕。

请让我们网页开发者更容易一些，并尝试从代码角度使每个浏览器都相同。请不要进行浏览器大战，不要说这是更好的，我就不打算实现这个功能，让我们达成一致。是的，这对你们来说是工作，但影响很大，与必须在你的平台上进行开发的大量网页开发者相比，你们浏览器开发者很少！所以请为我们着想！

很高兴看到 Mozilla 最终将 Web 组件发布到 Firefox。但我仍然不认为这篇文章中提到的不发布 HTML 导入的理由能够站得住脚。是的，许多功能都有 polyfill。但让使用 Polyfill 的开发人员不应该成为浏览器开发者的首选。

虽然 HTML 导入不是创建组件的必需条件，但 es6 模块从未打算做导入所做的事情。

我认为你会发现，将对这样一项功能的支持碎片化只会鼓励“包管理器战争”继续下去，我们在编译时有太多笨拙的 polyfill 方式。

导入的关键在于它们提供了一种简便的方式来打包你的元素并分发它，而无需额外的依赖项。

Es6 模块可以做到这一点，但我们作为一个社区，真的希望库和框架在它的基础上构建自己的包装器吗？Es6 是为 JS 制定的——它不应该被“硬塞”到注入 CSS 和 HTML 中

1. Anne van Kesteren

   最终，我们希望得到一些标准化的东西。我们目前不做 HTML 导入的原因是，我们认为如果它能从 JavaScript 模块、服务工作者以及将 HTTP/2 的部分暴露给 JavaScript 中获得的信息，它的设计会大不相同。

   我们希望设计能够反过来进行。我们向 Web 开发人员提供基本组件，然后他们在其基础上设计各种引人注目的库和框架。然后我们可以看看如何标准化一些更高层次的东西，以提高性能并减轻一些使用库的负担。

   2014年12月17日 上午08:52
   1. Laurentj

      > 以及将 HTTP/2 的部分暴露给 JavaScript。

      所以你想等很多年，才能看看 html 导入是否可以，或者是否应该改进？因为，说真的，HTTP/2 很棒，但它将需要很多年才能被数百万个 Web 服务器的大多数支持。因此，大多数项目无法使用依赖于 HTTP/2 的库或功能。

      > 然后我们可以看看如何标准化

      好的，你想看到 Web 开发人员尝试这些新的基本组件来验证它们。但你不想看到开发人员尝试 HTML 导入（从我的角度来看，它是一个“基本”功能）。:-/

      对不起，我不同意你的观点。

      我不喜欢 Web 技术采用的方式：年复一年，我们失去了声明式编程，转而使用命令式编程，而在某些情况下，声明式优于命令式。如果 Tim Barners-Lee 发明的是一种 JS 而不是 HTML，那么 Web 就不会存在。用 HTML/CSS 理解和编写网页比用命令式语言容易得多……

      2014年12月18日 上午02:29
      1. 布莱恩C

         > 好的，你想看到 Web 开发人员尝试这些新的基本组件来验证它们。但你不想看到开发人员尝试 HTML 导入

         啊，但文章中并没有说明这种情绪。这句话“缺乏 HTML 导入不是问题，因为如果需要，可以通过 polyfill 轻松提供该功能”清楚地表明 Mozilla 并不阻止（原谅这个双重否定）其他人尝试 HTML 导入。整个声明式/命令式 + Tim Berners Lee 的论点不幸地是一个稻草人论点，因为它与我们现在讨论的主题关系不大。这篇文章从未主张使用基于 JS 的命令式替代 HTML 导入，也没有主张 es6 模块作为替代方案（注意，es6 模块语法是声明式的）。文章也没有说明 Mozilla 将“等很多年”来分析 HTML 导入的状态。事实上，所有引入的功能都在明年的时间范围内，所以 Firefox 仍然有可能拥有 HTML 导入，如果 Web 标准机构能够找到某种方法来协调 es6 和自定义元素与模块系统之间的关系。

         说到这一点，这里有一个问题：es6 模块和 HTML 导入如何交互？目前，这个问题还没有明确的共识，但如果 HTML5 不想彻底崩溃，那么双方之间必须相互理解。据我所知，HTML5 导入使用与 es6 模块完全不同的机制，这意味着它们无法与 System 模块加载器交互。至少，这对导入包括模块提出了问题。如果模块加载器无法与 HTML 导入互操作，你将如何处理？目前，没有浏览器厂商有明确的答案。尽管 Google 支持 Polymer（与流行观点相反，Polymer 不是 Web 组件的参考实现）和 es6 模块，但 Google 也没有任何关于如何处理 JS 模块和 HTML 导入之间二元性的显著策略。

         ……现在我已经写了一堆语无伦次的胡言乱语。虽然我同意 Mozilla 等公司应该努力为开发人员提供新的 Web 基本组件进行试验，但当考虑到该功能对浏览器中的模块的影响时，推迟 HTML 导入的决定似乎是合理的。

         2014年12月18日 下午12:08

      2. Anne van Kesteren

         也许如果 HTML 导入提供了一种真正声明式的组件创作方式，你就有道理了，但可惜的是，它们没有。无论哪种方式都需要脚本。

         2014年12月19日 上午02:27

   2. Adam

      “…它的设计会大不相同，如果它能从 JavaScript 模块、服务工作者以及将 HTTP/2 的部分暴露给 JavaScript 中获得的信息”

      对不起，我不明白这种胡言乱语。你能用简单的术语描述一下原因吗？

      2014年12月18日 下午15:50
      1. 泰勒

         如果你想 *最终* 看到一些标准化的东西并作为解决方案提供，那么你需要改变你博客文章中的措辞，因为现在听起来你是在说你正在接球回家，WRT HTML 导入。

         同时，考虑将你不确定的这些功能添加为 -moz- 前缀，以便 Web 社区可以通过实践来决定应该如何做。

         2014年12月29日 上午08:33

是什么实际问题阻止 Mozilla 启用该标准？文章中的引述（“…我们对标准流程的反馈并不总是能产生所需的改变……”）没有说明——你能帮助我们理解标准存在的问题吗？

你能具体说明应该使用哪些 JavaScript 模块来代替 Web 导入（这是 JavaScript 代码模块吗？），它们如何解决你对 W3C 标准的担忧，以及我们何时可以预期它们被实现？这个过程正在通过标准化过程吗？有链接吗？

谢谢。

@Brett Zamir – 感谢你的评论 - 这些文档已由 MDN 团队更新。最好的，Havi

Mozilla，

不要做混蛋，不要实现 Html Imports，它可是 Web Component 标准的重要组成部分，它可能会出现问题吗？是的，Es6 模块加载器和 Html Imports 如何协同工作可能会让人困惑吗？是的。

那又怎样，Html Imports 是 Web Components 的关键部分，而不得不使用 polyfill 简直太糟了！!!!!!!!。遵循标准并实现它。事物总是在变化，在未来的某个日期，当我们弄清楚 Html Imports 和 Es6 如何更好地协同工作，或者其中一个能否取代另一个时，再实现那个。

不要因为没有得到你想要的结果就做那个混蛋/女孩，我们都同意 Html Import 标准有改进的空间，你的观点是有效的，但你还是需要实现它！!!!!!!!

不实现它，你就从一开始就束缚了整个 Web Components 标准，不要做混蛋！！

1. Anne van Kesteren

   为了非常清楚起见，“Web Components”还不是一个标准，目前只有 Google 正在发布某种实现（甚至没有完全符合规范）。因此，对“Web Components”成为标准的过程进行输入非常合适。你在网络上没有太多机会做对某些事情。

   2015年1月5日 00:56
   1. dan

      我理解要把它做好，但这正是 Web 标准一直很杂乱无章的主要原因之一。我们最终会形成自己对什么正确、良好和完美的理解，最终我们只是做自己的实现，对 IE、Safari、Chrome、Firefox 等等来说，实现都是不同的。我认为这是我们需要改变的一件事，让我们追求完美，但也要接受一些不那么完美的东西，一些足够好的东西，但至少要跨浏览器有一个标准。对不起，话可能有点过分，但至少从我的角度来看，我原本计划 Mozilla 在 Web Components 上跟随 Chrome，因为 2 个主要浏览器制造商，有助于推动其他制造商效仿，现在其他制造商更容易不实现 Web Components。我想我只是厌倦了浏览器大战，你们实现这个，我们实现那个，没有人站在中间，而 Web 开发人员却要忍受这种折磨，不得不去处理那些填补空白的数百万个不同的 js、html、css 库。这只是让我想起了当年我为什么一开始就使用 Firefox，当时 IE 是那些从不遵守标准的人，而 Firefox 站出来说我们会遵守标准，并将 IE 看作是制造问题的那些人。

      无论如何，我一直都很喜欢 FF，而且一直都在使用它，我是从 Netscape 时代开始就一直都是早期采用者，尽管我现在没有在使用它。

      我确实意识到 Web Components 还没有成为标准，但它也像 Es6 一样，受到了广泛的关注，Es6 还没有成为标准，但看起来大多数浏览器都会实现，但这也是另一个问题，需要 5 年或更长时间才能制定一个标准，时间太长了。让每个人都同意很难，我理解。但如果我们能够让网络继续向前发展，并且在标准上达成一致，那就太好了。

      对不起，我抱怨了！

      2015年1月5日 07:09

嗨 @Anne van Kesteren，你能评论一下我遇到的这个 HTML Exports 库吗

https://github.com/nevir/html-exports

在另一个页面上，作者说

“ES6 模块 HTML 导入互操作性有点奇怪，是的。但它们在概念上非常相似，让它们和谐相处并不需要太多……”

你能评论一下他的断言是否有道理吗？

其次，你说

“…它的设计会大不相同，如果它能从 JavaScript 模块、服务工作者以及将 HTTP/2 的部分暴露给 JavaScript 中获得的信息”

你能提供一个更具体的例子，说明你认为它实际上可能是什么样子，只是一个例子。例如，你是否在谈论像 jspm.io 这样的项目，它允许使用 ES6 语法开发多资产库，而且 @Guy Bedford 甚至证明可以使用它来开发 Web Components？

编辑说明：感谢大家提出问题和深思熟虑的评论和回复。对话将继续在 public-webapps 标准列表 (http://lists.w3.org/Archives/Public/public-webapps/) 上进行。现在这篇文章的评论已关闭。