为什么要编写模块化的javascript ?

Why write modular javascript?

本文关键字：javascript 模块化为什么更新时间：2023-09-26

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

特别是关于Javascript，我最近遇到了一个让我思考这个问题的例子。SO上的一个评论是，如果你没有在页面的基础上有条件地包括你的javascript，这"代表了JS代码正确模块化的失败"。然而，从代码重用和组织的角度来看，没有理由考虑页面加载时发生了什么。如果将代码写在一堆单独的文件中，然后在提供服务之前将其混合在一起并缩小，那么代码将具有同样的可读性。例如，rails资产管道就是这样做的。

当我第一次遇到资产管道时，我的脑海里一片混乱，我开始想知道"我如何使javascript只在需要时加载?"我读了一些SO问题和一篇关于这个问题的文章，并开始认为也许我不应该担心代码"编译"后会发生什么。

如果编写模块化代码的目的纯粹是人类层面的活动，那么在代码开始运行之后，我们是否应该停止担心模块化?在Javascript的情况下，我们是否应该担心我们的脚本在被包含之前被混在一起?

我认为关于性能，你没有真正谈论的一件事是实际的HTML浏览器下载行为。我相信你必须在只显示每一页所需的javascript和利用浏览器缓存和下载行为之间走一条很好的线。

例如，假设您有20个不同的javascript片段将用于每个页面。在这种情况下，将它们编译/缩小到一个文件中是显而易见的，因为浏览器需要下载的文件越少越好。这个文件也可以被缓存，假设它是一个静态文件，或者看起来是静态的(通过发送的头)，如果它是动态编译的。

现在假设这20个片段中，15个在每个页面上使用，其他的断断续续地使用。当然，您可以将所有15个经常使用的代码片段放入一个文件中。但是其他人呢?在我看来，您需要考虑文件的大小和使用频率。如果它们很小并且使用相对频繁，我可能会考虑将它们放入主文件中，考虑到主文件中额外的大小会被稍后下载内容的额外请求所抵消。如果代码很大，我倾向于只在必要的地方使用它。当然，一旦它被使用，它应该留在缓存中。

这种方法可能最适合于用户每次会话通常有多个页面加载的web应用程序。当然，如果你正在设计一个广告登陆页面或用户可能只看到一个页面的东西，你可能会倾向于保持初始javascript下载尽可能小，只在必要时加载新的javascript基于用户交互。

这个问题的各个方面归结为"看情况而定"。

您是否正在编写一个企业级应用程序，当您将其全部塞在一起时，它会产生80,000行代码?

如果是这样，那么是的，编译时间将是巨大的，如果你把它塞在文档的<head>中，人们将会感受到等待时间。
即使它已经被缓存了，编译时间也是显而易见的。

你是否正在编写许多可能永远不会被最终用户看到的小部件?
尤其是在手机上?

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

越来越少的人愿意接受5 -8秒的移动体验(或移动端的桌面体验)来达到交互性，只是基于"好吧，它是移动的，所以它需要更长的时间"的思路。

所以，如果你有一个8万行的应用程序，或者一个300kB的JS文件，或者要做大量的XML解析，等等，在加载之前，没有提供单独的移动体验，你的移动统计数据肯定会受到伤害——特别是如果你是一个媒体网站或商业/零售网站。

正确答案到你的问题是说,你的问题没有正确答案,除了有好的想法和坏的思想,根据目标设备的目的站点/应用程序,人口,很快上手,期待用户频繁的网站(因此受益于缓存的资产),代码库的更新的频率(有一个更新的模块,用20缓存模块,而fully-invalid 21-module块,由于一个更新的行,

…和更多…

弄清楚你在做什么。
想想你需要做些什么来实现它。
弄清楚如何做到这一点，同时为你的客户提供良好的体验。

知道如何组合文件。
知道如何按需加载。
知道如何构建一个轻引导，它可以智能地加载模块(和/或学习需求/AMD)。
使用这些工具为您的用户提供最好的体验，考虑到您想要完成的任务。