前端模块化的意义

前端小白的修炼 2019-11-04

开发中明显可以感觉到加载一个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

相关推荐