为什么要编写模块化 javascript？ [关闭]答案

【问题标题】：Why write modular javascript? [closed]为什么要编写模块化 javascript？ [关闭]
【发布时间】：2013-03-29 22:33:14
【问题描述】：

在我看来，精心设计和模块化的代码的好处是可重用性和组织性。在一个文件中以大块编写的代码难以阅读，并且重复使用代码的一小部分需要仔细复制粘贴，而不是包含语句。

特别是关于 Javascript，我最近遇到了一个让我思考这个问题的例子。对 SO 进行了评论，大意是，如果您没有逐页有条件地包含您的 javascript，这“表示未能正确模块化 JS 代码”。但是，从代码重用和组织的角度来看，没有理由考虑页面加载时会发生什么。如果将代码编写在一堆单独的文件中，然后在提供服务之前将其混合在一起并缩小，那么代码将同样具有可读性。例如，rails asset pipeline 就是这样做的。

当我第一次遇到资产管道时，我脑子里一片混乱，我开始想“如何让 JavaScript 只在需要时才加载？”我阅读了a few SO questions 和an article on the matter，并开始认为也许我不应该担心我的代码“编译”后会发生什么。

编写模块化代码的目的纯粹是人类活动，我们是否应该在代码开始运行后停止担心模块化？对于 Javascript，我们是否应该担心我们的脚本在被包含之前被混合在一起？

【问题讨论】：

想象缩小就是编译。如果他们的模块化代码在编译后不是模块化的，那么任何开发人员曾经会关心吗？不，同样适用于 JavaScript。至于在需要时加载，这在很大程度上取决于您的用例。如果可能需要代码，则应加载它。如果不太可能需要，则仅在需要时才加载它可能会有好处。
@Dave 这就是我的想法，但似乎很多人认为我们应该逐页加载 javascripts（我从人们对 rails 的回答中收集到这一点）资产管道问题）。

标签： javascript ruby-on-rails-3 performance coding-style modularity

【解决方案1】：

我认为在性能方面您并没有真正谈论的一件事是实际的 HTML 浏览器下载行为。我相信您必须在仅逐页显示所需的 javascript 和利用浏览器缓存和下载行为之间走一条细线。

例如，假设您有 20 个不同的 javascript sn-ps 将在每个页面上使用。在这种情况下，将它们编译/压缩成一个文件是不费吹灰之力的，因为浏览器需要下载的文件越少越好。这个单个文件也可以被缓存，即假设它是一个静态文件，或者如果它是动态编译的，它看起来是静态的（通过发送的标头）。

现在说这 20 个 sn-ps，每个页面使用 15 个，而其他的则间歇使用。当然，您将所有 15 个经常使用的 sn-ps 放入一个文件中。但是其他人呢？在我看来，您需要考虑文件的大小和使用频率。如果它们很小并且使用相对频繁，我可能会考虑将它们放入主文件中，并认为主文件中的额外大小被稍后需要额外请求以下载内容的需要所抵消。如果代码很大，我倾向于只在必要时使用它。当然，一旦使用，它应该保留在缓存中。

这种方法可能最适合用户通常希望每个会话加载多个页面的 Web 应用程序。当然，如果您正在设计广告登陆页面或用户只能看到该单个页面的设计，您可能倾向于保持初始 javasciprt 下载尽可能小，并且仅根据用户交互在必要时加载新的 javascript。

【讨论】：

【解决方案2】：

这个问题的每个方面都归结为“取决于”。

您是否正在编写一个企业级应用程序，结果是 80,000 行代码，当您将所有代码拼凑在一起时？

如果是这样，那么是的，编译时间会很长，如果你把它塞进文档的<head>，人们就会感觉到等待时间。
即使它已经被缓存，单独的编译时间也是显而易见的。

您是否正在编写数十个最终用户可能永远看不到的小部件？
尤其是手机？

如果是这样，那么您可能希望为他们节省下载/编译时间，而是加载您的核心功能，然后按需加载额外的功能，因为更多研究表明非技术最终用户期望他们的移动互联网体验类似于他们的桌面体验，不仅在内容方面，而且在一般等待时间方面。

越来越少的人愿意接受 5s-8s 的移动体验（或移动端的桌面体验）以达到交互性，只是基于“嗯，它是移动的，所以需要更长的时间“ 思路。

同样，如果您有一个 80,000 行的应用程序，或者一个 300kB 的 JS 文件，或者在加载之前进行大量的 XML 解析等等，而不提供单独的移动体验，那么您在移动设备上的统计数据肯定会受到伤害 - 特别是如果您是媒体网站或商业/零售网站。

因此，您的问题的正确答案是说您的问题没有正确答案，除了有好主意和坏主意，具体取决于目标设备、网站/应用程序的意图、人口统计、代码库、用户将频繁访问该站点的预期（从而从缓存资产中受益）、代码库更新频率（有一个更新的模块，有 20 个缓存的模块，而完全无效的 21 个模块块，由于一条更新的产品线，拥有 250,000 名客户的客户群，出于多种原因考虑）...

...还有更多...

弄清楚你在做什么。
弄清楚您需要做什么才能实现这一目标。
弄清楚如何做到这一点，同时为您的客户提供良好的体验。

知道如何合并文件。
知道如何按需加载。
知道如何构建一个轻量级的引导程序，它可以智能地加载模块（和/或学习 require/AMD）。
将这些用作工具，根据您要完成的任务，为您的用户提供尽可能好的体验。

【讨论】：