在我的理解中，良好分解和模块化代码的好处是可重用性和组织性。编写在一个大块中的代码都在一个文件中很难阅读，并且重复使用代码的一小部分需要仔细复制粘贴，而不是包含语句。
特别是关于Javascript，我最近遇到了一个让我想到这个问题的例子。在SO上发表评论的意思是，如果你没有在逐页的基础上有条件地包括你的javascripts，这“代表了无法正确模块化JS代码”。但是，从代码重用和组织的角度来看，没有理由考虑页面加载时发生的情况。如果代码是在一堆单独的文件中编写，然后在服务之前将它们混合在一起并缩小，那么代码就是可读的。例如，rails asset pipeline就是这样做的。
当我第一次遇到资产管道时，我的脑海里浮现，我开始疑惑“如何在需要时才加载javascripts？”我阅读了a few SO questions和an article on the matter，并开始认为我可能不会担心代码“编译”后会发生什么。
编写模块化代码的目的是纯粹是人类级别的活动，我们是否应该在代码开始运行后不再担心模块化问题？在Javascript的情况下，我们是否应该担心我们的脚本在被包含之前被混合在一起？
答案 0 :(得分：2)
我认为你在性能方面没有真正谈论的一件事是实际的HTML浏览器下载行为。我相信你必须在逐页显示所需的javascript和利用浏览器缓存和下载行为之间走一条路。
例如，假设您有20个不同的javascript片段将在每个页面上使用。在这种情况下，将它们编译/缩小为单个文件是明智的，因为浏览器需要下载的文件越少越好。这个单个文件也可以被缓存，假设它是静态文件，或者如果是动态编译的话，看起来是静态的（通过标头发送）。
现在谈到这20个片段，每页都使用15个片段，其他片段间歇使用。当然，您将所有15个始终使用的片段放在一个文件中。但其他人呢？在我看来，你需要考虑文件使用的大小和频率。如果它们很小并且相对频繁地使用，我可能会考虑将它们放入主文件中，并认为主文件中的额外大小超过了以后需要下载内容的额外请求。如果代码很大，我倾向于只在必要时使用它。当然，一旦使用它，它应该保留在缓存中。
此方法可能最适合用户期望每个会话通常有多个页面加载的Web应用程序。当然，如果您正在设计广告目标网页或用户只能看到该单页的内容，您可能会依赖于尽可能小的初始javasciprt下载，并且只根据用户交互加载新的javascript。
答案 1 :(得分：0)
这个问题的每个方面都归结为“它取决于”。
您是在编写企业级应用程序，当您将所有代码整合在一起时会生成80,000行代码吗？
如果是这样，那么是的，编译时间将是巨大的，如果你在文档的<head>中填写，那么人们会感受到等待时间。
即使它已经被缓存，单独的编译时间也是显而易见的。
你在写几十个最终用户可能永远不会看到的小工具吗？ 特别是在手机上？
如果是这样，那么你可能想要保存它们的下载/编译时间，而是加载你的核心功能，然后按需加载额外的功能，因为越来越多的研究表明非技术最终用户期望他们的移动互联网体验与其桌面体验类似，不仅在内容方面，而且在一般等待时间方面。
越来越少的人愿意接受5s-8s的移动体验（或移动设备上的桌面体验）来达到互动点，仅仅基于“好吧，它是移动的，所以它需要更长的时间“ 思路。
再说一次，如果你有一个80,000行应用程序，或者一个300kB的JS文件，或者正在进行大量的XML解析，等等，在加载之前，没有提供单独的移动体验，你的移动统计数据一定会受到伤害 - 特别是如果你是一个媒体网站或商业/零售网站。
所以对你的问题的正确答案是说你的问题没有正确的答案，除了有好的想法和坏的想法，基于目标设备，网站/应用程序的意图，人口统计，代码库，用户将频繁访问站点的预期（从而受益于缓存资产），代码库更新的频率（具有一个更新的模块，具有20个缓存模块，而不是完全无效的21个模块块） ，由于一条更新的产品线，客户群为250,000个客户，因此有几个原因需要考虑... ...
......还有更多......
弄清楚你在做什么 弄清楚你需要做些什么来实现这一目标 弄清楚如何做到这一点，同时为您的客户提供良好的体验。
知道如何组合文件 知道如何按需加载 知道如何构建一个轻型引导程序，它可以智能地加载模块（和/或学习require / AMD） 根据 工具 ，将这些作为您想要实现的目标，为用户提供最佳体验。