將 package.json 中的 Ionic 版本改為 2.0.0 的時候，我就思考一個問題。這個該死的問題是——我到底要用哪個框架繼續工作下去。

剛開始學習前端的時候，SPA（單頁面應用）還沒有現在這麼流行，可以選擇的框架也很少。而今天，我隨便開啟一個技術相關的網站、應用，只需要簡單的看幾頁，就可以看到豐富的前端框架世界 Angular 2、React、Vue.js、Ember.js。

當我還是一個新手程式設計師，我從不考慮技術選型的問題。因為不需要做技術選型、不需要更換架構的時候，便覺得框架豐富就讓它豐富吧，反正我還是用現在的技術棧。等到真正需要用的時候，依靠之前的基礎知識，我仍能很輕鬆地上手。

可是一旦需要考慮選型的時候，真覺得天彷彿是要塌下來一般。選擇 A 框架，則使用過 B 框架的可能會有些不滿。選用 B 框架，則使用 A 框架的人會有些不滿。選擇一個過時的框架，則大部分的人都會不滿。這點“小事”，也足夠讓你幾天幾夜睡不了一個好覺。

前端的選擇恐懼症

JavaScript學習交流群:615496236;
年輕的程式設計師都是好奇的貓，玩過一個又一個的前端框架。從毛球上弄出一條條的線，玩啊玩，最後這一個個的框架在腦子裡攪漿糊。

技術選型：不僅僅受技術影響

有太多的選擇，就是一件麻煩的事；沒有選擇時，就是一件更麻煩的事；有唯一的選擇時，事情就會變得超級簡單。

倘若，我是那個使用 Java 來開發 API 的少年，我會使用 Spring Boot 來作為開發框架。儘管 Java 是一門臃腫的語言，但保守的選擇不會犯上大錯。

倘若，我是那個使用 Python 來開發 Web 應用的少年，我會使用 Django 來作為開發框架。它可以讓我快速地開發出一個應用。

只可惜，我不再是一個後臺開發者，我不再像過去，可以直接、沒有顧慮的選擇。當我選擇 JavaScript 時，我就犯上了「選擇恐懼症」。技術選型也是沒有銀彈的——沒有一個框架能解決所有的問題。

在《Growth：全棧 Web 開發思想》一書中，我曾提到過影響技術選型的幾個因素。

這時，為了更好的考量不同的因素，你就需要列出重要的象限，如開發效率、團隊喜好等等。並依此來決定，哪個框架更適合當前的團隊和專案。

即使，不考慮前端框架以外的因素，那麼技術選型也是相當痛苦的一件事。

上線時間影響框架

每一個框架從誕生到受歡迎，都有其特定的原因和背景。不同的開發者選擇時，也是依據於其特定情景下的原因和背景。

如 Ruby On Rails誕生之時，帶來了極大的開發效率，而開發效率正是當時大部分人的痛點。我們知道 Ruby On Rails 是一個大而廣的框架，它可以提供開發者所需要的一切，開發者所需要做的就是實現業務程式碼。當開發效率不再是問題時，自由度變成了一些開發者的痛點，此時像 Sinatra 這樣的微框架就受這些人歡迎。

也因此，開發效率會在很大程度上影響技術選型。畢竟，開發效率在很大程度上決定了上線時間，上線時間很大地影響了技術選型。

• 用幾星期的時間來做一個網站，我首先想到的會是找一個模板。
• 用幾個月的時候來做一個網站，我仍然會想到找一個框架。
• 用幾個年的時間來做一個網站，我會想著是不是可以造幾個輪子。

遺憾的是，要遇到可以造輪子的專案不多。

錘子定律：你需要更大的視野

年輕的時候，學會了 A 框架，總覺得 Z 網站用 A 框架來實現會更好，一定不會像今天這樣經常崩潰、出Bug。**時間一長，有時候就會發現，Z 網站使用 A 不合適，他們的問題並不是框架的問題，而是運維的問題。

後來，出於對職業發展的探索，我開始瞭解諮詢師，看到一本名為《諮詢的奧祕》的書籍。在這其中，提到一個有意思的定律“錘子定律”（又稱為工具定律）——聖誕節收到一把錘子的孩子，會發現所有東西都需要敲打。 出現這種情況的主要原因是，開發者對一個熟悉的工具過度的依賴。

認真觀察，就會發現這個現象隨處可見。當一個新手程式設計師學會了某個最新的框架，通常來說這個框架有著更多的優點，這個時候最容易出現的想法是：替換現有的框架。可是，現有的框架並沒有什麼大的問題。並且憑估不充分時，新的框架則存在更多的風險。

