WebPack系列教程（二）：动机

当今的网站已经发展为web app：

越来越多的js脚本放入页面；

在现代浏览器中，我们能做越来越的事情；

如今很少有网站会采用整页面重载，因而页面的代码越来越多；

最终导致大量的代码放入客户端中了。

庞大的前端代码库需要重新组织。模块系统提供了这样的能力来帮助你拆分代码库到各个模块中。

目录

Module system styles

<script>

标签（无模块化）

CommonJs: （同步加载）

AMD: （异步加载）

ES6 模块系统

公正的解决方案

传输

分块传输

为什么仅仅是Javascript

静态分析

策略

Module system styles

如今有很多标准来定义依赖(dependencies)和导出(export)的值：

<script>

标签（无模块化）

CommonJs: （同步加载）

AMD: （异步加载）

ES6 模块系统

更多…

<script>

标签（无模块化）

下面是未使用模块系统来加载使用已经模块化了的代码库

<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>

这种方式会把加载的模块对象添加到全局对象上，如window对象。模块能通过window对象访问到其所依赖的各模块对象。

存在的问题

全局对象命名冲突；

加载顺序非常重要；

开发人员不得不解决模块/库之间的依赖；

在大型项目中，如此多的引入脚本是相当费时和难以维护的；

这种方式使用同步require方法加载依赖并返回对外的接口。一个模块能通过给exports对象添加属性或者给module.exports设置值来指定开放哪些接口。

require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;

CommonJs多用于服务端NodeJs

支持者

服务端模块能复用；

npm中已经有很多模块使用该方式；

非常简单和容易使用；

反对者

阻塞式的加载不适用于网络环境，网络请求通常都是异步的；

无法并行请求多个模块；

基于该方式实现的库

node.js - server-side

browserify

modules-webmake - compile to one bundle

wreq - client-side

AMD: （异步加载）

异步模块定义Asynchronous Module Definition

对于浏览器端的模块系统使用同步加载的方式会存在问题，因而引入了异步加载的方式。

require(["module", "../file"], function(module, file) { /* ... */ });
define("mymodule", ["dep1", "dep2"], function(d1, d2) {
return someExportedValue;
});

支持者

适合网络环境的异步请求方式；

多模块的并行加载；

反对者

编码开销：更难以读和编写；

看起来像某种变通方案；

基于该方式实现的库

require.js - client-side

curl - client-side

阅读更多关于CommonJs and AMD.

ES6模块系统

EcmaScript6添加了一些语言结构到javascript当中，使之形成了另一套模块系统。

import "jquery";
export function doStuff() {}
module "localModule" {}

支持者

静态分析很容易；

成为ES标准：不会过时；

反对者

本地浏览器支持尚需时日；

使用这种方式的模块太少；

公正的解决方案

允许开发者自己选择使用哪种模块系统；兼容现有的代码；添加自定义模块更加容易；

传输

模块代码需要在客户端执行，因此它们必须要从服务端传输到浏览器中。

有两种传输模块的极端方式：

一个请求一个模块；

一个请求所有模块；

两种方式都使用很广，但都不是最佳方案：

一个请求一个模块；

支持者：只传输必须加载的模块；

反对者：很多的请求意味着更多的开销；

反对者：因为延迟加载，导致应用程序启动变慢；

一个请求所有模块；

支持者：更少的请求开销，更少的延迟；

反对者：会加载不需要（多余）的模块；

分块传输

一种更灵活的传输方式可能会更好。在很多案例中对于上述两种极端情形进行折中会更合适。

当编译所有模块时：可以将多个模块组成模块集分别放入多个更小的打包分块的文件中。

我们会得到大量更小的请求。大模块集不会在初始化时就加载，只有当需要时才会去加载它们。初次加载不会请求项目所有的代码库。

代码分割的“拆分点 ”取决于开发者，并且是可选的。

编写大代码库成为可能。

注：该思想来源于Google’s GWT

阅读更多关于代码拆分

为什么仅仅是Javascript

为什么一个模块系统只能帮助开发者处理Javascript。要知道前端代码中存在很多需要被处理的其他静态资源：

样式表

图片

网络字体

html模板

等等…

同时还有：

coffeescript → javascript

elm → javascript

less/sass stylesheets→ css stylesheets

jade templates → javascript which generates html

i18n files → something

等等…

这些都应该同样可以简单使用：

require("./style.css");

require("./style.less");
require("./template.jade");
require("./image.png");

阅读更多关于Using Loaders和Loaders

静态分析

当编译所有模块时，静态分析试图查找所有的依赖。

通常静态分析只能通过简单没有表达式的字符串进行查找，但是像

require("./template/" + templateName + ".jade")

是一种很常见的结构。

很多库使用不同的风格，有些事非常怪异的…

策略

一个聪明的解析器需要能够保证大量已经存在的代码可以运行。如果开发人员使用了一些怪异的方式编写，解析器要能找到最兼容的解决方案。