把Webpack放在历史情景下能更好的理解它。这能让你知道它实现了多么强大的功能。过去，把一些脚本组合到一起就足够了。如今时代变了，现在分发你的JavaScript代码是一个复杂的过程。
这个问题随着单页应用的增加而升级。他们依靠很多沉重的库。最后你想做的是一次性加载它们。这是一个好主意，Webpack能与这些解决方案一起工作。
随着Node.js和[npm](https://www.npmjs.com/)的流行，Node.js的包管理工具，提供了更多的上下文。在npm之前，管理依赖是很困难的。现在npm在前端开发很流行，管理依赖的解决方案已经改变。现在我有许多棒棒哒的方式来管理我们项目的依赖。
历史告诉我们有许多的构建系统，[Make](https://en.wikipedia.org/wiki/Make_%28software%29)也许是最出名的一个，而且任然是一个可行方案。在前端的世界[Grunt](http://gruntjs.com/)和[Gulp](http://gulpjs.com/)已经特别的流行了。通过npm实现的插件机制使它们都很强大。
[Browserify](http://browserify.org/)领先了一步。它基于npm打包提供了非常强大的功能。你可以用很多小工具补充它。这是与Webpack的实现是一个很好的对比.
[JSPM](http://jspm.io/)走在了前面，它推动了包管理直接到了浏览器。它建立在[System.js](https://github.com/systemjs/systemjs)之上，System.js是一个动态的模块加载器。不像Browserify和Webpack，它跳过了在开发阶段把代码打包到一起的步骤。然而你也可以产生一个生产环境的包来使用它。Glen Maddern在它的[关于JSPM的视频](https://www.youtube.com/watch?t=33&v=iukBMY4apvI)里有详细讲述。
##Make
你可以说Make让你回到了童年时代。它首次发布时1977年。尽管它是一个老工具，但却很有意义。Make允许你写一些单独的任务来达到不同的目的。在下面的例子中，你将有几个单独的任务来创建一个生产环境构建，压缩你的JavaScript和运行测试。你可以在许多其他工具里看到同样的主意。
虽然Make通常在C项目里使用，但它没有被束缚在里面。James Coglan有关于[如何在JavaScript使用Make](https://blog.jcoglan.com/2014/02/05/building-javascript-projects-with-make/)的详细讲解.思考一些下面由James提供的简短代码。
```
PATH := node_modules/.bin:$(PATH)
SHELL := /bin/bash
source_files := $(wildcard lib/*.coffee)
build_files := $(source_files:%.coffee=build/%.js)
app_bundle := build/app.js
spec_coffee := $(wildcard spec/*.coffee)
spec_js := $(spec_coffee:%.coffee=build/%.js)
libraries := vendor/jquery.js
.PHONY: all clean test
all: $(app_bundle)
build/%.js: %.coffee
coffee -co $(dir $@) $<
$(app_bundle): $(libraries) $(build_files)
uglifyjs -cmo $@ $^
test: $(app_bundle) $(spec_js)
phantomjs phantom.js
clean:
rm -rf build
```
使用Make来需要使用Make的特殊语法和终端命令来构建任务。这可方式可以很容易和Webpack一起工作。
##Grunt
Grunt在Gulp之前是主流构建工具。它的插件构架促使了它占领的市场。同时这也是它致命的弱点。从经验来看，你不希望维护一个300多行的`Gruntfile`。下面是一个[Grunt文档](http://gruntjs.com/sample-gruntfile)里的一个例子。
```
module.exports = function(grunt) {
grunt.initConfig({
jshint: {
files: ['Gruntfile.js', 'src/**/*.js', 'test/**/*.js'],
options: {
globals: {
jQuery: true
}
}
},
watch: {
files: ['<%= jshint.files %>'],
tasks: ['jshint']
}
});
grunt.loadNpmTasks('grunt-contrib-jshint');
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.registerTask('default', ['jshint']);
};
```
在这个列子中，我们定义了两个和*jshint*有关的任务。jshint是一个代码规范工具，帮助你发现源代码里可能存在的语法和使用不规范问题。我们有一个独立运行jshint的任务，同时又有一个监视任务。当我们运行Grunt时，在我们编辑和保存源代码时就能实时看到警告信息。
在实践中，你可能为了各种各样的目的需要很多小的任务。比如打包一个项目。这个列子向我们展示了任务是如何构建的。Grunt非常重要的一点是为我们隐藏了很多细节。当走的太远时会是一个问题。很难明白这些配置下到底发生了什么。
*提醒：grunt-webpack插件允许你在Grunt环境中使用Webpack。你可以把这个重任交给Webpack。*
##Gulp
Gulp使用了不同实现方式。用真正的代码替代了对每个插件的配置。Gulp构建在可靠和管道之上。如果你熟悉Unix，这是相同的思想。你会很熟悉数据源，过滤器，水槽(sinks)。
文件就是数据源，过滤器在数据源上执行操作(比如转换JavaScript)，最后结果被送到水槽(比如，你的发布目录)。这里有一个`Gulpfile`让你对这种实现更多认识，这个文件来着这个项目的README。下面删减了部分。
```
var gulp = require('gulp');
var coffee = require('gulp-coffee');
var concat = require('gulp-concat');
var uglify = require('gulp-uglify');
var sourcemaps = require('gulp-sourcemaps');
var del = require('del');
var paths = {
scripts: ['client/js/**/*.coffee', '!client/external/**/*.coffee']
};
// Not all tasks need to use streams
// A gulpfile is just another node program and you can use all packages available on npm
gulp.task('clean', function(cb) {
// You can use multiple globbing patterns as you would with `gulp.src`
del(['build'], cb);
});
gulp.task('scripts', ['clean'], function() {
// Minify and copy all JavaScript (except vendor scripts)
// with sourcemaps all the way down
return gulp.src(paths.scripts)
.pipe(sourcemaps.init())
.pipe(coffee())
.pipe(uglify())
.pipe(concat('all.min.js'))
.pipe(sourcemaps.write())
.pipe(gulp.dest('build/js'));
});
// Rerun the task when a file changes
gulp.task('watch', function() {
gulp.watch(paths.scripts, ['scripts']);
});
// The default task (called when you run `gulp` from cli)
gulp.task('default', ['watch', 'scripts']);
```
配置文件全变成代码了，当你遇到问题时，你可以马上修改(hack)它。你可以包装现成的Node.js模块作为Gulp插件。和Grunt对比，你比较明白这到底发生了什么。不过你任然需要为临时的任务写很多样板代码，这也就是为什么新的工具会出现。
[gulp-webpack](https://www.npmjs.com/package/gulp-webpack)能让你在Gulp环境中使用Webpack
##Browserify
处理JavaScript的模块一直以来都是一个问题。知道ES6，这门语言都没有模块的概览。因此在90年代进入浏览器环境时，我们就卡主了。很多解决方案被提出来，包括[AMD](http://requirejs.org/docs/whyamd.html)
在实践中，使用CommonJS是很实用的。它是Node.js的格式，采用同步加载的方式。它的优点时可以利用npm而不必重复造轮子。
[Browserify](http://browserify.org/)解决了这个问题，它提供了把CommonJS打包到一起的方法。你可以把它和Gulp集成。这里有一些小的转换工具能让你超越基本的使用，比如[watchify](https://www.npmjs.com/package/watchify)提供了一个文件监听器，能够在你开发期间进行打包。毫无疑问，这回节省一些努力，并在某种程度上这是一个不错的方案。
Browserify的生态系统由许许多多的小模块组成。在这方面，它始终坚持Unix的哲学。Browserify比Webpack更易用，选择使用它也是非常好的。
##Webpack
你可能会说Webpack（或者webpack）比起Browerify实现的更集成一些。你获得了更多的开箱即用。Webpack扩展了`require`，允许你使用加载器自定义它的行为。你可以通过这个机制加载任意的内容。也适用于css文件(`@import`)。Webpack为任务也提供了插件，比如压缩，本地化，热加载等等。
这一切都基于配置。这里有一个例子，改编自[Webpack的官方文档](http://webpack.github.io/docs/tutorials/getting-started/)。
###webpack.config.js
```
var webpack = require('webpack');
module.exports = {
entry: './entry.js',
output: {
path: __dirname,
filename: 'bundle.js'
},
module: {
loaders: [
{
test: /\.css$/,
loaders: ['style', 'css']
}
]
},
plugins: [
new webpack.optimize.UglifyJsPlugin()
]
};
```
上面的配置是使用JavaScript写的，且具有很好的扩展性。只要是JavaScript，Webpack就能很好的和它在一起。
有时，配置文件会使Webpack看起来有一些不透明。很难理解其中发生了什么。在复杂的项目中尤其明显。我和Christian Alfoni 完成了[Webpack手册](https://christianalfoni.github.io/react-webpack-cookbook/)，里面对具体的问题有更详细的描述。
#JSPM
使用JSPM会与前面介绍的工具不同。它自带了一些命令行工具来安装新包到项目里，和创建线上压缩包等。它支持[System plugins](https://github.com/systemjs/systemjs#plugins),能允许在你的项目里加载各种格式的js包。
鉴于JSPM是一个年轻的项目，它肯定有很多坑现在。如果你是一个冒险者，值得去试一试。就像你现在知道的那样，在前端开发里工具更新的很快JSPM就是一个有价值的竞争者。
#为什么使用Webpack?
为什么你会使用Webpack代替Gulp或者Grunt?这不是非此即彼的问题。Webpack不仅处理打包的困难问题，还处理其他很多问题。我选择Webpack是因为它支持模块热替换(HMR)。这是react-hot-loader使用的特性。我将在后续像你展示。
你或许已经对LiveReload或者Browsersync很熟悉。当你做出改变时这些工具自动刷新浏览器。HMR把这个事情更进了一步。在React的案例中，它允许应用保存自己的状态。这听起来简单，但是在实践中却大不一样。
抛开HMR这个特性。Webpack的打包能力是很广泛的。它允许你使用各种方法分开打包。你可以在你的应用执行时动态加载。这个延时加载很方便，特别是面对大型程序时。你可以在你需要时才加载依赖。
使用Webpack你可以很容易给包的名字加上hash。这能让你在客服端改变时将起失效。在理想情况下包分割能让客服端仅仅重新加载很小一部分代码。
用其他工具也能完成这些任务，问题是肯定需要做很多工作。在Webpack里主要的就是配置。记住你可以通过livereactload使用HMR，所以这个特性不是只有Webpack才有。
通过集成这些小的特性。Webpack能让你惊讶并完成很多事情。如果你觉得什么事情缺失了，加载器和插件可以帮助你找到他们。Webpack有一个意味深长的学习曲线，尽管如此，它仍是一个值得学习的的工具，能节省很多时间和精力，在长期看来。
获得更多的Webpack和其他工具的比较，请翻阅[官方对比](https://webpack.github.io/docs/comparison.html)。
#Webpack支持的模块格式
Webpack允许你使用不同的模块格式，不过在帽子(hood)下它们以同样方式工作。
##CommonJS
如果你使用Node.js，那么你应该很熟悉CommonJS了。下面是简短的例子：
```
var MyModule = require('./MyModule');
// export at module root
module.exports = function() { ... };
// alternatively, export individual functions
exports.hello = function() {...};
```
##ES6
ES6这个格式我们从1995年就开始等待了。正如你看到那样，它很像CommonJS并且更简单。
```
import MyModule from './MyModule.js';
// export at module root
export default function () { ... };
// or export as module function,
// you can have multiple of these per module
export function hello() {...};
```
##AMD
AMD是异步模块定义格式。作为一种变通方案被发明，它引进了一个`define`包装器：
```
define(['./MyModule.js'], function (MyModule) {
// export at module root
return function() {};
});
// or
define(['./MyModule.js'], function (MyModule) {
// export as module function
return {
hello: function() {...}
};
});
```
顺便提一下，它可能和`require`一起使用，想下面这个样子：
```
define(['require'], function (require) {
var MyModule = require('./MyModule.js');
return function() {...};
});
```
这些实现方法确实减少了一些混乱。你最终还是要使用一些多余的代码。现在有了ES6,你应该不会再有理由使用AMD了，除非你真的需要它。
##UMD
UMD，同意模块定义。需要更上一层楼。这是一个怪物格式，它的目标是让上面的格式互相兼容。只是让你看一看，千万不要写在代码里，把这个工作留给工具吧。如果你没有被吓到。你可以试一试[官方文档](https://github.com/umdjs/umd)
Webpack能生成UMD包装器给你(output.libraryTarget: 'umd')。这对于库的作者特别有用。当讨论npm和库作者是时我们会回来讨论关于这个的细节。
#总结
我希望这个章节能帮助你明白为什么Webpack是一个值得学习的工具。它解决了一个常见的web开发问题。当你使用好它时，它可以节省大量的处理时间。在接下来的章节里我们会更深入的考察Webpack。你将学习开一个简单的开发配置。我们会用它来开始我们的Kanban应用。
你可以，也许是应该，使用Webpack时和其他一些工具一起使用。它不能解决所有的问题。它能解决打包中困难的问题。它减少了开发中的一些负担。仅仅使用`package.json, scripts`,和Webpack会带你走很远，你马上就能看到。
