CommonJs与AMD
在一开始,先讲一下它和以往所用的模块管理工具有什么不一样。在最开始的阶段,Js并没有这些模块机制,各种Js到处飞,得不到有效妥善的管理。后来前端圈开始制定规范,最耳熟能详的是CommonJs和AMD。
CommonJs是应用在NodeJs,是一种同步的模块机制。它的写法大致如下:
var firstModule = require("firstModule");
//your code...
module.export = anotherModule
AMD的应用场景则是浏览器,异步加载的模块机制。require.js的写法大致如下:
define(['firstModule'], function(module){
//your code...
return anotherModule
})
其实单比较写法,就知道CommonJs是更为优秀的。它是一种同步的写法,对Human友好,而且代码也不会繁琐臃肿。但更重要的原因是, 随着npm成为主流的JavaScript组件发布平台,越来越多的前端项目也依赖于npm上的项目,或者自身就会发布到npm平台。 所以对如何可以使用npm包中的模块是一大需求。所以browserify工具就出现了,它支持直接使用 require() 的同步语法去加载npm模块。
当然这里不得不说的是,ES2015(ES6)里也有了自己的模块机制,也就是说ES6的模块机制是官方规定的,通过 babel (一种6to5的编译器)可以使用比较多的新特性了,包括提到的模块机制,而它的写法大致如下:
import {someModule} from "someModule";
// your codes...
export anotherModule;
当然上面的写法只是最基本的,还有其他的不同加载模块的写法,可以看一下阮一峰老师的 ECMAScript 6 入门 或者babel的相关文档 Learn ES2015 。
功能特性
browserify的出现非常棒,但webpack更胜一筹!
来看看webpack支持哪些功能特性:
支持CommonJs和AMD模块,意思也就是基本可以无痛迁移旧项目。
支持模块加载器和插件机制,可对模块灵活定制。特别是最爱的babel-loader,有效支持ES6。
可以通过配置,打包成多个文件。有效利用浏览器的缓存功能提升性能。
将样式文件和图片等静态资源也可视为模块进行打包。配合loader加载器,可以支持sass,less等CSS预处理器。
内置有source map,即使打包在一起依旧方便调试。
看完上面这些,可以想象它就是一个前端工具,可以进行各种模块加载,预处理后,再打包。之前对这些的处理是放在grunt或gulp等前端自动化工具中。有了webpack,无需借助自动化工具对模块进行各种处理,让工具的任务分的更加清晰。