【译】Webpack对比

　　原文链接：http://survivejs.com/webpack_react/webpack_compared/

---

 开始正文

　　当你把Webpack放到过往历史中你就会很好地理解为什么它的方法是如此的有力。在早些时候，它的能力对于仅仅把一些脚本连接在一起是足够的。然而时光变迁，现在分布你的Javascript代码可以是个复杂的奋斗者号。

　　SPA（单页应用）的崛起

　　随着单页应用（SPAs,single page application）的崛起，这个问题已经逐渐凸显出来。它们倾向于使用非常多笨重的库。你最不想看到的应该是一次性地把它们全部加载出来。其实有很多很好的解决办法，Webpack与它们中的很多都可以紧密配合使用。

　　得益于Node.js的火爆，Node.js的包管理器npm提供了许多环境。在之前，npm还难以让开发人员去使用这些依赖。现在，随着npm已经因为前端开发而变得广为熟知，环境已经发生了很多变化。依赖管理也是越来越简单了。

　　任务运行工具和打包工具

　　从历史上来讲，已经有了很多的构建系统。Make可能是最广为数值的，并且仍然是个可行的选项。为了让工作简单一些，专业的任务运行工具，类似于Grunt和Gulp出现了。通过npm可获得的插件使得这些任务运行工具变得非常好用。

　　任务运行工具已经是高水准中的非常棒的工具了。它们允许你去跨平台去进行一些操作。但是当你需要把非常多的资源拼接在一起并在生产中打包时问题就会出现了。这也就是为什么我们需要打包工具，比如Browserify或者Webpack。

　　为了在这条路上更进一步，JSPM直接向浏览器推出了包管理器。它依赖于Systerm.js，一个动态模块加载器。不像Browserify和Webpack，它跳过了开发过程中所有的打包步骤。然而你也可以用它打包生成一个产品。Glen Maddern在他的关于JSPM的视频中有更多的细节。

　　Make

　　你可以说Make在走下坡路。它最初在1977年发布。尽管它是个非常老的工具，但是它仍然保持放松。Make允许你为了创造一个生产构建工具去写一些分散的任务——压缩你的JavaScript代码或运行一些测试。你可以在一些其他的工具中发现相同的想法。

　　即使Make在C语言项目中广泛使用，它不以任何方式依赖于这些使用Make的C语言项目。James Coglan在如何通过JavaScript使用Make中讨论了细节。仔细思考一下下面的基于James文章的简短代码

　　Makefile

　　

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之前就成为了主流。特别一提的是它的插件构建特性，这有助于它的流行。同时，这种构建特性也是Grunt的唯一弱点。我知道有很多你不想必须维护一个300行的Gruntfile而告终的经历。这是Grunt documentation上的一个例子。

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是个悠久的用来定位你的JavaScript原代码中可能的问题点的工具。我们有一个单独的任务去运行jshint。当我们运行Grunt时，随着我们编辑保存原代码我们也会在终端机上得到实时的警告。

　　在实践中，你会为各种各样的类似构建一个项目这样的目标而有很多小任务。 例子展示了这些任务是如何构造的。Grunt的优点中很重要的一点就是它隐藏了你的很多线路。尽管，过度使用的话还是会变得有问题的。它会让你很难完全理解在表面下进行的是什么。

　　注意：grunt-webpack插件能使你在一个Grunt环境下使用Webpack。你可以告别繁重的Webpack。

 

　　Gulp

 

　                                                      　

　　Gulp采用了不同的方法。你可以用真实的代码去解决而不是依赖配置配个插件。Gulp构建在可靠地正确的管道基础上。如果你对Unix熟悉，这里是相同的理论。你仅仅有软件源、过滤器和接收器。

　　软件源与文件相适配。过滤器在软件源上进行操作（举例来说就是转化成JavaScript代码）。最后，结果通过给过滤器（举例来说就是你建立了一个目录也就是文件夹）。这里有个从一个项目上的README上拿下来的Gulpfile来帮你更好地理解这种方法。它已经缩写过了。

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']);

　　给出配置的是代码，如果你运行出问题时通常可以仅仅删改。你可以打包作为Gulp的插件放在Node.js的包管理器中，等等。对比Grunt，你对正在运行的有更清晰的理解。尽管如此，你仍然可以停止为临时任务写一堆引用。这里有一些更新的方法来使用。

　　gulp-webpack允许你在gulp的环境中使用Webpack。

　　Fly是一个和Gulp相似的工具。它依赖于ES6的生成器。

　　Browserify

　　

　　使用JavaScript模块处理已经有了很多的问题。这种语言本身在ES6之前并没有对模块的明确定义。因此，当谈到浏览器环境时，我们就已经陷在90年代了。各种解决措施包括AMD，已经被提出。

　　在实际生产中，只使用CommonJS是非常方便点，这是Node.js的格式，并且剩下的可以用工具解决。优势是你可以经常连接到npm上，可以避免重复造轮子。

　　Browserify是一个解决模块化问题的办法。它提供了一种一起打包CommonJS模块一起的方式。你可以把它和Gulp连接到一起。有一些小的转换工具能使你超越基本用途。例如：watchify提供了一个文件监测器当开发过程中为你生成打包。这将省去你很多工夫，并且毫无疑问这在一定程度上是一个好的解决方案。

　　Browserify的系统是由很多小的模块组成的。在这一方面，Browserify紧随Unix哲学。Browserify比Webpack接受起来简单些，并且确实，是一个好的另一种选择。

来源：https://www.cnblogs.com/regiondavid/p/5487994.html