如何選擇合適的前端框架，告別選擇恐懼癥

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

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

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

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

前端的選擇恐懼癥

年輕的程序員都是好奇的貓，玩過一個又一個的前端框架。從毛球上弄出一條條的線，玩啊玩，最后這一個個的框架在腦子里攪漿糊。

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

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

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

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

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

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

技術選擇因素

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

PRI

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

上線時間影響框架

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

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

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

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

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

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

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

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

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

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

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

前端框架一覽

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

jQuery, 使用生態解決問題

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，一站式提高生產力

與 Backbone 同一時代誕生的 Angular 便是一個大而全的 MVC 框架。在這個框架里，它提供了我們所需要的各種功能，如模塊管理、雙向綁定等等。它涵蓋了開發中的各個層面，并且層與層之間都經過了精心調適。

我們所需要做的便是遵循其設計思想，來一步步完善我們的應用。Angular.js 的創建理念是：即聲明式編程應該用于構建用戶界面以及編寫軟件構建，而命令式編程非常適合來表示業務邏輯。

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

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

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

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

React，組件化提高復用

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

傳統的 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，仍然值得我們期待。

小結

除了上面提到的這些前端框架，我還用過 Reactive、Ember.js、Mithril.js，遺憾的是同 Vue.js 一樣，我沒有在大一點的、正式項目上用過。也因此，我沒有能力、經驗、精力去做更詳細的介紹。有興趣的讀者，可以做更詳細的了解，也可以在 GitHub (https://github.com/phodal/fe) 上給我們提交一個 Pull Request。

總結

今天，大部分的框架并不只是那么簡單。為了使用這個框架你，可能需要學習更多的框架、知識、理論。一個很好的例子就是 React，這個框架的開發人員，引入了相當多的概念，JSX、VIrtual Dom。而為了更好地使用 React 來開發，我們還需要引入其他框架，如 Redux、ES6 等等的內容。

這些框架從思想上存在一些差異，但是它們都有相似之處，如組件化、MV**、All in JS、模板引擎等等。欲知后事如何，請期待下一章。

1. 頗受歡迎的個人電腦廠商奧斯本，其公司的創新式便攜電腦還沒有上市，就宣布他們要推出的更高檔的機器，而又遲遲無法交貨，消費者聞風紛紛停止下單訂購現有機種，最后導致奧斯本因收入枯竭而宣布破產。 ?