並且，對於某個熟悉工具的過度依賴，特別容易影響到技術決策——看不到更多的可能性。這時候，我們就需要頭腦風暴。但是這種情況下，頭腦風暴很難幫助解決問題。

在這個時候，擁有更多專案、框架經驗的人，可能會做出更好的選擇。

前端框架一覽

在這個複雜的前端框架世界裡，我不敢自稱是有豐富的徒刑經驗。我只能去分享我用過的那些框架，讀者們再結合其他不同的框架來做決定。

jQuery, 使用生態解決問題

JavaScript學習交流群:615496236;
jQuery 創立之初的主要目標是，簡化 HTML 與 JavaScript 之間的操作，開發者可以輕鬆地使用 $('elment').doSomething() 的形式來對元素進行操作。

誕生之後，由於其簡單容易手、並且擁有豐富的外掛，幾度成為最受歡迎的前端框架。大部分動態互動效果，都能輕鬆地找到 jQuery 外掛。即使，沒有也能通過其 API，快速地編寫相應的外掛。

在很多人看來，jQuery 似乎是一個不會在未來用到的框架。可惜到了今天（2017年），我仍然還在專案中使用 jQuery 框架。一年前，我們仍在一個流量巨大的搜尋網站上使用用 jQuery。在這幾個專案上，仍然使用 jQuery 的原因，大抵有：

• 專案功能比較簡單。並不需要做成一個單頁面應用，就不需要 MV* 框架
• 專案是一個遺留系統。與其使用其他框架來替換，不如留著以後重寫專案

所以，在網際網路上仍有大量的網站在使用 jQuery。這些網站多數是 CMS（內容管理系統）、學校網站、政府機構的網站等等。對於這些以內容為主的網站來說，他們並不需要更好的使用者體驗，只需要能正確的顯示內容即可。

因此即使在今天，對於一般的 Web 應用來說，JavaScript 搭配 jQuery 生態下的外掛就夠用。然而，對於一些為使用者提供服務的網站來說，前端就不是那麼簡單。

Backbone.js，脊椎連線框架

從 Ajax 出現的那時候開始，前端便迎來了一個新的天地。後來，智慧手機開始流行開來。Web 便從桌面端往移動端發展，越來越多的公司開始製作移動應用（APP 和 移動網站）。jQuery Mobile 也誕生這個特殊的時候，然而開發起中大型應用就有些吃力。隨後就誕生了 Backbone、Angular 等等的一系列框架。

畢竟，作為一個程式設計師，如果我們覺得一個工具不順手，那麼應該造一個新的輪子。

Backbone.js 是一個輕量級的前端框架，其程式設計範型大致上匹配MVC架構。它為應用程式提供了模型(models)、集合(collections)、檢視(views)的結構。

Backbone 的神奇之處在於，在可以結合不同的框架在一起使用。就像脊椎一樣，連線上身體的各個部分。使用 Require.js 來管理依賴；使用 jQuery 來管理 DOM；使用 Mustache 來作為模板。它可以和當時流行的框架，很好地結合到一起。在今天看來，能結合其他前端框架，是一件非常難得的事。

遺憾的是，Backbone.js 有一些的缺陷，使它無法滿足複雜的前端應用，如 Model 模型比較簡單，要處理好 View 比較複雜。除此，還有更新 DOM 帶來的效能問題。

Angular，一站式提高生產力

JavaScript學習交流群:615496236;
與 Backbone 同一時代誕生的 Angular 便是一個大而全的 MVC 框架。

在這個框架裡，它提供了我們所需要的各種功能，如模組管理、雙向繫結等等。它涵蓋了開發中的各個層面，並且層與層之間都經過了精心調適。

我們所需要做的便是遵循其設計思想，來一步步完善我們的應用。Angular.js 的建立理念是：即宣告式程式設計應該用於構建使用者介面以及編寫軟體構建，而指令式程式設計非常適合來表示業務邏輯。

我開始使用 Angular.js 的原因是，我使用 Ionic 來建立混合應用。出於對製作移動應用的好奇，我建立了一個又一個的移動應用，也在這時學會了 Angular.js。對於我而言，選擇合適的技術棧，遠遠比選擇流行的技術棧要重要得多，這也是我喜歡使用 Ionic 的原因。當我們在製作一個應用，它對效能要求不是很高的時候，那麼我們應該選擇開發速度更快的技術棧。

