模块化历史

在es6还未正式发布前，前端模块化，往往都是通过函数式编程实现的，那时候只能这样

function moduleA(){   // code here...

}

function moduleB(){   // code here...

}

  因为没有块级作用域的概念，

  因为没有块级作用域的概念，前端模拟块状作用域，需要用函数作用域实现，但是为此会产生很多全局变量，污染了命名空间，命名冲突的问题也随之产生，用命名空间实现模块化是一种较好的方案。系统愈加庞大复杂，本来的书写方式已经不能适应目前的开发。
  ***但是实现方式也是千差万别，于是有人提出了的前端模块化规范的概念，***

CommonJS

又有一些模块的概念涌现出来，比如源自服务器端js模块化的commonjs（一开始叫serverjs）；

CommonJS定义的模块分为: 模块引用(require) 模块输出(exports) 模块标识(module)
由于commonjs采用同步加载机制，拉取模块依赖的时候会停止页面渲染，于是AMD规范这样的异步加载规范又被提出来，require.js，node.js是其最火的两个实现，nodejs遵循了commonjs规范，但并没有完全的遵循。但是又有国人觉得AMD这种异步加载的方式不太完美，于是司徒正美提出了CMD概念并祭出了其实现sea.js。

直到2015年ES6正式发布，ECMAScript实现了原生的js模块化，import，export，块状作用域，是其十分常用的模块化的API，但并不是所有浏览器都实现了ES6的支持，由于业界毒瘤IE，尤其是ie8，ie9还占据着大部分市场份额，所以为了兼容ES6的新语法，还得引入第三方打包编译工具，比如babel，broswerify,html5-shim等向下兼容的方案。

基于nodejs的Grunt，gulp这样的自动化模块和打包工具应运而生，require.js这样的冷兵器，黯然隐退。
Webpack对上诉两个自动化模块和打包工具都不太满意，果断另起炉灶，获得了好评。
Gulp 的定位是 Task Runner, 就是用来跑一个一个任务的。放在以前比如我想用sass写css, coffee写js, 我必须手动的用相应的compiler去编译各自的文件，然后各自minify。这时候designer给你了两张新图片，好嘞，接着用自己的小工具手动去压缩图片。后来前端人不能忍了，搞出个自动化这个流程的 Grunt/Gulp, 比如你写完代码后要想发布production版本，用一句 gulp build
就可以
rm
掉 dist文件夹中以前的旧文件

自动把sass编译成css, coffee编译成js

压缩各自的文件，压缩图片，生成图片sprite

拷贝minified/uglified 文件到 dist 文件夹

但是它没发解决的是 js module 的问题，是你写代码时候如何组织代码结构的问题.
之前大家可以用 require.js, sea.js 来 require dependency, 后来出了一个 webpack 说 我们能不能把所有的文件(css, image, js) 都用 js 来 生成依赖，最后生成一个bundle呢？ 所以webpack 也叫做file bundler.
同时 webpack 为了解决可以 require 不同文件的需求引入了loader, 比如面对sass文件有
sass-loader, 把sass 转换成 css

css-loader, 让 webpack 能识别处理 css

style-loader, 把识别后的 css 插入到 html style中类似的识别es6 有babel-loader

本来这就是 webpack 的初衷，require everything, bundle everything. 一开始 webpack 刚出来的时候大家都是把它结合着 gulp 一起用的， gulp 里面有个 gulp-webpack，就是让 webpack 专门去做module dependency的事情, 生成一个bundle.js文件，然后再用 gulp 去做一些其他杂七杂八minify, uglify的事情。 后来人们发现 webpack 有个plugins的选项， 可以用来进一步处理经过loader 生成的bundle.js，于是有人写了对应的插件， 所以minify/uglify, 生成hash的工作也可以转移到webpack本身了，挤掉了gulp这部分的市场份额。 再后来大家有发现 npm/package.json 里面的scripts 原来好好用啊，调用任务的时候就直接写一个简单的命令，因为 gulp 也不就是各种插件命令的组合呀，大部分情况下越来越不需要 gulp/grunt 之类的了 ref. 所以你现在看到的很多新项目都是package.json里面scripts 写了一堆，外部只需要一个webpack就够了。
打个不恰当的比方，webpack就像微信一样，本来就是做聊天(module dependency)的，后来生生搞出一个微信小程序(processing files)，大家面对简单的需求发现这个比原生app方便使用啊，于是开发原生的人越来越少一样。
所以 LZ 一开始就模仿其他项目用 npm scripts + webpack 就好了，当你发现有哪些任务你没法用 webpack 或者npm scripts 解决起来麻烦， 这个时候再引入task runner 也不迟