随着页面表现形式越来越丰富，用户体验与交互越来越被关注。前端开发大量涌现出H5、CSS3、ES6等技术方案。前端开发从简单的类库调用转而关注和强调框架的应用。无论是使用类库还是框架，都需要加载JS、CSS甚至大量第三方类库。如何管理和组织这些静态资源，并保证它们在浏览器中可以快速、灵活的加载与更新呢？这是目前web开发倡导的模块系统所需面对和解决的问题。
模块系统需要解决的是如何定义模块以及如何处理模块间的依赖关系。
Web开发初期，常用JS文件加载使用<script>标签完成，这种方式带来的问题是每个文件中声明的变量都会出现在全局作用域内，即window对象中。模块间的依赖关系完全由文件的加载顺序所决定，显然这种模块组织方式存在很多弊端。
- 全局作用域下容易造成变量冲突
- 文件只能按照
<script>标签的书写顺序进行加载 - 开发者需自己解决模块/代码库的依赖关系
- 大型web项目中这样的加载方式导致文件冗长且难以管理
你曾经遇到过这些问题吗？
- 载入有问题的依赖项
- 意外引入生产环境中无用的CSS和JS，使项目膨胀。
- 意外的多次载入某些库
- 遇到作用域问题
- 使用NPM或Bower模块的构建系统，令人发狂的配置后才能正确使用。
- 优化asset时担心弄坏它
...
前端模块化标准规范
- CommonJS
CommonJS规范中模块使用require()同步加载所依赖的模块，通过设置exports对象或module.exports对象的属性的方式，对外提供支持的接口。
CommonJS的优点是可重用服务端模块、NPM中有大量模块使用CommonJS规范来书写，其缺点是同步的加载方式并不适合在浏览器的环境，由于浏览器的资源往往是异步加载的，而且不能非堵塞的并行加载多个模块。
CommonJS典型实现如node.js、browserify、modules-webmake、wreq等。 - AMD（Asynchronous Module Definition）
AMD规范中模块通过define(id, dependencies,function)方法来定义，同时需指定模块的依赖关系，而且这些依赖的模块会被当做形参传入function方法中。而应用通过使用require()方法来调用所定义的模块。
AMD的优点在于适合在浏览器环境中异步加载模块，可以并行加载多个模块。其缺点是增加开发成本且不利于代码的编写与阅读，另外，不符合通用的模块化的思维方式，只是一种妥协的实现。
AMD典型的实现如require.js 和 curl。 - ES6模块
ECMAScript2015（ES6）增加了很多JS语言层面的模块化体系定义，ES6模块的设计思想是尽量的静态化，使得编译时即可确定模块的依赖关系，以及输入和输出的变量。
ES6模块的优点是很容易进行静态分析，而且面向未来的ECMAScript标准。缺点在于原生浏览器还没有实现该标准，而且目前支持的模块较少。
ES6典型的实现如Babel。
期望的模块系统
- 兼容多种模块系统风格
- 模块按需加载且不影响页面初始化速度
- 支持多种资源文件
- 支持静态分析及第三方类库
- 合理的测试解决方案
什么是前端构建工具呢？
- 文件打包
每个页面会根据前端资源JS、CSS、图片等发起多次HTTP请求，大量页面叠加在一起，将极大地降低页面性能，造成页面加载很慢。那么，能不能将前端资源文件合并为一个文件呢？ - 文件压缩
压缩文件可提供页面性能，例如删除注释、删除空格、缩短变量名等，以减少文件体积加快传输速度提高页面性能，另外实现代码混淆破快其可读性以保护作者知识产权。 - 前端模块化
从大量<script>到webpack广泛使用，实际上是前端模块化发展的过程，期间有两个主要模块化标准CommonJS和AMD。 - 编译和转换
浏览器是无法理解开发代码中SASS、LESS、JSX模块文件等，通过webpack的转换生成一份浏览器能够理解的生产代码。
什么是webpack呢？
webpack是前端资源模块化管理和打包工具，可将松散的模块按依赖和规则打包成符合生产环境部署的前端资源。可将按需加载的模块进行代码分隔并进行异步加载。通过loader的装换，任何形式的资源都可视作模块，如CommonJS模块、AMD模块、ES6模块、CSS、图片、JSON、CoffeeScript、LESS等。
webpack和gulp本质上并非同一类型工具，但它们都能完成相同的任务。
- webpack是一个模块化工具（a module bundle）
- gulp是一个任务运行器（a task runner）
为什么需要webpack呢？
webpack通过让JS来处理依赖关系和加载顺序，而非通过开发者的大脑。webpack可纯粹的在服务端运行来构建渐进增强式的应用。
webpack试图通过提出一个大胆的想法来减轻开发者的负担：如果开发过程一部分可以自动处理依赖关系会怎样呢？若可以简单地写代码，让构建过程最终只根据需求管理自己会怎样呢？
webpack的方式是：若webpack了解依赖关系，它会捆绑在生产环境中实际需要的部分。
- 将依赖树拆分保证按需加载
- 保证初始加载的速度
- 所有静态资源可被模块化
- 整合构建第三方库和模块
- 适合构建大型SPA单页应用程序
本质上，webpack是一个现代JS应用程序的静态模块打包器（module bundle）。当webpack处理应用程序时，它会递归地构建一个依赖关系图（dependency graph），其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个bundle。
