前端技術全景展望

前言

若是你正在進行前端項目的技術選型，可能就會發現，你已經跟不上前端生態的變化了，甚至令你眼花繚亂，由於如今有太多的技術棧供你選擇：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 項目一般須要解決哪些問題？

1. JavaScript先天不具備包管理功能 這並無阻礙咱們偉大的前端開發先驅們的探索，npm，bower 這類技術棧爲咱們解決了包管理問題。

2. 過多的代碼致使的項目更新，迭代，重構難題 既然代碼過多，就須要使用諸如：封裝，繼承等現代化編程語言的面向對象編程方式。雖然 JavaScript 締造初期並非解決這些問題的，但 Brendan Eich 大神顯然預見了將來，即在第一版的 JavaScript 語言中，就包含了 OO 思想。換言之，JavaScript 是基於對象的開發語言。 雖然都是面向對象，但 JavaScript 與傳統的面向對象不太同樣，它使用了更高級但晦澀的繼承鏈方式，這就是咱們須要理解 prototype / _proto_ 這些技術棧的緣由。

3. 多人蔘與，開發的職責區分困難 因爲大型 SPA 項目的出現，頁面不只承載了用戶行爲，更多的是將後端主導的邏輯開發也帶到了前端。本來 MVC 中的 『M』比任何以往都要『重』，以致於在 『M』層，又造成了新的框架理論。所以瞭解並掌握 MVC / MVP / MVVM 等設計模式就變成了必要手段，進而前端框架開始流行。與其它語言同樣，選用現成的前端框架天然變成了趨勢，這些現代化框架的『設計思想』包含了前端開發新穎的理念， 如：操做虛擬 DOM（ Virtual DOM ）的 React；單純的踐行 MVC 理論的 Backbone.js；MVVM 風格的 AngularJS；等。學習並掌握前端框架能夠更好的區分職責，而框架統一的 API 實現了長時間多人開發/維護的可能性。

4. 雖然網絡帶寬獲得了很大的提升，但頁面的加載速度還是問題 因爲SPA 是單頁面應用，所以頁面在加載的時候幾乎包含了所有功能，但用戶每每卻只使用其中的一部分，因此網速的限制，帶寬的浪費，用戶的等待則是另外一個難題。**『模塊化開發』 是解決這類難題的銀彈，而 AMD / CMD 的理論天然成爲前端開發者們掌握的必要知識，而 requre.js / seajs 則是這些理論的具體實現方式。**因爲 Http 的特性所致 ( 分散的，小的靜態資源在加載的時候更慢 )，所以 合併/壓縮 則是另一個解決方案，所以也產生了一個新的問題，即第五個問題。

5. 靜態資源（ html/js/css/圖片等資源 ）過多致使上線時的重複性工做量增大 當這類靜態資源不多的時候，手動 合併/壓縮 並無問題，反之這些資源呈指數上升的時候，手動方案顯示不是一個好辦法。自動化方案 的引入勢在必行，而其中踐行者：grunt / gulp / webpack 就須要掌握了。

不掌握這些技術也能夠實現 JavaScript 開發，但掌握了這些技術棧可使咱們從 『繁重 / 繁瑣』的事務中抽離出來，更加 『專一於業務邏輯』。因此，恭喜你，歡迎來到新世界！！！

上述列舉的知識點僅僅屬於前端技術棧的一部分，除此之外還包括了：調試/測試，性能優化，CSS預編譯方式，編碼規則，SEO，移動 Web 開發等。

掌握這些技術後就萬事無憂了嗎？固然不，隨着前端開發的發展，總有一天，這些技術仍沒法知足開發。因此要了解這些技術棧背後的理論邏輯，以不變應萬變，方爲制勝之道！

技術全景

基礎技術

技術演進

對於前端技術的演進過程，主要都是爲了解決前端在大型項目開發過程當中遇到的問題，好比：包管理、模塊開發、多人協做、資源管理、打包構建、頁面加載等方面的問題，其演進過程主要分爲5條主線：JS編程語言、CSS編程語言、JavaScript模塊化、前端分層模式、前端自動構建。

演進	過程	目標	文章
JS編程語言	JavaScript、TypeScript、CoffeeScript、ES五、ES六、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	爲了解決前端開發中預處理、風格與測試、資源壓縮、靜態資源替換、模塊化處理、性能優化等問題	文章待續

參考資料

1. 現代前端技術解析目錄
2. 現代前端開發技術棧
3. 統一回復《怎麼學JavaScript？》