javascript - 有效组织和服务 JavaScript 的最佳实践是什么

Question

我有兴趣听取有关如何在可能会出现高流量的大型 Web 应用程序项目中有效地组织 JavaScript(和 jQuery)的意见。

我关心的事情是:

• 在服务器上保持高效
• 在浏览器上高效
• 保持代码库可管理

假设所有编写的 JavaScript 都保存在一个巨大的 application.js 文件中，该文件又与所有外部库连接成一个服务器必须提供的 js 文件。这在服务器上应该是最有效的，因为它只需要提供一次服务，然后浏览器将为每个后续页面加载缓存它。

其中包含许多与选择器 Hook 的自定义 jQuery 函数，如下所示:

$('#my_unique_selector').bellsAndWhistlesPlugin();

上面的选择器只出现在几个页面上，使用将所有内容都打包在一起的方法意味着浏览器加载的每个页面都必须解析插件代码(不会被使用)，并且然后解释 bellsAndWhiSTLesPlugin() 方法，即使选择器没有找到匹配项。

所以我想我的问题是，这种方法在什么时候变得低效？是否有关于拆分 JavaScript 并仅提供每个页面所需的位的争论？还是我什么都不担心 - 浏览器完全有能力处理大量冗余代码？

Answer 1

绝对不应该做的事情是将所有 JavaScript 连接到一个文件中。如果您对代码库进行了更改，则会重新创建该文件……并重新分发给每个访问者。 HTTP 开销相当微不足道，因此除非您要加载成百上千个唯一文件，否则加载 20 个不同的文件与加载 1 个大文件不会显示出太大差异，除非用户连接速度特别慢(他们将等待大文件文件，因此他们不会从 HTTP 开销中注意到额外的一两秒)。

ToonMariner 关于使用托管代码(特别是 Google Code 存储库)的建议是一个很好的建议 - 它使您不必托管文件，它允许遇到该文件的用户利用缓存(提高明显的加载速度您的网站)，如果您进行更改，它不会包含在您的串联文件中。即使您选择在一个大文件中维护整个应用程序，您也应该考虑使用它，因为您可以避免打包 jQuery，这样可以节省 50+kb。

此外，您对解释 bellsAndWhiSTLesPlugin() 的担忧是正确的 - bellsAndWhiSTLesPlugin 函数中的 this 只是一个空列表(尽管我希望插件执行 $(this).each 调用遍历元素并尽早返回，因为没有元素……否则，您可能需要重新访问您的插件!)。您可以通过从完整的 application.js 文件中删除特定于页面的代码并将其放入页面本身的内联 <script> 元素中来消除此问题，无论如何它都属于该元素，或者重写插件以使其在有没有匹配的元素。

只需确保为从/js 目录加载的资源启用缓存，您就不会在重新加载库时遇到问题 - 只有那些已更改的库。您可以使用 Expires header 或 Last-modified header ；除非用户重新加载或缓存已过期，否则 Expires 不一定会强制更新，并且 Last-modified 会为每个文件调用 HTTP 开销，这对于大量文件来说是有问题的。您必须评估您的应用程序的权衡。

如果您真的对最大效率非常感兴趣，您可以使用 GWT 重写您的应用程序.这在技术上保证了最大的跨浏览器可移植性、最大的代码效率、消除了对 jQuery 库的依赖、执行速度更快，并产生更小的文件大小。一切都在一个文件中，我可能会补充说，但是为了获得静态编译器以实现最高效率的 JavaScript 的权衡是值得的......如果你愿意在 GWT 中重写整个东西。

您必须问自己的问题是:谁是我的普通用户？他/她有什么样的联系？我的应用程序需要在移动设备上运行吗？如果您的普通用户拥有快速连接，请不要担心 - 无论您选择哪种方式，他们都会足够快地加载您的页面。如果您需要在移动设备上工作，或者您的目标受众的连接速度较慢，请考虑缓存您很少更改的大型库并在可用的情况下使用外部存储库(例如 jQuery)，然后将应用程序的其余部分打包到一个大文件中.移动设备和慢速互联网的 HTTP 开销足以保证这样做。