標籤:機制 頁面 開發 文法 rac 解決 資料驅動 模板 分支
Angular
選擇 Vue 而不選擇 Angular,有下面幾個原因,當然不是對每個人都適合:
在 API 與設計兩方面上 Vue.js 都比 Angular 簡單得多,因此你可以快速地掌握它的全部特性並投入開發。
Vue.js 是一個更加靈活開放的解決方案。它允許你以希望的方式組織應用程式,而不是任何時候都必須遵循 Angular 制定的規則。它僅僅是一個視圖層,所以你可以將它嵌入一個現有頁面而不一定要做成一個龐大的單頁應用。在配合其他庫方面它給了你更大的的空間,但相應,你也需要做更多的架構決策。例如,Vue.js 核心預設不包含路由和 Ajax 功能,並且通常假定你在應用中使用了一個模組構建系統。這可能是最重要的區別。
Angular 使用雙向繫結,Vue 也支援雙向繫結,不過預設為單向綁定,資料從父組件單向傳給子組件。在大型應用中使用單向綁定讓資料流易於理解。
在 Vue.js 中指令和組件分得更清晰。指令只封裝 DOM 操作,而組件代表一個自給自足的獨立單元 —— 有自己的視圖和資料邏輯。在 Angular 中兩者有不少相混的地方。
Vue.js 有更好的效能,並且非常非常容易最佳化,因為它不使用髒檢查。Angular,當 watcher 越來越多時會變得越來越慢,因為範圍內的每一次變化,所有 watcher 都要重新計算。並且,如果一些 watcher 觸發另一個更新,髒檢查迴圈(digest cycle)可能要運行多次。 Angular 使用者常常要使用深奧的技術,以解決髒檢查迴圈的問題。有時沒有簡單的辦法來最佳化有大量 watcher 的範圍。Vue.js 則根本沒有這個問題,因為它使用基於依賴追蹤的觀察系統並且非同步列隊更新,所有的資料變化都是獨立地觸發,除非它們之間有明確的依賴關係。唯一需要做的最佳化是在 v-for 上使用 track-by。
有意思的是,Angular 2 和 Vue 用相似的設計解決了一些 Angular 1 中存在的問題。
React
React.js 和 Vue.js 確實有一些相似 —— 它們都提供資料驅動、可組合搭建的視圖組件。當然它們也有許多不同。
首先,內部實現本質上不同。React 的渲染建立在 Virtual DOM 上——一種在記憶體中描述 DOM 樹狀態的資料結構。當狀態發生變化時,React 重新渲染 Virtual DOM,比較計算之後給真實 DOM 打補丁。
Virtual DOM 提供了一個函數式的方法描述視圖,這真的很棒。因為它不使用資料觀察機制,每次更新都會重新渲染整個應用,因此從定義上保證了視圖與資料的同步。它也開闢了 JavaScript 同構應用的可能性。
Vue.js 不使用 Virtual DOM 而是使用真實 DOM 作為模板,資料繫結到真實節點。Vue.js 的應用環境必須提供 DOM。但是,相對於常見的誤解——Virtual DOM 讓 React 比其它的都快, Vue.js 實際上效能比 React 好,而且幾乎不用手工最佳化。而 React,為了最佳化的渲染需要處處實現 shouldComponentUpdate 和使用不可變資料結構。
在 API 方面,React(或 JSX)的一個問題是,渲染函數常常包含大量的邏輯,最終看著更像是程式片斷(實際上就是)而不是介面的視覺呈現。對於部分開發人員來說,他們可能覺得這是個優點,但對那些像我一樣兼顧設計和開發的人來說,模板能讓我們更好地在視覺上思考設計和 CSS。JSX 和 JavaScript 邏輯的混合幹擾了我將代碼映射到設計的思維過程。相反,Vue.js 通過在模板中加入一個輕量級的 DSL (指令系統),換來一個依舊直觀的模板,且能將邏輯封裝進指令和過濾器中。
React 的另一個問題是:由於 DOM 更新完全交給 Virtual DOM 管理,當想要自己控制 DOM 時就有點棘手了(雖然理論上可以做到,但是這樣做就本質上違背了 React 的設計思想)。如果應用需要特別的自訂 DOM 操作,特別是複雜時間控制的動畫,這個限制就很討厭。在這方面,Vue.js 更靈活,有許多用 Vue.js 製作的 FWA/Awwwards 獲獎網站。
再多說幾句:
React 團隊雄心勃勃,計劃讓 React 成為通用平台的 UI 開發工具,而 Vue 專註於為 Web 提供實用的解決方案。
React,由於它的函數式特質,可以很好地使用函數式編程模式。但是對於初級開發人員和初學者這也導致較大的學習難度。Vue 更易學習並能快速投入開發。
對於大型應用,React 社區已經創造了大量的狀態管理方案,例如 Flux/Redux。Vue 本身不解決這個問題(React 核心也是),但是可以輕鬆地修改狀態管理員模式,實現一個類似的架構。Vue 有自己的狀態管理方案 Vuex,而且 Vue 也可以與 Redux 一起用。
React 的開發趨勢是將所有東西都放在 JavaScript 中,包括 CSS。已經有許多 CSS-in-JS 方案,但是所有的方案多多少少都有它的問題。而且更重要的是,這麼做脫離了標準的 CSS 開發經驗,並且很難和 CSS 社區的已有工作配合。Vue 的 單檔案組件 在把 CSS 封裝到組件模組的同時仍然允許你使用你喜歡的前置處理器。
Ember
Ember 是一個全能架構。它提供大量的約定,一旦你熟悉了它們,開發會很高效。不過,這也意味著學習曲線較高,而且不靈活。在架構和庫(加上一系列鬆散耦合的工具)之間權衡選擇。後者更自由,但是也要求你做更多的架構決定。
也就是說,最好比較 Vue.js 核心和 Ember 的模板與資料模型層:
Vue 在普通 JavaScript 對象上建立響應,提供自動化的計算屬性。在 Ember 中需要將所有東西放在 Ember 對象內,並且手工為計算屬性聲明依賴。
Vue 的模板文法可以用全功能的 JavaScript 運算式,而 Handlebars 的文法和協助函數文法相比之下非常受限。
在效能上,Vue 甩開 Ember 幾條街,即使是 Ember 2.0 最新的 Glimmer 引擎。Vue 自動批次更新,在效能比較關鍵時 Ember 要手工管理迴圈。
Polymer
Polymer 是另一個由 Google 支援的項目,實際上也是 Vue.js 的靈感來源之一。Vue.js 的組件可以類比為 Polymer 中的自訂元素,它們提供類似的開發體驗。最大的不同在於,Polymer 依賴最新的 Web 元件特性,在不支援的瀏覽器中,需要載入笨重的 polyfill,效能也會受到影響。相對的,Vue.js 無需任何依賴,最低相容到IE9。
另外,在 Polymer 1.0 中,為了效能Team Dev嚴格限制了它的資料繫結系統。例如,Polymer 模板支援的運算式僅有邏輯逆運算和簡單的方法調用。它的計算屬性實現得也不是很靈活。
最後,當發布到生產環境時,Polymer 元素需要用專用工具 vulcanizer 打包。相比之下,單檔案 Vue 組件能與 Webpack 無縫整合,因而你可以輕鬆在組件中使用 ES6 及任意 CSS 前置處理器。
Riot
Riot 2.0 提供類似的基於組件的開發模式(Riot 稱之為“標籤”),API 小而美。我認為 Riot 與 Vue 在設計思路上有許多相同點。不過,儘管比 Riot 重一點,Vue 提供了一些顯著優處:
- 真實的條件渲染,Riot 渲染所有的分支,然後簡單地顯示/隱藏它們。
- 一個強大得多的路由器,Riot 的路由 API 過於簡陋。
- 更成熟的工具鏈支援,見 Webpack + vue-loader。
- 過渡效果系統,Riot 沒有。
- 更佳的效能。Riot 實際上使用髒檢查而不是 Virtual DOM,因而遭受跟 Angular 一樣的效能問題。
原文地址http://www.cnblogs.com/shikyoh/p/5841105.html
Vue.JS 對比其他架構