浅谈JS前端模块化的几种规范

前言

有这样一个场景，客户端运行很久，但是法务部和数据部需要收集用户的一些信息，这些信息收集好之后需要进行相应的数据处理，之后上报到服务端。客户端提供一个纯粹的js执行引擎，不需要 webview 容器。ios 端有成熟的javascriptcore、android 可以使用 v8 引擎。这样一个引擎配套有一个 sdk，访问 native 的基础能力和数据运算能力，可以看成是一个阉割版的 hybrid sdk 额外增加了一些数据处理能力。

问题结束了吗？处理逻辑的时候还需要用到2个库：cheerio和sql。因为都是 node 工程，所以纯粹的js环境是没办法直接执行。所以需求就进行了转变 ———— 将 node 项目打包成 umd 规范。这样就可以在纯粹的 js 环境下运行。接下来的文章就分析下各种规范。其实也就是前端模块化的几种规范。

前端模块化开发的价值

随着互联网的飞速发展，前端开发越来越复杂。本文将从实际项目中遇到的问题出发，讲述模块化能解决哪些问题，以及以 sea.js 为例讲解如何进行前端的模块化开发。

恼人的命名冲突

我们从一个简单的习惯出发。我做项目时，常常会将一些通用的、底层的功能抽象出来，独立成一个个函数，比如

并像模像样的将这些代码抽取出来并统一到util.js中，在需要使用的地方引入该文件，看起来很棒，团队内的同事很感激我提供了这么便利的工具包。

直到团队越来越大，开始有人抱怨

小杨：我定义了一个 each 方法遍历对象，但是 util.js 中已经存在一个 each 方法，每次都需要改方法名，我只能叫 eachobject 方法。<br>张三：我定义了一个 log 方法，可是王武的代码出问题了，谁来看看？

抱怨越来越多，最后参照 java 的方式，引入命名空间解决问题。于是 util.js 代码变成了

可能看上去的代码很 low，其实命名空间在前端领域的布道者是 yahoo！的 yui2 项目，看看下面的代码，是 yahoo！的一个开源项目

通过命名空间虽然可以极大的解决冲突问题，但是每次在调用一个方法时都需要写一大堆命名空间相关的代码，剥夺了编码乐趣。

另一种方式是一个自执行函数来实现。

繁琐的文件依赖

继续上述场景，很多情况下都需要开发 ui 层通用组件，这样项目组就不需要重复造*。其中有一个高频使用的组件就是 dialog.js

虽然公共组做项目都会编写使用文档、发送邮件告知全员（项目地址、使用方式等），但是还是有人问「为什么 dialog.js 有问题」，最后排查的结果基本都是没有引入 util.js

命名冲突和文件依赖是前端开发中2个经典问题，经过开发者不断的思考和研究，诞生了模块化的解决方案，以 cmd 为例

通过 exports 就可以向外提供接口， dialog.js 代码变成

使用的时候可以通过require('./util.js')获取到 util.js 中通过 exports 暴露的接口。 require 的方式在其他很多语言中都有解决方案：include、

模块化的好处

1.模块的版本管理：通过别名等配置，配合构建工具，可以轻松实现模块的版本管理

2.提高可维护性： 模块化可以实现每个文件的职责单一，非常有利于代码的维护。

3.前端性能优化： 对于前端开发来说，异步加载模块对于页面性能非常有益。

4.跨环境共享模块： cmd 模块定义规范与 nodejs 的模块规范非常相近，所以通过 sea.js 的 nodejs 版本，可以方便的实现模块的跨服务器和浏览器共享。

commonjs 规范

commonjs 是服务器端模块的规范。nodejs 采用了这个规范。commonjs 加载模块是同步的，所以只有加载完成后才能执行后面的操作。

因为服务器的特点，加载的模块文件一般都存在在本地硬盘，所以加载起来比较快，不用考虑异步的方式。

commonjs 模块化的饿规范中，每个文件都是一个模块，拥有独立的作用域、变量、以及方法等，对其他模块不可见。 commonjs 规范规定，每个模块内部，module变量表示当前模块，它是一个对象，它的exports属性是对外的接口，加载某个模块，其实是加载该模块的 module.exports 属性，require 方法用于加载模块。

commonjs 与 es6 模块的差异

1.commonjs 模块输出的是值的拷贝，es6 模块输出的是值的引用

2.commonjs 模块是运行时加载，es6 模块是编译时输出接口

commonjs 模块导出的是一个对象（module.exports 属性），该对象只在脚本运行完才会生成。

es6 的模块机制是 js 引擎对脚本进行静态分析的时候，遇到模块加载命令 import，就会生成一个只读引用，等到脚本真正执行时，再根据这个只读引用到被加载的模块中取值，

amd 规范

