页面制作的历史
切页面是前端最基础的工作，如何选用合适的工具让自己事半功倍，一直都是我关注的问题。
最早的时候，我直接生产 HTML、CSS、JS，以及大量的资源文件，比如图片、音频、视频，甚至 Flash。然后把所有产生的文件打包，传给负责下一步的同事。
这样的操作方式，开发时还好，维护时会遇到比较大的挑战：
- 中大型网站，一般要把不同类型的资源放在不同的服务器上。每次分门别类上传不同文件，很容易出错。
- 负责下一步的同事可能要对资源进行修改和调整，维护意味着每次都要这样做
- 缺少版本管理，每次都是一个压缩包，很容易弄乱文件
接下来 Node.js 面市，前端终于可以摆脱浏览器的限制，创造本地工具，改善开发流程了。于是一时间各种工具如雨后春笋般涌现出来，从各种角度改进开发流程。其中，最受瞩目的，是批处理 Grunt。
前面说过，维护工作，诸如把不同文件上传到不同服务器上、合并 CSS spirit、优化图片尺寸，等，非常繁琐，容易出错。如今有了 Grunt，大家可以用写配置脚本的方式来完成这些工作，相对来说，压力小了非常多。而且，配置文件可以进行版本管理，一些产品部署的方案变化也可以脱离具体的人，体现在代码库的文件里，对协作有很大好处。
然后，Gulp 逐步取代了 Grunt 的位置，不过从本质上来讲，二者区别不大。Gulp 的优势在于：
- 它使用 stream 传递数据，速度更快、效率更高
- 它抛弃了“配置”式，改用“定义”式结构，阅读体验更好，更方便调试
一直到现在，Gulp 可能都是开发多页面企业网站最常用的工具——我在群里宣传时，就有人问我，为什么不用 Gulp。
Gulp 能满足网站开发的各种需求，但不代表 Gulp 解决方案是完美的：
- Gulp 需要开发者手动处理所有资源，成本较高
- Gulp 没有类似 webpack-dev-server 这样的核心组件，开发环境比较难搞
- Gulp 只是批处理，只能组织各种操作，它仍然需要用 webpack 处理 JS。换言之，Webpack “可能”可以替代 Gulp，但 Gulp “不可能”替代 Webpack
如果一个工作只用 webpack 就能完成，那么我似乎没有必要再用别的工具，比如 Gulp。何况 webpack 还有更好用的 dev-server。
Webpack 诞生的时候，可能没想过要取代 Gulp。Webpack 的核心是打包，它想解决的，是前端模块复用的问题。通过一个核心（入口）JS，把所有元素组织起来，交给脚本处理，更加自动化，更不容易出错。但是经过这么多年的发展，它的作用已经不仅局限于此，各种前置处理后置处理，优化过滤打包复制，都可以通过各种 Loader 和插件实现，甚至连企业网站开发这种 Gulp 曾经最适用的场合，也有更优秀更好用的新方案了。
接下来，开始分享这个方案。