前端工具之WebPack解密--背景

请注意，这是一篇站在彻底新手的角度上来写的文章。可能你是一个后端人员想了解前端工具的使用和概念;也可能你是一个前端小菜（还在DIV+CSS的世界里挣扎着）。本文比较适合那些之前彻底没有接触过WebPack，而又想使用的朋友。经过本文你能理解webPack工做原理及作用！（不会至于看了半天资料尚未头绪！）

前言：本人是一个从后端转向前端的程序猿，在此以前对于前端的印象一直是：HTML + CSS + JS。彻底没有想过前端会发展的如此的迅速，各类名词的出现：Node、NPM、Grunt、Gulp、Bower、Webpack、Browserify、Yeoman。瞬间让感受到不知道如何下手（好像根本学不完的样子）！

先上一张别人的图,目前的前端工具！

1、背景

若是你和我同样，以前对于前端打包工具的发展一无所知，甚至于不知道这些工具出现的必要性。你能够浏览此部分的内容，若是你不想知道这些或者对这些并不感兴趣，能够直接跳过此部分。

互联网程序现状

随着移动互联的来袭，当前愈来愈多的网站已经从单纯的网页模式，开始升级为webapp模式。它们运行在现代的浏览器中，使用HTML五、CSS三、ES6等技术开发，已经从单一的浏览功能转变为一个基于浏览器的富客户端。而且webapp一般是一个SPA(Single Page Application 单页面应用)。每一个页面（View）经过异步的方式加载，有着良好的用户体验。可是这样作的结果是致使程序初始化和使用的过程当中须要更多、更复杂的JavaScript代码来实现，这就对前端程序的开发带来巨大的挑战！

模块化系统的演变

随着程序的复杂性的增长，项目结构的庞大。把单一js文件按职责进行模块化划分。

咱们在写页面的时候会这样写：

<script src="base.js"></script>
<script src="utils.js"></script>
<script src="vipPush.js"></script>

这是最基础的JavaScript加载方式，每一个JS的全部方法和属性都是暴露在window对象中的（就像把全部代码都放在一个命名空间或者同一个包下），借助全局对象，咱们就能使用这些属性和方法。若是更为复杂的程序会使用命名空间的概念来组织这些模块的接口，好比：YUI

这种开发方式带来的弊端：

• 全局的做用域下容易形成变量的相互冲突（这是一个很常见的问题）
• 文件只能按照<script>的书写顺序进行加载
• 开发者要解决各个模块和代码库之间的依赖
• 若是按照此模式进行开发，长期下去整个项目（前端）代码一定会混乱不堪

由于有了模块的概念，让咱们的开发变得比较方便。让咱们能够很方便的使用别人的代码，想要什么功能就加载什么模块。这样下去模块的规范就变的更重要。目前：通用的JavaScript模块规范主要有：

1. CommonJs
2. AMD、CMD
3. ES6的模块

CommonJS： 同步加载解决方案

著名的node.js模块系统就是参照CommonJS规范来实现的。其核心思想就是经过require来进行同步加载其它模块，而后经过exports 或 module.exports来导出须要暴露的接口。

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

优势：

1. 服务器端模块便于重用
2. 在NPM里有不少功能模块
3. 简单易用

缺点：

1. 同步加载的方式注定不能用于客户端（clients），同步的加载意味着阻塞加载，浏览器的加载方式是异步的
2. 不能非阻塞的并行加载多个模块

表明：

1. 服务端 node.js
2. Browserify，浏览器端的 CommonJS 实现，可使用 NPM 的模块，可是编译打包后的文件体积可能很大

AMD： 异步加载解决方案

AMD(asynchronous Module Definition)意思就是"异步模块定义"，其规范主要是一个接口define(id?, dependencies?, factory),它采用的是异步加载的方式加载模块，模块的加载不影响它后面请语句的运行。全部执行语句都是在模块加载完成以后的回调函数中执行的。

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

优势：

1. 适合在浏览器环境中进行加载模块
2. 能够并行多个模块

缺点：

1. 提升了并发的成功，代码的阅读和书写比较困难
2. 不符合通用模块化的思惟方式，是一种妥协的实现

实现：

• RequireJS

CMD： 另外一种异步加载解决方案

CMD(Common Module Definition)规范与AMD很类似，尽可能保持简单，并与CommonJs和Node.js的Module规范保持了很大的兼容性

define(function(require, exports, module) {
  var $ = require('jquery');
  var Spinning = require('./spinning');
  exports.doSomething = ...
  module.exports = ...
})

优势：

1. 依赖就近，延迟执行
2. 能够很容易在 Node.js 中运行

缺点：

1. 依赖 SPM 打包，模块的加载逻辑偏重

实现：

• Sea.js

ES6 模块

在ECMAScript2015(es6)中，增长了JavaScript语言层面上的模块体系定义，其设计思想是：尽可能的静态化，使得编译时就能肯定模块的依赖关系，以及输入和输出变量。

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

优势：

1. 容易进行静态分析
2. 面向将来的 EcmaScript 标准

缺点：

1. 原生浏览器端尚未实现该标准
2. 全新的命令字，新版的 Node.js才支持

实现：

• Babel

把程序全部的文件进行模块化以后，咱们还要处理一个问题那就是传输问题。模块的化分让咱们可让程序变得能够组件化进行开发，组件虽然被客户端执行，可是依然要由服务器传送给客户端。

关于组件的传送有两个极端：

1. 每一个组件，一个HTTP请求

   • 优势：仅仅传送依赖项
   • 缺点：请求多，负载高，更慢的启动延迟

2. 全部的组件，一个HTTP请求

   • 优势： 更快，更低的延迟
   • 传送了没有必要传送的东西

让我在这两种状况之间作一个妥协：分块传输，按需进行懒加载，在实际用某些模块的时候进行增量的更新，才是比较合理的加载方案。

要实现这个功能，须要在编译打包时进行静态的分析、模块进行分批次的打包。那么这个分批次谁来作呢？ 答案就是：WebPack

参考资料：

• http://webpackdoc.com/module-system.html
• http://webpack.github.io/docs/motivation.html
• http://www.jianshu.com/p/42e11515c10f#
• http://www.ruanyifeng.com/blog/2012/10/asynchronous_module_definition.html
• http://mp.weixin.qq.com/s/di2evt5-KCmudC1U6m5sKw