我正在使用TypeScript在Angular 2中开展一个项目,并尝试确定我的工作流程。
昨天,我看到盖伊贝德福德关于包装管理的this video。在其中,他提到了他认为捆绑是反模式的事实。
我已经看到过类似的提法,即不再捆绑angular-university guide。
从观看视频后我读过的内容来看,捆绑反模式的原因是HTTP2 allows multiple responses per request并行发送。这似乎非常有用,因为对您的服务器的单个请求可以在单个文件中返回整个角度应用程序。
HTTP2支持现在是否足以过渡到未捆绑的应用程序?有什么优点和缺点?
编辑#2:试图让问题更集中
答案 0 :(得分:2)
反模式是一个强有力的术语。它也有点模糊:我们都有这种直观的意义,但在争论是否有问题的实践x是否存在,实际上是反模式时,它很容易迷失。 p>
因此,我不想在图书馆作者的谈话中过多地阅读一篇副评论,而是想提出反对捆绑的案例。这些观点应该是相当无可争议的(如果有人不同意,请在评论中告诉我,我会编辑)。
我们开始之前的重要警告:我捆绑了。我是一般捆绑的粉丝,它对我的工作非常有意义,而且通常是向前迈进了一步。它有许多积极的方面,我最喜欢的是更好的闭包编译器/汇总压缩。但对于这个答案的其余部分,我只是在谈论潜在的缺陷。
捆绑可能导致琐碎的缓存未命中。对应用程序任何部分的任何更改都会使浏览器缓存失效。
捆绑可能会使利用公共库的缓存变得更加困难。如果您使用与其他人相同的cdn使用相同版本的jquery,那么您的用户很可能永远不会为您的服务器点击它。
捆绑意味着您通常会一次性加载所有JavaScript。有一些例外,例如webpack代码拆分,但这会使您的构建管道与处理文件相比变得复杂。
捆绑意味着错过了HTTP / 2并行处理多个资产请求的能力。这可能与您的用例有关,也可能与您的用例无关。如果你在FooCorp建立一个内部资产,每个人仍然被IT锁定到IE 8,因为这个论点的原因是没有用的。由于同样的原因,您的大部分客户都是中国人。对于世界上大多数,HTTP / 2现在是widely supported(chrome,firefox,edge,iOS safari)。这意味着您为用户的多数提供了可能低于标准的体验。