何时使用 Requirejs 以及何时使用捆绑的 javascript？答案

【问题标题】：When to use Requirejs and when to use bundled javascript?何时使用 Requirejs 以及何时使用捆绑的 javascript？
【发布时间】：2012-08-27 07:18:53
【问题描述】：

对于网络人来说，这可能是一个愚蠢的问题。但我对此有点困惑。现在，我有一个应用程序，我在其中使用几个 Javascript 文件来执行不同的任务。现在，我正在使用 Javascript bundler 来合并和缩小所有文件。因此，在运行时将只有一个 app.min.js 文件。现在，Requirejs 用于在运行时加载模块或文件。所以，问题是如果我已经在一个文件中拥有所有东西，那么我需要 requirejs 吗？或者我可以使用 requirejs 和/或 bundler 的用例场景是什么？

如果需要任何进一步的细节，请告诉我。

【问题讨论】：

我不明白你为什么需要两者。你认为你会吗？
这是一个混乱。什么时候用什么？还是只需要选择一个？
除了延迟加载 javascripts 之外，Require 是否还具有依赖注入功能，从而消除了对全局变量的需求？在我看来，Require 在捆绑文件中仍然很有用。我错了吗？

标签： javascript requirejs servicestack

【解决方案1】：

通常你在开发过程中只在加载表单中使用 RequireJS。站点完成并准备好部署后，您可以缩小代码。这里的优点是 RequireJS 确切地知道您的依赖项是什么，因此可以轻松地以正确的顺序缩小代码。这是RequireJS website上的内容：

完成开发并希望为最终用户部署代码后，您可以使用优化器将 JavaScript 文件组合在一起并缩小它。在上面的例子中，它可以将 main.js 和 helper/util.js 合并到一个文件中并缩小结果。

【讨论】：

我知道这是一个旧线程，但我偶然发现了，因为我有类似的疑问。所以，一个后续问题，如果您不介意 - 如果我们最终将所有内容捆绑到一个文件中进行部署，那么我的整个应用程序将一次性加载，而不是零碎（按需）加载。这不是和 AMD 矛盾吗？
是的，从某种意义上说。但 AMD 更具理论性，因为 requirejs 也关注现实世界的性能问题。单独加载每个模块肯定更干净、更纯粹，但会花很长时间 :)
我也提出了这个问题，所以请参阅stackoverflow.com/questions/20515679/…。也许是这两种方法的中间点？

【解决方案2】：

这是许多精通 javascript 开发人员之间激烈争论的问题。许多其他语言都有一个“编译”阶段，在该阶段将整个程序捆绑起来进行部署（想到 JBoss 的 .WAR 文件）。来自更传统背景的程序员通常喜欢这种方法。

近年来，Javascript 的发展速度如此之快，以至于很难绘制出确切的最佳实践，但那些欣赏 Javascript 更多功能性质的人通常更喜欢模块加载方法（如 require.js 使用）。

我写了Frame.js，它的工作原理很像 require.js，所以我偏向于模块加载器方法。

要直接回答您的问题，是的，是其中之一。

大多数主张将脚本打包到单个文件中的人认为，它可以实现更多压缩，因此更高效。我相信在大多数情况下打包的效率优势可以忽略不计，因为：（1）模块加载时间分布在整个会话中，（2）单个模块可以压缩到几乎相同的百分比，（3）单个模块可以通过服务器和路由器分开，以及 (4) 仅在需要时加载脚本最终允许您为某些用户加载更少的代码，而总体上加载更多的代码。

从长远来看，如果您能看到动态脚本加载的优势，请使用它。如果没有，请将您的脚本捆绑到一个文件中。

【讨论】：

虽然我了解单独保存文件的好处，但我认为捆绑也减少了所需的 http 连接数。随着浏览器和服务器中的流水线变得越来越广泛可用，这可能不再那么重要，但它目前是一个相当大的问题。
如果应用很大，http 连接开销会迅速增加。对于我们的应用程序，当我们以解压模式运行它并单独加载每个 JS 文件时，加载页面大约需要 15-30 秒。在打包模式下大约需要一秒钟。
一个打包的缓存文件显然比获取数十个或数百个文件要快得多，您永远无法确定它们是否已加载，或者加载它们需要多长时间。因此，最好将所有内容都转储到客户端。在大多数情况下，这个单个文件无论如何都不会超过 1mb 大小，在被缩小和 gzip 压缩后可能会小得多。所以，单文件 FTW。
数千个强类型类和一个 .swf 文件，ftw。

【解决方案3】：

这取决于您的应用程序。如果您正在制作一个仅使用适度 javascript（小于 100kb 缩小）的服务器端应用程序，那么进行完全捆绑，您可能会没事的。

但是，如果您正在制作一个 javascript 应用程序并且其中包含大量代码，那么您的需求将会有所不同。

例如，在我的应用程序中，我捆绑了所有核心文件。有 jQuery、下划线、主干、我的主要应用程序文件、我的用户登录系统、我的布局系统、我的通知和聊天系统，所有这些都是我的初始大文件的一部分。

但我还有许多其他模块，它们不属于初始捆绑包的一部分，它们是在这些模块之后加载的。

论坛、wiki、所见即所得、颜色选择器、拖放、日历和一些动画文件属于第二类。您需要对哪些是常用的和立即需要的，哪些是可以延迟的，做出合理的决定。

如果我立即包含所有内容，我可以超过一兆 javascript，这将是疯狂的，并且会使初始启动速度慢得令人无法接受。

第二个类别在initSuccess 事件从初始文件触发后开始下载。

但第二类比第一类更智能，因为它首先加载更重要的内容。例如，如果您正在查看 wiki，它将在加载颜色选择器之前加载 wiki。

【讨论】：