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，无需借助自动化工具对模块进行各种处理，让工具的任务分的更加清晰。