對於複雜的前端應用來說，基於 Angular.js 應用的執行效率，仍然有大量地改進空間。在應用執行的過程中，需要不斷地操作 DOM，會造成明顯的卡頓。對於 WebView 效能較差或早期的移動裝置來說，這就是一個致命傷。

幸運的是在 2016 年底，Angular 團隊推出了 Angular 2，它使用 Zone.js 實現變化的自動檢測、

而遲來的 Angular 2 則受奧斯本效應osborne的影響，逼得相當多的開發者們開始轉向其它的框架。

React，元件化提高複用

從 Backbone 和 Angular.js 的效能問題上來看，我們會發現 DOM 是單頁面應用急需改善的問題——主要是DOM 的操作非常慢。而在單頁面應用中，我們又需要處理大量的 DOM，效能就更是問題了。於是，採用 Virtual DOM 的 React 的誕生，讓那些飽受效能苦惱的開發者歡迎。

JavaScript學習交流群:615496236;
傳統的 DOM 操作是直接在 DOM 上操作的，當需要修改一系列元素中的值時，就會直接對 DOM 進行操作。而採用 Virtual DOM 則會對需要修改的 DOM 進行比較（DIFF），從而只選擇需要修改的部分。也因此對於不需要大量修改 DOM 的應用來說，採用 Virtual DOM 並不會有優勢。開發者就可以創建出可互動的 UI。

除了編寫應用時，不需要對 DOM 進行直接操作，提高了應用的效能。React 還有一個重要思想是元件化，即 UI 中的每個元件都是獨立封裝的。與此同時，由於這些元件獨立於 HTML，使它們不僅僅可以執行在瀏覽器裡，還能作為原生應用的元件來執行。

同時，在 React 中還引入了 JSX 模板，即在 JS 中編寫模板，還需要使用 ES 6。令人遺憾的是 React 只是一個 View 層，它是為了優。為了完成一個完整的應用，我們還需要路由庫、執行單向流庫、web API 呼叫庫、測試庫、依賴管理庫等等，這簡直是一場噩夢。因此為了完整搭建出一個完整的 React 專案，我們還需要做大量的額外工作。

大量的人選擇 React 還有一個原因是：React Native、React VR 等等，可以讓 React 執行在不同的平臺之上。我們還能通過 React 輕鬆編寫出原生應用，還有 VR 應用。

在看到 Angular 2 升級以及 React 複雜性的時候，我相信有相當多的開發者轉而選擇 Vue.js。

Vue.js，簡單也是提高效率

引自官網的介紹，Vue.js 是一套構建使用者介面的漸進式框架，專注於MVVM 模型的 ViewModel 層。Vue.js 不僅簡單、容易上手、配置設施齊全，同時擁有中文文件。

對於使用 Vue.js 的開發者來說，我們仍然可以使用 熟悉的 HTML 和 CSS 來編寫程式碼。並且，Vue.js 也使用了 Virtual DOM、Reactive 及元件化的思想，可以讓我們集中精力於編寫應用，而不是應用的效能。

對於沒有 Angular 和 React 經驗的團隊，並且規模不大的前端專案來說，Vue.js 是一個非常好的選擇。

雖然 Vue.js 的生態與 React 相比雖然差上一截，但是配套設施還是相當齊全的，如 Vuex 、 VueRouter。只是，這些元件配套都由官方來提供、維護，甚至連 awesome-vue 也都是官方專案，總覺得有些奇怪。

除此，Vue.js 中定義了相當多的規矩，這種風格似乎由 jQuery 時代遺留下來的。照著這些規矩來寫程式碼，讓人覺得有些不自在。

和 React 相似的是，Vue.js 也有相應的 Native 方案 Weex，仍然值得我們期待。

大部分的框架並不只是那麼簡單。為了使用這個框架你，可能需要學習更多的框架、知識、理論。一個很好的例子就是 React，這個框架的開發人員，引入了相當多的概念，JSX、VIrtual Dom。而為了更好地使用 React 來開發，我們還需要引入其他框架，如 Redux、ES6 等等的內容。
這些框架從思想上存在一些差異，但是它們都有相似之處，如元件化、MV**、All in JS、模板引擎等等。
從JavaScript基礎滿足UI工程師條件;
到深入理解JavaScript特性與理論和實戰;
瞭解ECMAscript6新特性,瞭解服務端js並且學習,走向全棧;
可以加入JavaScript學習交流群:615496236;更多學習資料分享。