捆绑我的JS/TS项目反模式？

Question

我正在使用TypeScript在Angular 2中开展一个项目,并试图确定我的工作流程.

昨天,我看到Guy Bedford关于包裹管理的视频.在其中,他提到了他认为捆绑是反模式的事实.

我已经看到类似的提及远离捆绑角度大学指南.

从我观看视频后的内容来看,在我看来,捆绑反模式的原因是HTTP2允许每个请求多个响应,并行发送.这似乎非常有用,因为对您的服务器的单个请求可以返回单个文件中的整个角度应用程序.

HTTP2支持现在是否足以过渡到未捆绑的应用程序？优缺点都有什么？

编辑#2:试图使问题更集中

Answer 1

反模式是一个很强的术语。这也是一个有点模糊的问题：我们都对它的含义有这种直觉，但是很容易在争论有问题的实践 x 实际上是否是反模式的争论中迷失方向。

因此，我不想在图书馆作者的演讲中过多地解读即兴评论，而是想提出反对捆绑的案例。这些观点应该是相当没有争议的（如果有人不同意，请在评论中告诉我，我将进行编辑）。

在我们开始之前重要的警告：我捆绑。总的来说，我是捆绑的粉丝，这对我所做的工作来说非常有意义，而且通常来说这是向前迈出的一步。它有很多积极的方面，我最喜欢的是更好的闭包编译器/汇总压缩。但对于这个答案的其余部分，我只关注潜在的缺陷。

1. 捆绑可能会导致微不足道的缓存未命中。对应用程序任何部分的任何更改都会使浏览器缓存失效。

2. 捆绑会使利用公共库的缓存变得更加困难。如果您与其他人使用来自同一个 CDN 的相同版本的 jquery，那么您的用户很可能永远不需要访问您的服务器。

3. 捆绑意味着您通常会同时加载所有 JavaScript。也有一些例外情况，例如 webpack 代码分割，但这会使您的构建管道与处理文件变得复杂。

4. 捆绑意味着失去 HTTP/2 并行处理多个资源请求的能力。这可能与您的用例相关，也可能不相关。如果您正在 FooCorp 构建内部资产，而 IT 部门仍然将每个人锁定在 IE 8 上，那么这个论点就没有说服力。出于同样的原因，您的大多数客户群都是中国人。对于世界上大多数地区来说，HTTP/2 现已得到广泛支持（chrome、firefox、edge、iOS safari）。这意味着您为大多数用户提供了可能低于标准的体验。