前言：
前端工程化是近年来屡被提及的一个概念，它并非凭空而来，而是在前端业务演化的过程中应运而生。
公元前的前后端开发模式：牵一发而动全身
在前端被称为“切图仔”的年代里，一个项目的开发流程是这样的：
- step1：前端拿到设计稿，用HTML+CSS实现。如果有必要，写一点点点点的js（比如简单的动画）
- step2:把写好的前端代码交给后端工程师
- step3:后端工程师把前端代码里的HTML和CSS嵌入服务器的模板引擎里。
- step4:后端工程师瞅瞅还要啥逻辑要交给浏览器处理，把对应的javascript代码写进模板引擎文件里
交互出了BUG怎么办？
- step1: 测试找到前端，前端把对应的CSS或HTML改掉
- step2: 测试和前端一起找到后端，后端把新的前端代码嵌入到之前的模板引擎文件里
- step3: 后端把新整合的代码重新部署出去
楼上的这种开发模式有两个巨大的BUG：
- 开发过程是串行的，时间利用率极低
- 出一个BUG要调动整个团队的人来修，明明不是后端的锅，后端也要跟着改，浪费人力
但是早起的网站逻辑普遍没有那么复杂，这种低效的开发模式竟也活了不少日子。
创世纪：AJAX问世，前端工程化萌芽
AJAX允许了异步请求和局部刷新，它的出现，大大提升了交互层面的用户体验。曾经我们的前端页面是字符串，是死的。现在我们的前端页面是应用，可以即时请求后端资源——它活了，活过来的前端页面渴求着更加丰富的前端业务逻辑。
后端工程师绝望了：我既要写后端业务代码，还要写前端业务代码，我是啥？全能神？？？
不，他不是。既然HTML，CSS和Javascript都是写给浏览器看的逻辑，那么Javascript逻辑理应由页面仔们来接手。于是页面仔们从此拥有了编写业务逻辑的权利。从这一天起，页面仔不再是页面仔，而是——前端工程师！
总结一下：前端业务的复杂化，使得前后端分离成为必须（否则将带来巨大的效率问题）。复杂度的提高，使得前端工程化成为必须。
公元后：前后端分离下的开发模式
前后端分离带来了这样的改变：
- 开发时，前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，前后端程序员只需要关心自己这一端的业务逻辑，双方并行开发
- 测试阶段，前端有Bug，前端来修。然后呢？然后就没有然后了，不需要惊动后端程序员了
- 部署阶段，静态资源和动态资源分开部署，各扫门前雪。
伴随着这种开发模式而生的，便是前端工程化的种种具体的诉求：开发期间我想用ES6写代码，老版本的浏览器看不懂怎么办？于是有了构建；前端页面没有后端的接口就没办法展示数据？先向本地发请求吧，于是有了本地服务；部署的过程怎么处理？手动还是自动，谁可以部署，权限怎么加——于是有了自动化部署，甚至有了管理平台的诉求。
总结
前端工程化在前后端分离的开发模式下萌芽，前端工程化正是为了在这种模式下创造一个更加高效的开发环境。
