# webpack > At its core, webpack is a static module bundler for modern JavaScript applications. > 从本质上来讲，webpack是一个现代的JavaScript应用的`**静态模块打包工具**`。 重点：模块和打包 ## 前端模块化 在前面学习中，我已经用了大量的篇幅解释了为什么前端需要模块化。 而且我也提到了目前使用前端模块化的一些方案：AMD、CMD、CommonJS、ES6。 在ES6之前，我们要想进行模块化开发，就必须借助于其他的工具，让我们可以进行模块化开发。 并且在通过模块化开发完成了项目后，还需要处理模块间的各种依赖，并且将其进行整合打包。 \*\*而webpack其中一个核心就是让我们可能进行模块化开发，并且会帮助我们处理模块间的依赖关系。 而且不仅仅是JavaScript文件，我们的CSS、图片、json文件等等在webpack中都可以被当做模块来使用（在后续我们会看到）。 这就是webpack中模块化的概念。 \*\* ## 打包 就是将webpack中的各种资源模块进行打包合并成一个或多个包(Bundle)。 供`浏览器`或者`node服务`去使用 **并且在打包的过程中，还可以对资源进行处理，比如压缩图片，将scss转成css，将ES6语法转成ES5语法，将TypeScript转成JavaScript等等操作**。 但是打包的操作似乎grunt/gulp也可以帮助我们完成，它们有什么不同呢？ （后面介绍） ## 组件化和模块化的区别 > Tips：大家可能也经常听到组件化这个名词，模块化一般指的是可以被抽象封装的最小/最优代码集合，模块化解决的是功能耦合问题；组件化则更像是模块化进一步封装，根据业务特点或者不同的场景封装出具有一定功能特性的独立整体；另外，前端提到组件化更多的是具有模板、样式和 js 交互的 UI 组件。 ## 工程化 当我们开发的 Web 应用越来越复杂的时候，会发现我们面临的问题会逐渐增多： 1. 模块多了，依赖管理怎么做； 2. 页面复杂度提升之后，多页面、多系统、多状态怎么办； 3. 团队扩大之后，团队合作怎么做； 4. 怎么解决多人研发中的性能、代码风格等问题； 5. 权衡研发效率和产品迭代的问题。 这些问题就是软件工程需要解决的问题。工程化的问题需要运用工程化工具来解决，得益于 Nodejs 的发展，前端这些年在工程化上取得了不俗的成绩。前端工程化早期，是以 Grunt、Gulp 等构建工具为主的阶段，这个阶段解决的是重复任务的问题，它们将某些功能拆解成固定步骤的任务，然后编写工具来解决，比如：图片压缩、地址添加 hash、替换等，都是固定套路的**重复你性工作**。 而现阶段的 Webpack 则更像是从一套解决 JavaScript 模块化依赖打包开始，利用强大的插件机制，逐渐解决前端资源依赖管理问题，依附社区力量逐渐进化成一套前端工程化解决方案。 ## 什么是 webpack > 本质上，Webpack 是一个现代 JavaScript 应用程序的静态模块打包器（static module bundler）。在 Webpack 处理应用程序时，它会在内部创建一个依赖图（dependency graph），用于映射到项目需要的每个模块，然后将所有这些依赖生成到一个或多个 bundle。 像 Grunt、Gulp 这类构建工具，打包的思路是：`遍历源文件`→`匹配规则`→`打包`，这个过程中**做不到按需加载**，即对于打包起来的资源，到底页面用不用，打包过程中是不关心的。 webpack 跟其他构建工具本质上不同之处在于：**webpack 是从入口文件开始，经过模块依赖加载、分析和打包三个流程完成项目的构建**。在加载、分析和打包的三个过程中，可以针对性的做一些解决方案，比如`code split`（拆分公共代码等）。 当然，Webpack 还可以轻松的解决传统构建工具解决的问题： * 模块化打包，一切皆模块，JS 是模块，CSS 等也是模块； * 语法糖转换：比如 ES6 转 ES5、TypeScript； * 预处理器编译：比如 Less、Sass 等； * 项目优化：比如压缩、CDN； * 解决方案封装：通过强大的 Loader 和插件机制，可以完成解决方案的封装;