模块加载器的比较: Webpack vs Require.js vs Browserify

对于一个高质量的web应用程序来说，选择一个重要的模块加载器是非常重要的。你可能不想在html页面中手动的添加script标签，因为这样很不灵活(你必须手动的对script标签排序、不能在部署的时候压缩代码...)。

最终的解决方案是Webpack，并遵循它的基本原理的文档。

模块加载器最主要的需求就是允许你写不同环境下的代码。这就意味着同样的一份代码能运行在node.js环境，也能运行在浏览器环境。每一个模块加载器对服务器端的支持不同：

1. Require.js和WebPack：可以在服务器端使用
2. Browserify：没有开箱即用的方法

模块代码风格

Require.js的模块看起来像这样：

    define(['a', 'b'], function(a, b){return {myModule: 1}})

或者你需要很多的依赖，你可能会感到混乱，你将这么做：

    define(function(require, exports, module){
        var a         = require('a');
        var b         = require('b');
        module.exports = {myModule: 1};
    })

这两种方式都不是最优的，因为会增加额外的代码。
使用WebPack和Browserify看起来像这样：

    var a          = require('a');
    var b          = require('b');
    module.exports = {myModule: 1};

这看起来非常像原生的node.js模块。
投票结果：

1. WebPack: +1;
2. Require.js: -1;
3. Browserify: +1;

迁移

你可以从任何风格迁移到Webpack。举个例子，我以前用Require.js风格的模块，然后无缝迁移到了Webpack。这非常的快，我不需要对我的源代码做任何的改变(构建过程的配置例外)，后来慢慢的我升级到Webpack的方式。这一个点我们不进行投票，但是Webpack再一次闪耀，如果你有一个大项目要处理的话(超过1000个文件)。

别名

别名是非常重要的，因为让你的代码组织良好、整洁、健壮且便于维护。
Webpack和Require.js在服务器端和客户端都有别名，而Browserify没有因为它不支持node.js。

为什么别名非常重要，我们看下面的代码结构：

    src
    client/someFolderA/a.js
    shared/logic/complexLogic.js
    server/someFolderB/b.js

现在你在服务器上的server/someFolderB/b.js文件中写了一些代码，你将怎么样去加载complexLogic.js这个文件呢？没有别名的话会很混乱：

// From file "server/someFolderB/b.js"
require('../../shared/complexLogic');

这不是理想的情况，有很多真实的例子： ghost1, ghost2, ghost3 with 3 levels, material-ui, strider1, strider2。
现在假设你要把server/someFolderB/b.js这个文件移动到其他的目录，你将不得不更新所有的相对路径(有时候相对路径是好的，但你需要知道什么时候使用它们)。
如果有别名的话，你可能这么做：

    // From file "server/someFolderB/b.js"
    require('shared/complexLogic');

你需要添加一个名为shared的别名指向src/shared，这让代码非常的整洁且更加健壮。
Browserify的用户也能做类似的事情，但不是最优的做法。他们能添加一个命名为node_modules的root项目文件夹。

    app
    node_modules
    client
    shared
    server

如果你只需要3个root别名且你不介意你的app中多一个node_modules文件的话，这也是不错的。但是这对新加入的开发者来说是不直观的，他们可能会把node模块放到node_modules文件夹中。

投票结果：

1. WebPack: +1;
2. Require.js: +1;
3. Browserify: -1;

速度

在开发的模式中，这是没有统一标准的。但是从个人经验而言这3者中Require.js是最快的，因为它在运行前不需要任何预处理的任务。
构建过程的速度取决于2个变量：

1. 运行任务的工具(gulp或者grunt);
2. 运行的任务(Webpack、Require.js、Browserify)

Gulp远远比grunt要快，没有做统计比较所有的选项。

投票结果：

1. WebPack: 0;
2. Require.js: +1;
3. Browserify: 0;

内存使用

WebPack和Browserify都需要使用大量的内存，因为它们必须把所有的代码都保存在内存中。Require.js是最轻的，因为没有代码必须保存在内存中。

投票结果：

1. WebPack: 0;
2. Require.js: +1;
3. Browserify: 0;

集成其他模块

在Require.js中加载其他模块需要在配置中去填充，而WebPack做这些几乎都是自动的。
投票结果：

1. WebPack: +1;
2. Require.js: -1;
3. Browserify: 0;

Webpack警告

使用增强的require(让Webpack工作在node.js中)，你可能会遇到一些问题，比如：加载java的模块因为它是二进制的(很容易修复，通过原生的node.js的require方法)。
投票结果：

1. WebPack: -1;
2. Require.js: 0;
3. Browserify: 0;

结论

通过回顾Webpack、Require.js和Browserify，你能够很好的理解每一个工具有什么优点和缺点。
最后的投票结果：

1. WebPack: 2;
2. Require.js: 1;
3. Browserify: 0;

在所有的选择中，强烈建议WebPack结合gulp一起使用。

原文地址：module-loader-webpack-vs-requirejs-vs-browserify