前言
如果你正在进行前端项目的技术选型，可能就会发现，你已经跟不上前端生态的变化了，甚至令你眼花缭乱，因为现在有太多的技术栈供你选择：React、Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow、Vue...这些技术栈的出现试图前端开发变得简单化、模块化、工程化，但有一部分却增加了学习成本和项目维护的不稳定性，因为技术栈的变化速度太快了。
由于 JavaScript 的语法很简单，前端入门比较简单，基本上少则数周就可以开发项目了，但要学习提升成为一名优秀的前端的工程师又极其不易，因为涉及的技术点很多，如：grunt / gulp, npm, requre.js / seajs 等辅助性技术；学习 **prototype / _proto_**等较晦涩的语法知识；掌握 MVC / MVP / MVVM 等设计模式；Backbone.js / Vue.js / React / AngularJS 等框架；jQuery / Protorype / lodash等库。
所以，我们往往需要阅读很多书籍才能理解前端技术的知识体系。本文将在前端知识体系上进行总结和梳理，涵盖了前端技术绝大部分的知识内容，会讲解前端技术的几条重要的演进路线，希望起到一个启蒙作用，能帮助读者快速把握前端技术的整个脉络，培养更完善的体系化思维。
疑惑
一些初学者大多都有这样的想法：我现在可以用 JavaScript 编写程序了，并且也正常上线了，而且运行的也不错，为什么我要再花额外的时间学习这些技术栈呢？
上述这些技术栈是为了弥补 JavaScript 在开发大型项目时的短板。
JavaScript 作为前端开发领域中最重要的语言，难道无法胜任现在的大型项目开发吗？如果要寻求这个答案，需要我们重新认识 JavaScript 的前世今生。
前世
JavaScript 在创造初期用来（ 脚本形式 ）弥补网页开发的不足。在那个时代，JavaScript 作为诸如： ASP / JSP 等开发语言的辅助功能存在，经常使用的场景（ 之一 ） 就是 『表单验证』。虽然 JavaScript 的缔造者 Brendan Eich 大神早已 『洞悉』了未来，但也无法阻挡 JavaScript 只花 10天 创造出来的事实。（ 第一版 ）那个时代，还没有一个专门从事 JavaScript 开发的职位，前端开发先驱们将更多的精力放在了 『浏览器大战』 之后的兼容性问题上。
发展
浏览器大战之后的另外一个影响，就是推动了 JavaScript 成为国际化标准，即：ECMAScript（欧洲标准化组织ECMA（European Computer Manufacturers Association）），后者用来描述 JavaScript 的语法结构，并推动它的发展，前者只是后者的实现方案。
备注：另外一个 ECMAScript 实现方案是 ActionScript 3.0
今生
随着 Chrome 这种现代浏览器的出现，其背后的 JavaScript 解析器（V8）大大增强了 JavaScript 的执行速度/效率。（在 V8 的基础上，另外一位大神 Ryan Dahl 发明了 Node.js，将本来仅仅运行在浏览器端的语言，发展到了后端开发。）jQuery 的诞生，使前端开发先驱们抽离出**『浏览器兼容性问题的泥沼』，有更多的精力来思考 JavaScript 的未来。网络带宽的增大以及 Ajax 技术的出现，使网页具有异步更新的方式，大大的加快了由传统 B/S 架构向 C/S 架构的探索，Google Gmail 的成功进一步推动此项技术成为大型项目的可能性。最终出现了SPA（ Single Page Application：单页面应用程序 ）**，至此使用 JavaScript 开发大型项目成为一种趋势和标准。
短板
由于 ECMAScript 推动着 JavaScript 的发展，即便 JavaScript 是上世纪的产物，但使用它开发一个小型的前端项目，其实并不困难。但是，**一个大型的 SPA 项目往往具有N个外部引用类库，数十个（甚至更多）js/html/css/图片 等资源组成；多人参与长时间维护，成千上万行的代码的特点。**显然，这些都是 JavaScript 在最初时所没有考虑过的情况。
正如前文描述，技术栈弥补了JavaScript 在开发大型项目上的短板，所以为了更加清晰的分析技术栈的特点，先从问题入手，一个大型的 JavaScript 项目通常需要解决哪些问题？
-
JavaScript先天不具有包管理功能 这并没有阻碍我们伟大的前端开发先驱们的探索，npm，bower 这类技术栈为我们解决了包管理问题。
-
过多的代码导致的项目更新，迭代，重构难题 既然代码过多，就需要使用诸如：封装，继承等现代化编程语言的面向对象编程方式。虽然 JavaScript 缔造初期并不是解决这些问题的，但 Brendan Eich 大神显然预见了未来，即在初版的 JavaScript 语言中，就包含了 OO 思想。换言之，JavaScript 是基于对象的开发语言。 虽然都是面向对象，但 JavaScript 与传统的面向对象不太一样，它使用了更高级但晦涩的继承链方式，这就是我们需要理解 prototype / _proto_ 这些技术栈的原因。
-
多人参与，开发的职责区分困难 由于大型 SPA 项目的出现，页面不仅承载了用户行为，更多的是将后端主导的逻辑开发也带到了前端。原本 MVC 中的 『M』比任何以往都要『重』，以至于在 『M』层，又形成了新的框架理论。因此了解并掌握 MVC / MVP / MVVM 等设计模式就变成了必要手段，进而前端框架开始流行。与其它语言一样，选用现成的前端框架自然变成了趋势，这些现代化框架的『设计思想』包含了前端开发新颖的理念， 如：操作虚拟 DOM（ Virtual DOM ）的 React；单纯的践行 MVC 理论的 Backbone.js；MVVM 风格的 AngularJS；等。学习并掌握前端框架可以更好的区分职责，而框架统一的 API 实现了长时间多人开发/维护的可能性。
-
虽然网络带宽得到了很大的提高，但页面的加载速度仍是问题 由于SPA 是单页面应用，因此页面在加载的时候几乎包含了全部功能，但用户往往却只使用其中的一部分，所以网速的限制，带宽的浪费，用户的等待则是另一个难题。**『模块化开发』 是解决这类难题的银弹，而 AMD / CMD 的理论自然成为前端开发者们掌握的必要知识，而 requre.js / seajs 则是这些理论的具体实现方式。**由于 Http 的特性所致 ( 分散的，小的静态资源在加载的时候更慢 )，因此 合并/压缩 则是另外一个解决方案，因此也产生了一个新的问题，即第五个问题。
-
静态资源（ html/js/css/图片等资源 ）过多导致上线时的重复性工作量增大 当这类静态资源很少的时候，手动 合并/压缩 并没有问题，反之这些资源呈指数上升的时候，手动方案显示不是一个好办法。自动化方案 的引入势在必行，而其中践行者：grunt / gulp / webpack 就需要掌握了。
不掌握这些技术也可以实现 JavaScript 开发，但掌握了这些技术栈可以使我们从 『繁重 / 繁琐』的事务中抽离出来，更加 『专注于业务逻辑』。所以，恭喜你，欢迎来到新世界！！！
上述列举的知识点仅仅属于前端技术栈的一部分，除此以外还包括了：调试/测试，性能优化，CSS预编译方式，编码规则，SEO，移动 Web 开发等。
掌握这些技术后就万事无忧了吗？当然不，随着前端开发的发展，总有一天，这些技术仍无法满足开发。所以要了解这些技术栈背后的理论逻辑，以不变应万变，方为制胜之道！
技术全景
基础技术
技术演进
对于前端技术的演进过程，主要都是为了解决前端在大型项目开发过程中遇到的问题，比如：包管理、模块开发、多人协作、资源管理、打包构建、页面加载等方面的问题，其演进过程主要分为5条主线：JS编程语言、CSS编程语言、JavaScript模块化、前端分层模式、前端自动构建。
| 演进 | 过程 | 目标 | 文章 |
|---|---|---|---|
| JS编程语言 | JavaScript、TypeScript、CoffeeScript、ES5、ES6、Babel转码器、Traceur 转码器 | 使得 JavaScript 语言可以用来编写复杂的大型应用程序，成为企业级开发语言 | 文章待续 |
| 包依赖管理 | Bower、npm、Browserify | 为了解决JavaScript没有包管理系统。不能自动加载和安装依赖问题 | 文章待续 |
| CSS编程语言 | Sass、LESS和Stylus | 使我们可以用编程思想来编写CSS，并可以帮助我们快速编译代码，及更好进行前端项目的维护 | 文章待续 |
| JavaScript模块化 | CommonJs (Node.js)、AMD (RequireJS)、CMD (SeaJS)、UMD | 为了解决JavaScript没有模块系统的问题，减少命名冲突，消除全局变量；一个模块一个文件，组织更清晰；依赖自动加载，按需加载 | 文章待续 |
| 前端分层模式 | MVC、MVP、MVVM | 为了解决前端逻辑越来越重，越来越复杂，路由不好掌控，复杂前端情况下模块化JS、多人协作等问题 | 文章待续 |
| 前端自动构建 | Grunt、Gulp、Webpack、Yeoman | 为了解决前端开发中预处理、风格与测试、资源压缩、静态资源替换、模块化处理、性能优化等问题 | 文章待续 |
