对于一个高质量的web应用程序来说，选择一个重要的模块加载器是非常重要的。你可能不想在html页面中手动的添加script标签，因为这样很不灵活(你必须手动的对script标签排序、不能在部署的时候压缩代码...)。
最终的解决方案是Webpack，并遵循它的基本原理的文档。
模块加载器最主要的需求就是允许你写不同环境下的代码。这就意味着同样的一份代码能运行在node.js环境，也能运行在浏览器环境。每一个模块加载器对服务器端的支持不同：
- Require.js和WebPack：可以在服务器端使用
- 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模块。
投票结果：
- WebPack: +1;
- Require.js: -1;
- 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文件夹中。
投票结果：
- WebPack: +1;
- Require.js: +1;
- Browserify: -1;
速度
在开发的模式中，这是没有统一标准的。但是从个人经验而言这3者中Require.js是最快的，因为它在运行前不需要任何预处理的任务。
构建过程的速度取决于2个变量：
- 运行任务的工具(gulp或者grunt);
- 运行的任务(Webpack、Require.js、Browserify)
Gulp远远比grunt要快，没有做统计比较所有的选项。
投票结果：
- WebPack: 0;
- Require.js: +1;
- Browserify: 0;
内存使用
WebPack和Browserify都需要使用大量的内存，因为它们必须把所有的代码都保存在内存中。Require.js是最轻的，因为没有代码必须保存在内存中。
投票结果：
- WebPack: 0;
- Require.js: +1;
- Browserify: 0;
集成其他模块
在Require.js中加载其他模块需要在配置中去填充，而WebPack做这些几乎都是自动的。
投票结果：
- WebPack: +1;
- Require.js: -1;
- Browserify: 0;
Webpack警告
使用增强的require(让Webpack工作在node.js中)，你可能会遇到一些问题，比如：加载java的模块因为它是二进制的(很容易修复，通过原生的node.js的require方法)。
投票结果：
- WebPack: -1;
- Require.js: 0;
- Browserify: 0;
结论
通过回顾Webpack、Require.js和Browserify，你能够很好的理解每一个工具有什么优点和缺点。
最后的投票结果：
- WebPack: 2;
- Require.js: 1;
- Browserify: 0;
在所有的选择中，强烈建议WebPack结合gulp一起使用。
原文地址：module-loader-webpack-vs-requirejs-vs-browserify