第4章 模块演义与Require.js

JavaScript最初并没有提供模块化规范，可能连它的设计者都没有指望让它承担过重的任务，但随着前端的发展，JavaScript逐渐承担起完整应用的开发工作，这必然会带来模块划分和管理的需求。JavaScript社区出现了很多模块化解决方案，这让许多非专业前端开发者感到很混乱。旧的模块化解决方案都是利用JavaScript自身的特性模拟出来的，它们无一例外都有着奇怪的语法，且无法在浏览器环境中直接使用，更别提社区里先后出现的CMD、AMD、UMD等多种模块化方案，想要分清楚真的很难。好不容易等到ES6标准提出解决方案，却又在工程实践中因为种种问题而未能统一实行，如果你查看过webpack的打包产物，就会发现其中内置了一个实现了CommonJS规范的简易加载器，它可使打包产物运行在浏览器中，而开发过程中使用ES Module的语法（指通过import关键字来引入模块，export关键字来导出模块）仅仅是为了方便理解，对应的模块会在webpack打包的过程中被转换为CommonJS模块。直到2021年，基于ES Module的构建工具才开始在开发环境中崭露头角，它借助跨语言的优势将构建速度提升了几十倍，不过要在生产环境中稳定使用还需要一些时间。目前，许多前端工程师对于模块化的认知仅仅是“打包工具会处理好它们的”。

要想掌握模块化的知识，需要明确的一个最重要的原则就是：“即使没有模块化，业务逻辑代码也是能正常运行的”。在不同的模块化标准中，我们用不同的外层代码结构包裹着自己编写的业务逻辑代码，相信你也曾有过这样的疑惑，明明是代码在承载着业务逻辑，即使不用外层代码结构来包裹，它也依然可以正常运行，模块化相关的代码并没有增加任何业务逻辑，为什么还要画蛇添足呢？你的疑惑是有道理的，但模块化规范的出现，本身就是软件工程的一种诉求，它的目的是提高工程层面的可维护性，并不会直接面向业务逻辑场景。本章就从前端开发领域最初面临的问题开始，来看看对模块化的诉求是如何产生的，再分别讲述各种模块化标准是如何处理这些诉求的，Require.js是AMD模块化规范的实现，本章的最后将以它为例讲解包模块管理工具的用法和原理。