webpack学习笔记（一） -- webpack背景介绍为了统一开发者和项目之间的差异，我们需要一些行业化的标准去规

本文旨在学习记录，以便后期复习巩固

需要知道的问题:

它到底解决了问题，
也需要知道一些模块化的基本知识(因为webpack早期就是去实现前端方面的模块化开发)

webpack背景介绍
webpack核心特性
webpack高阶内容
同类优秀方案

模块化的演进过程

方法1：文件划分方式
- 简介：即一个文件就是一个模块，需要时我们通过script标签引入html内，然后使用
- 优点：-
- 缺点：
  1. 模块直接在全局工作，易污染全局作用域
  2. 没有私有空间，所有模块内的成员可在外部被访问或修改
  3. 模块多的时候，易发生命名冲突
  4. 无法管理模块与模块之间的依赖关系
  5. 维护的过程中很难分辨每个成员所属的模块
  6. 模块加载方式不友好
  7. 通过约定的方式实现，不同的开发者之间会有一些差异
方法2：命名空间的方式
- 简介：在1的基础上，将每个模块包裹起来，挂载到全局对象中
- 优点：解决了命名冲突
- 缺点：1的其他缺点还是存在的
方法3：IIFE
- 简介：在2的基础上增加了立即执行函数（每个模块的内容都放在一个立即执行函数的私有作用域内）
- 示例：
- 优点：
  1. 为每个模块提供了私有的空间（解决了全局污染）
  2. 解决了命名冲突
  3. 通过参数申明依赖的模块，所以可以知道模块间的依赖关系
- 缺点：
思考：
1. 方法1 - 3都存在加载方式不友好的问题，为此，我们需要更友好的方式：在页面中引入一个js入口文件，需要用到的模块由这个文件负责控制，进行按需加载
2. 为了统一开发者和项目之间的差异，我们需要一些行业化的标准去规范模块的实现方式。
- 基于以上内容，我们对于模块化的需求如下：
  - 一个统一的模块化标准规范
  - 一个可以自动加载模块的基础库
- 谈到标准，可能会想到CommonJS规范
  - CommonJS规范是node中遵循的模块规范
  - 该规范约定一个文件就是一个模块，每个模块都有单独的作用域，通过module.exports导出成员，再通过require函数载入模块
  - 注意：node中是同步加载模块~~
  - 所以，早期并没有直接选择CommonJS规范
- 综上专门为浏览器端重新设计了一个规范AMD (Asyncchronous Module Definition)，即 异步模块定义规范
- 同期推出了库：require.js，除了实现了AMD模块规范，本身也是一个非常强大的模块加载器
- 随着技术的发展，模块化规范也逐渐标准化：
  - 在node中，遵循CommonJS规范
  - 在浏览器环境中，遵循ES Modules规范
ES Modules
- 简介：ES Modules 规范是在ECMAScript2015（ES6）中才定义的模块系统
- 优点：
  1. 相较AMD这种社区提出来的规范而言，ES Modules是从语言层面实现的模块化，所以更完善、更合理
- 缺点：
  1. 存在兼容性问题（es6 =》 es5）
  2. 模块化会使划分出来的模块文件过多，可能导致浏览器频繁发送请求，影响性能 (将散落的模块再打包成一个文件, bundle.js)
  3. 随着发展发现，html、css也需要做模块化的处理（支持前端不同种类的文件类型都当做模块使用，即让样式、图片等等都可以作为模块处理）
  - 1和2我们可以通过gulp实现，但是3我们就需要webpack了

webpack学习笔记（一） -- webpack背景介绍

模块化的演进过程

思考：