将一个大的 JavaScript 文件拆分成多个小文件是否值得？ [关闭]答案

【问题标题】：Is it worth spliting up a large JavaScript file into many smaller one? [closed]将一个大的 JavaScript 文件拆分成多个小文件是否值得？ [关闭]
【发布时间】：2023-02-24 12:13:54
【问题描述】：

我目前正在开发一款游戏，我需要为在单个 HTML 页面上玩的游戏定义许多功能。目前，我已经在一个 JavaScript 文件上实现了所有功能，但是这个文件变得非常大，看起来既不“整洁”也不“易于阅读”。

我在想，也许我应该为一组函数分别创建一个文件。这解决了上述问题，但也意味着将加载更多的 js 文件，尽管网页引用的整体代码仍然相似。

我不确定第二种方法是否值得采用。做出决定时我需要考虑哪些因素以及这两个决定的后果是什么？

目前将所有 js 代码放在一个文件中。

【问题讨论】：

性能方面的收益可以忽略不计；在可维护性方面，代码将更加模块化，更易于维护，与不必要的东西分离并且整体上更好。
就个人而言，我使用像 OOP 这样的模块，人们遵循 SRP（单一职责原则）来编写类：每次我在代码中编写新功能时，我都会在一个单独的模块中进行，并使用一个非常具有描述性的名称（通常是动词，很少是动词）名词）。它更好，更有条理，而且在很短的时间内你将无法以不同的方式做到这一点。因为我通常不会为一个程序编写超过 10 个模块，所以我不介意打包，但如果你达到数百个，那么按照下面的答案建议做是个好主意。

标签： javascript performance module

【解决方案1】：

当有很多很多小脚本文件时要考虑的一个大问题是，如果您的 Web 服务器使用 HTTP 1.1，那么一次可以传输多少文件是有硬性限制的。如果文件很多，如果客户端的 ping 不佳，则应用程序可能需要很长时间才能完全加载。

（如果您的网络服务器使用 HTTP/2，则不存在此类限制；很多小文件都可以正常工作，并且可以与 <script type="module"> 结合使用。）

一种常见的方法是编写许多不同的来源文件的可读性，但使用像Webpack这样的构建系统来获取所有这些文件并将它们转换成一个更大的包（或几个）以供客户下载。无论您的服务器的网络协议如何，捆绑包都能很好地工作。此外，拥有一个构建过程（任何构建过程）无论如何对许多其他事情都有帮助，例如 Babel 将新语法转换为旧语法和缩小以减少需要传输的字节数。

【讨论】：