前言
如果你正在進行前端專案的技術選型，可能就會發現，你已經跟不上前端生態的變化了，甚至令你眼花繚亂，因為現在有太多的技術棧供你選擇：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 | 為了解決前端開發中預處理、風格與測試、資源壓縮、靜態資源替換、模組化處理、效能優化等問題 | 文章待續 |