资产中的脚本文件越少越好吗？

Question

鉴于：

• 资产管道相当复杂（来自 ASP.NET MVC，这 更复杂）： How do I associate a CoffeeScript file with a view?
• 所有 js 文件都将加载到每个页面上，并且每个“准备就绪” 每个文件中的jquery方法都会被执行

将应用程序的 javascript 分解为“区域”是否更有意义——一个 js 文件用于站点的用户/公共区域，一个文件用于站点的管理区域等等。来自外部站点（jquery，组织中的其他站点）的脚本不会真正适用。

我看到的好处是

• 性能：加载一个 80kb 文件比加载 4 个 20kb 文件要快得多，因为 TCP/IP 开销 (source)。在生产环境中，所有公共 js 将被编译到一个文件中并在每个请求中提供服务，但我认为在该文件中包含“管理”代码的缺点。

• 安全性：脚本文件中可能有一些我不想暴露给未经授权的用户的内容。诚然，如果它在脚本中它是不安全的，但如果我可以最大限度地减少诸如执行数据库维护的控制器操作的路径之类的事情的暴露，那就太好了。

• 开发中的简单性：如果 on-ready 事件将从每个文件中触发，那么将它放在一个文件中对我来说是有意义的，这样我就不必加载每个文件来查看里面有什么准备好的。子区域（如 admin）的 js 自然会在一个单独的文件中，该文件不会来自资产

相关：Put javascript in one .js file or break it out into multiple .js files?

Answer 1

从其他 javascript 中拆分管理 javascript 听起来是个好主意。

那篇性能文章绝对正确。我还没有看到在一个文件中缓存尽可能多的 javascript 并没有成为性能赢家的情况。即使这些区域不共享 javascript，一次下载一个较大的文件也往往比多次下载要快。

如果您有很多库和 1-off 页面特定的 javascript 文件，那么缓存所有库可能是有意义的，只需确保在测试时测量典型用户的缓存命中。

您可以使用一些模式来最小化负载问题。将事物拆分为模块并仅基于特征检测初始化这些模块对我来说是一种有效的方法。

例如，如果我有一个UserInfo 模块：

!function(ns) {
  ns.init = function() {
    ns.setup_login()
    ns.show_user_info()
  }
  ns.setup_login = function() { /* blah-blah */ }
  // ... etc
}.call(this, this.UserInfo={})

如果我在页面上有一些与登录相关的 html：

<div id="user_login">
  <div class="user_info"></div>
  <div class="login_links"></div>
</div>

我可以编写如下初始化器：

$(function() {
  $("#user_login").each(function() { UserInfo.init() })
})

如果没有这种模式，我会分别编写对setup_login 和show_user_info 的加载调用。通常这让我可以根据我在页面上检测到的方面来初始化几个不同的模块，如果你按照它们的依赖关系对这些模块进行分组，通常会进一步减少它。 （我可能已经完成了 User.init -> UserInfo.init，因为也许我可以假设 UserInfo 取决于 User。）