在我的理解中，良好分解和模块化代码的好处是可重用性和组织性。在一个文件中以大块编写的代码难以阅读，并且重复使用代码的一小部分需要仔细复制粘贴，而不是包含语句。
特别是关于 Javascript，我最近遇到了一个让我思考这个问题的例子。对 SO 进行了评论，大意是，如果您没有逐页有条件地包含您的 javascript，这“表示未能正确模块化 JS 代码”。但是，从代码重用和组织的角度来看，没有理由考虑在页面加载时会发生什么。如果将代码编写在一堆单独的文件中，然后在提供服务之前将其混合在一起并缩小，那么代码将同样具有可读性。例如，rails 资产管道就是这样做的。
当我第一次遇到资产管道时，我的思绪摇摇欲坠，我开始想知道“我如何让 javascripts 仅在需要时加载？” 我阅读了一些 SO questions和一篇关于此事的文章，并开始认为也许我不应该担心我的代码在“编译”后会发生什么。
编写模块化代码的目的是否纯粹是人类活动，我们是否应该在代码开始运行后停止担心模块化？在 Javascript 的情况下，我们是否应该担心我们的脚本在被包含之前被混合在一起？
我认为您在性能方面并没有真正谈论的一件事是实际的 HTML 浏览器下载行为。我相信您必须在仅逐页显示所需的 javascript 和利用浏览器缓存和下载行为之间走一条细线。
For example, say you have 20 different javascript snippets that are going to be used on every page. In this case it is a no-brainer to compile/minify them into a single file, as the fewer files your browser needs to download, the better. This single file would also be able to be cached, that is assuming it is a static file or appearing to be static (via headers sent) if it is dynamically compiled.
Now say of those 20 snippets, 15 are used on every page and the others are used intermittently. Of course you put all 15 of the always used snippets into a single file. But what about the others? In my opinion you need to consider the size and frequency of use of the files. If they are small and used relatively frequently, I might consider putting them into the main file, with the thought that the extra size in the main file is outweighed by the need to have additional request to download the content later. If the code is large, I would tend to only use it where necessary. Of course once it is used, it should remain in cache.
This approach might best be suited for a web application where users are expect to typically have multiple page loads per session. Of course if you are designing an advertising landing pages or seomthing where the user only may see that single page, you might lean on keeping the initial javasciprt download as small as possible and only loading new javascript in as necessary based on user interaction.
这个问题的每个方面都归结为“它取决于”。
您是否正在编写一个企业级应用程序，它会产生 80,000 行代码，而您将它们拼凑在一起？
如果是这样，那么是的，编译时间将会很长，如果你把它塞进<head>你的文档中，人们就会感觉到等待时间。
即使它已经被缓存，单独的编译时间也是显而易见的。
您是否正在编写数十个最终用户可能永远看不到的小部件？
尤其是手机？
如果是这样，那么您可能希望为他们节省下载/编译时间，而是加载您的核心功能，然后按需加载额外的功能，因为更多研究表明非技术最终用户期望他们的移动互联网体验类似于他们的桌面体验，不仅在内容方面，而且在一般等待时间方面。
越来越少的人愿意接受 5s-8s 的移动体验（或移动端的桌面体验）以达到交互的地步，只是基于“嗯，它是移动的，所以需要更长的时间”的火车想法。
再说一次，如果你有一个 80,000 行的应用程序，或者一个 300kB 的 JS 文件，或者在加载之前进行大量的 XML 解析等等，而不提供单独的移动体验，那么你在移动设备上的统计数据必然会伤害 - 特别是如果您是媒体网站或商业/零售网站。
所以对你的问题的正确答案是说你的问题没有正确的答案，除了有好主意和坏主意，基于目标设备、站点/应用程序的意图、人口统计、代码-base，预期用户将频繁访问该站点（并因此受益于缓存资产），更新代码库的频率（有一个更新的模块，有 20 个缓存的模块，而不是一个完全无效的 21 模块块，由于一条拥有 250,000 名客户的客户群的更新产品线出于多种原因考虑）...
...和更多...
弄清楚你在做什么。
弄清楚你需要做些什么来实现这一点。
弄清楚如何做到这一点，同时为您的客户提供良好的体验。
知道如何合并文件。
知道如何按需加载。
知道如何构建一个轻量级的引导程序，它可以智能地加载模块（和/或学习 require/AMD）。考虑到您要完成的工作，
使用这些工具为您的用户提供可能的最佳体验。