我已经看到它在 http/2 的解释中随便提到，捆绑 JS 文件之类的技术将不再是必需的，并且是绕过 http 1.1 限制的反模式。
仔细想想，似乎问题并没有因为存在服务器推送而变得容易得多。现在我们有像 webpack 这样的工具，它构建了require()s 或 ES6的依赖图，import然后将它们组合成一个文件。好消息是这会生成一个可以从 CDN 提供的静态文件。
在 http/2 中，您仍然需要构建图的初始步骤，以便您知道服务器推送到客户端的内容。如果您在服务器上动态执行此操作，则无法从 CDN 提供服务。您可以在构建时解析 js 图并将它们全部作为脚本标签放在 index.html 的底部，并且网络服务器可以知道服务器推送这些资源（尽管我认为您需要某种浏览器支持来整合那与requires 在代码中？）。但是，如果您的 html 不是由 CDN 提供的，那将无法正常工作。而且由于您在任何页面加载时都传递了每个文件，因此与单个捆绑包相比，这似乎没有什么好处。我想你可以为不同的关键路线构建其中的一些，但这与在 webpack 中构建多个包没有什么不同，你如何转换到应用程序的另一个可能尚未下载的部分？
最重要的是，您很可能仍然有一个静态资源构建步骤，例如最新 js 功能的浏览器兼容性、sass 类型 css 编译、以@1x 和@2x 分辨率保存图标等. 所以，当前的 webpack 风格的编译 js 包的方法似乎还有很多其他的好处，而且目前还不清楚 http/2 server-push 如何真正帮助它。
我错过了什么？通过 http/2 server-push 为 js 提供服务还有其他我没有想到的好处吗？关于在 http/2 上提供 js 应用程序的计划，是否有人提供专家资源或流行 Web 框架的资源链接？