amd（asynchronous module definition） 是在 require.js 推广的过程中对模块定义的规范化产出。amd 推崇依赖前置。它是 commonjs 模块化规范的超集，作用在浏览器上。它的特点是异步，利用了浏览器的并发能力，让模块的依赖阻塞变少。

amd 的 api

id 是模块的名字，是可选参数。 dependencies 指定了该模块所依赖的模块列表，是一个数组，也是可选参数。每个依赖的模块的输出都将作为参数依次传入 factory 中。

amd 规范允许输出模块兼容 commonjs 规范，这时 define 方法如下

优点： 适合在浏览器环境中加载模块，可以实现并行加载多个模块

缺点： 提高了开发成本，并不能按需加载，而是提前加载所有的依赖

cmd 规范

cmd 是 sea.js 推广的过程中对模块定义的规范化产出。cmd 推崇依赖就近。

cmd 规范尽量保持简单，并与 commonjs 规范中的 module 保持兼容，通过 cmd 规范编写的模块，可以在 nodejs 中运行。

cmd 模块定义规范

cmd 中 require 依赖的描述用数组，则是异步加载，如果是单个依赖使用字符串，则是同步加载。

amd 是 requirejs 在推广过程中对模块定义的规范化产出，cmd是seajs 在推广过程中被广泛认知。seajs 出自国内蚂蚁金服玉伯。二者的区别，玉伯在12年如是说：

requirejs 和 seajs 都是很不错的模块加载器，两者区别如下：

• 两者定位有差异。requirejs 想成为浏览器端的模块加载器，同时也想成为 rhino / node 等环境的模块加载器。seajs 则专注于 web 浏览器端，同时通过 node 扩展的方式可以很方便跑在 node 服务器端
• 两者遵循的标准有差异。requirejs 遵循的是 amd（异步模块定义）规范，seajs 遵循的是 cmd （通用模块定义）规范。规范的不同，导致了两者api 的不同。seajs 更简洁优雅，更贴近 commonjs modules/1.1 和 node modules 规范。
• 两者社区理念有差异。requirejs 在尝试让第三方类库修改自身来支持 requirejs，目前只有少数社区采纳。seajs 不强推，而采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
• 两者代码质量有差异。requirejs 是没有明显的 bug，seajs 是明显没有 bug。
• 两者对调试等的支持有差异。seajs 通过插件，可以实现 fiddler 中自动映射的功能，还可以实现自动 combo 等功能，非常方便便捷。requirejs无这方面的支持。
• 两者的插件机制有差异。requirejs 采取的是在源码中预留接口的形式，源码中留有为插件而写的代码。seajs 采取的插件机制则与 node 的方式一致开放自身，让插件开发者可直接访问或修改，从而非常灵活，可以实现各种类型的插件。

umd 规范

umd（universal module definition）是随着大前端的趋势产生，希望提供一个前后端跨平台的解决方案（支持 amd、cmd、commonjs 模块方式）。

实现原理：

1.先判断是否支持 node.js 模块格式（exports 是否存在），存在则使用 node.js 模块格式

2.再判断是否支持 amd 模块格式（define 是否存在），存在则使用 amd 模块格式

3.前2个都不存在则将模块公开到全局（window 或 global）

可能有些人就要问了，为什么在上面的判断中写了 amd，怎么没有 cmd？因为前端构建工具webpack不可识别 cmd 规范，使用 cmd 就需要引用工具，比如 sea.js

讲道理，如果想判断 cmd，那 umd 代码如何写？

回到正题

cheerio 如何打包到普通的 js 执行环境中。

借助webpack可以方便的打出一个 umd 规范的包。

总结

手机端（无论 ios 还是 android）的底层渲染内核都是类 chrome v8 引擎。v8 引擎在执行 js 代码时，是将代码先以 macroassembler 汇编库在内存中先编译成机器码再送往 cpu 执行的，并不是像其它 js 引擎那样解析一行执行一行。所以，静态加载的 es6 模块规范，更有助于 v8 引擎发挥价值。而运行时加载的 commonjs、amd、cmd 规范等，均不利于 v8 引擎施展拳脚。

在 nodejs 开发项目中，node9 已经支持 es6语法，完全可以使用 es6 模块规范。nodejs 的诞生，本身就基于 google 的 v8 引擎，没有理由不考虑发挥 v8 的最大潜能。

在浏览器 js 开发项目中，因为从服务器加载文件需要时间，使用 commonjs 规范肯定是不合适了。至于是使用原生的 es 模块规范，还是使用 sea.js，要看具体场景。如果想页面尽快加载，sea.js 适合；如果是单页面网站，适合使用原生的 es6 模块规范。还有一点，浏览器并非只有 chrome 一家，对于没有使用 v8 引擎的浏览器，使用 es6 原生规范的优势就又减少了一点。

以上就是浅谈js前端模块化的几种规范的详细内容，更多关于js前端模块化的资料请关注其它相关文章！