前端模块化的意义

开发中明显可以感觉到加载一个HTML需要依赖很多的JS文件依赖，比如到一定阶段的HTML页面，尾部就是这样的：

<script src="/public/vendors/jquery/js/jquery.min.js"></script>
<script src="/public/vendors/popper.js/js/popper.min.js"></script>
<script src="/public/vendors/bootstrap/js/bootstrap.min.js"></script>
<script src="/public/vendors/pace-progress/js/pace.min.js"></script>
<script src="/public/vendors/perfect-scrollbar/js/perfect-scrollbar.min.js"></script>
<script src="/public/vendors/@coreui/coreui-pro/js/coreui.min.js"></script>
<script src="/public/vendors/moment/js/moment.min.js"></script>
<script src="/public/vendors/select2/js/select2.min.js"></script>
<script src="/public/vendors/bootstrap-daterangepicker/js/daterangepicker.js"></script> 
<script src="/public/js/src/jquery.twbsPagination.js"></script>
<script src="/public/js/src/HZRecorder.js"></script>

随着所需功能越来越多，我们就需引入更多的JS依赖和CSS依赖，有时还会面临着一个文件不够需要拆分成几个文件的情况。因此可能会遇到以下几点问题：

• 管理依赖会成为一个很费时的工作，很可能引入的文件顺序出现错误前端交互就不可以使用了。
• 当页面加载的时候所有依赖会被全部同步加载，这样也很难实现所有依赖按需加载的高级功能。
• 在团队协作开发中，出现管理全局变量，变量命名空间困难的问题。

而前端要使用模块化的原因或者要解决的问题就是：

• 解决命名冲突
• 管理依赖
• 提高代码的可复用性

相关模块化规范

常见的规范有 CMD、AMD、CommonJS 规范

• CMD规范（Common Module Definition）：是sea.js在推广过程中对模块定义的规范化产出，主要用于浏览器端。它主要特点是：对于依赖的模块是延迟执行，依赖可以就近书写，等到需要用这个依赖的时候再引入这个依赖。
• AMD规范（Asynchronous Module Definition）：是 RequireJS 在推广过程中对模块定义的规范化产出，也是主要用于浏览器端。其特点是：依赖前置，需要在定义时就写好需要的依赖，提前执行依赖。
• CommonJS规范是在服务器端模块的规范，是同步加载的，应用有node.js。

ES6 助推了前端模块化，import语法会被JavaScript引擎静态分析，这是一个很重要的功能，我们通常使用CommonJS时，代码都是在运行时加载的，而ES6是在编译时就引入模块代码，当然我们现在的浏览器还没有这么强大的功能，需要借助各类的编译工具（webpack）才能正确的姿势来使用ES6的模块化的功能。也正因为能够编译时就引入模块代码，所以使得静态分析就能够实现了。

ES6模块化的优点有

• 静态化编译。如果能够静态化，编译的时候就能确定模块的依赖关系，以及输出和输入的变量。CommonJS和AMD/CMD都只能在运行代码时才能确定这些关系。
• 不需要特殊的UMD模块化格式（Universal Module Definition（通用模块规范）是由社区想出来的一种整合了CommonJS和AMD两个模块定义规范的方法）。不再需要UMD模块的格式，将来服务器和浏览器都会支持ES6模块格式。目前各种工具库（webpack）其实已经做到这一点了。
• 目前的各类全局变量都可以模块化。比如navigator现在是全局变量，以后就可以模块化加载。这样就不再需要对象作为命名空间。

参考链接：javascript模块化之CommonJS、AMD、CMD、UMD、ES6