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

剛開始學習前端的時候，SPA（單頁面應用）尚未如今這麼流行，能夠選擇的框架也不多。而今天，我隨便打開一個技術相關的網站、應用，只須要簡單的看幾頁，就能夠看到豐富的前端框架世界 Angular 二、React、Vue.js、Ember.js。

 

當我仍是一個新手程序員，我從不考慮技術選型的問題。由於不須要作技術選型、不須要更換架構的時候，便以爲框架豐富就讓它豐富吧，反正我仍是用如今的技術棧。等到真正須要用的時候，依靠以前的基礎知識，我仍能很輕鬆地上手。

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

前端的選擇恐懼症

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

 

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

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

 

假若，我是那個使用 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, 使用生態解決問題

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 則受奧斯本效應[osborne]的影響，逼得至關多的開發者們開始轉向其它的框架。

[osborne]: 頗受歡迎的我的電腦廠商奧斯本，其公司的創新式便攜電腦尚未上市，就宣佈他們要推出的更高檔的機器，而又遲遲沒法交貨，消費者聞風紛紛中止下單訂購現有機種，最後致使奧斯本因收入枯竭而宣佈破產。

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 層，它是爲了優化 DOM 的操做而誕生的。爲了完成一個完整的應用，咱們還須要路由庫、執行單向流庫、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 (phodal/fe) 上給咱們提交一個 Pull Request。

總結

今天，大部分的框架並不僅是那麼簡單。爲了使用這個框架你，可能須要學習更多的框架、知識、理論。一個很好的例子就是 React，這個框架的開發人員，引入了至關多的概念，JSX、VIrtual Dom。而爲了更好地使用 React 來開發，咱們還須要引入其餘框架，如 Redux、ES6 等等的內容。