最走心的前端開發技術棧（概覽）

在前端大全微信公號後臺收到不少以下這樣的留言反饋

• 我該如何學習、提高前端開發水平？

• 前端開發涉及到哪些技能點？

• 能不能推薦經典的前端開發技術書籍？

• ……

若是你也有相似的困惑，這份 Web 前端開發技能棧就是爲你準備的。它的目標是作成一份前端開發入門、進階的參考指南。目前已經出爐的是概覽部分，後續還會補充前端開發的技能點列表和各類擴展閱讀資料。若是你對這份參考指南有任何反饋，請在評論中留言告訴咱們。謝謝！

如下是正文

這篇文章並無單純的羅列出前端開發涉及到的技術棧，而是探尋這些技術棧背後的『祕密』，適合初學者以及想要了解這些『祕密』的閱讀者。如僅想了解前端開發技術棧的話，請持續關注前端技能棧 https://github.com/jobbole/web-skill-set

開篇：

工欲善其事，必先利其器。

出自：《論語·衛靈公》

前言：

因爲 JavaScript 的語法很簡單，因此上手容易，基本上少則數週就能夠開發項目了，但這就是 JavaScript 的所有嗎？顯然不是！不少剛接觸 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 項目一般須要解決哪些問題？

• 外部引用包的管理；

• 過多的代碼致使的項目更新，迭代，重構難題；

• 多人蔘與，開發職責區分困難；

• 雖然網絡帶寬獲得了很大的提升，但頁面的加載速度還是問題；

• 靜態資源（ html/js/css/圖片資源等 ）過多致使上線時的重複性工做量增大；

外部引用包的管理：

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；MVM 風格的 AngularJS 等。學習並掌握前端框架能夠更好的區分職責，而框架統一的 API 實現了長時間多人開發/維護的可能性。

雖然網絡帶寬獲得了很大的提升，但頁面的加載速度還是問題：

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

靜態資源（ html/js/css/圖片等資源 ）過多致使上線時的重複性工做量增大：

當這類靜態資源不多的時候，手動 合併/壓縮 並無問題，反之這些資源呈指數上升的時候，手動方案顯示不是一個好辦法。自動化方案 的引入勢在必行，而其中踐行者：grunt / gulp / webpack 就須要掌握了。

思考：

上述大可能是『 非官方機構 / 開發者社區 』創造出來的技術棧，推進 JavaScript 發展的 ECMAScript 官方組織在作什麼？難道當前 『最in』 JavaScript ，實際上是個過期的產物？

答案固然是錯的，ECMAScript 早已公佈了 它的第六個版本：ECMAScript 6（ 2015年6月正式發佈 ）

ECMAScript 6：

它最重要的特性（之一）就是包含了：Class（ 原生 OOP ） 和 Module（ 原生模塊化 ）方案。

結論：

不掌握這些技術也能夠實現 JavaScript 開發，但掌握了這些技術棧可使咱們從 『繁重 / 繁瑣』的事務中抽離出來，更加 『專一於業務邏輯』。

上述技術的掌握能使咱們更好的融入現代化的前端開發中來。

結語：

若是你看到這裏的話，那麼恭喜你，歡迎來到新世界！！！

彩蛋1：

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

彩蛋2：

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

彩蛋3：

• 類似的技術棧，如何取捨？

• 只要是大型項目就都須要這些技術棧嗎？

• 爲何使用了框架後，仍是以爲開發慢？

• 使用了 xxx 後，並無實際解決個人問題？

想弄懂它們？，請關注前端技能棧 https://github.com/jobbole/web-skill-set

參考文獻：

• ECMAScript is an object-oriented

• ECMAScript 6 語言描述

• ECMAScript 6 瀏覽器兼容表

• 瀏覽器兼容性問題 連接 及 瀏覽器大戰

• Chrome V8 解析器