JavaScript富應用MVC MVVM框架

對框架的挑選 Ember.js、Backbone.js、Knockout.js、Spine.js、Batman.js ， Angular.js

1. 輕量級的應用選擇哪個會比較好？
2. 那一個比較簡單，容易上手
3. 哪個開發週期最短？

具體能夠看   (英) Rich JavaScript Applications – the Seven Frameworks

                        Web前端開發：爲什麼選擇MVVM而非MVC

因爲工做關係~一直沒時間細細研究下這些框架的源碼~ 早期就看過Backbone.js與EXT4的MVC

最近開始研究業界小有名氣司徒正美的mvvm框架avalon

爲何放着Angular，Ember不去分析,而去研究avalon呢, 看了http://rubylouvre.github.io/mvvm/

其實做者就是基於Angular，Ember，knockout這種成熟的框架中，演化出來的avalon，因此avalon我不說媲美這些框架，可是從研究的角度入手，我以爲未必不可

核心的功能avalon都可以完成，只是組件不夠多，畢竟是我的行爲的 ,  avalon 源碼分析目錄 , 博主已經開始研究angular,儘可能同步推出源碼分析

 

對比：

1. angular是找大而面的道路，所以體積很是龐大，1.6-1.7萬行；
2. avalon旨在提供一種遠離DOM操做的前端開發體驗，0.6.3只有2420行，min只有29kb。
3. avalon從angular抄來了很多好東西，如{{}}插值表達式，ms-model（經過事件實現雙向同步），ms-controller（爲了VierModel指定做用域範圍），但都作了加強，{{aaa|html}添加html過濾器就能輸出innerHTML，ms-model能夠經過data-observe來開關雙向同步，ms-controller擁有孿生兄弟ms-important。
4. avalon的$watch與ms-bind方法提供比angular強大得多回調功能。
5. avalon擁有像knockout, emberjs那樣的計算屬性， angular沒有。
6. avalon與angular都擁有監控數組，但avalon的監控數組像knockout那樣擁有大量好用的方法，能自動同步頁面，angular的則至關弱。
7. avalon與angular都擁有定義UI的功能（將一個元素變成一個UI組件），angular是使用自定義標籤，avalon是使用ms-ui屬性，但自定義標籤在舊式IE並很差使，而且可能隨着瀏覽器的升級，瀏覽器會添加一個與你如出一轍的新標籤。avalon則安全多了，而且擁有12UI組件可作參考，實現起來很是簡單。
8. avalon是採起邊掃描邊轉換綁定的策略，用戶打開頁面後當即能看到效果，angular是要所有掃描後才轉換綁定，所以用戶可能看到一些奇異的模板。
9. avalon是經過define方法來定義ViewModel，並有scan方法指定做用的元素與ViewModel。angular要求用戶將xxxxCtrl函數暴露到全局做用域下，框架本身去取去組裝。
10. avalon在ViewModel有個$json，就是ViewModel對應的純數據的Model（ViewModel每次被操做，都會自動同步View與Model的），咱們能夠直接將它放到AJAX中使用。angular沒有獨立的Model,須要本身轉換。
11. avalon是使用Object.defineProperty與VBS實現ViewModel，angular則是將整個xxxxCtrl函數進行編譯，轉換一大堆getter, setter從而實現雙向綁定，所以angular的體積是至關龐大的。
12. avalon的綁定值但是ViewModel的屬性或數組或表達式， angular則容許用戶在視圖定義新變量，新對象，這是個很差的特徵，會讓頁面很是難維護。
13. avalon的綁定已經強大到讓用戶徹底脫離DOM寫業務，頂可能是取一下表單元素的checked, disabled等狀態值，angular仍是傳統的思路，只是在1.0後添加數據綁定機制。

其實說了一堆，並不是是說angular不夠好avalon超過angular，正如做者所說angular是找大而面的道路，所以體積很是龐大，就跟EXT同樣想什麼都想攬着.

 

各個框架的技術速覽

Backbone

• 做者：Jeremy Ashkenas and DocumentCloud
• 內容：
  • Model-View模式，MIT 許可
  • 最小的類庫——僅僅一個文件，800行代碼！
  • 很專注的功能——僅僅提供REST持久化模型以及簡單的路由和回調，這樣就可讓你知道何時去渲染實體（須要本身設置渲染機制）
  • 最著名的，被許多大牌網站使用（或許是由於它小而易於被接受）
• 優勢：
  • 它很小，你能夠在使用以前經過讀源代碼來弄懂它。
  • 對你的服務端架構和文件結構都沒有影響，能夠只在頁面的一小部分起做用，並不須要考慮整個頁面。
  • Jeremy就像一個禪宗大師，對全部的問題都頗有觀點。他就像一個大人指導着一羣吵鬧的孩子。
• 項目地址：GitHub ，官網
• 發佈時間：兩年前

Meteor

• 做者：Meteor開發團隊，他們剛剛得到了1120萬美圓的融資因此能夠全職開發Meteor
• 內容：
  • 這是一個來自將來世界的使人驚訝的框架，它擁有你所沒有見過的東西（可能除了Derby)
  • 在服務端（Node.js + Mongo）和客戶端使用相同的代碼，使兩者(包括數據庫）連通起來.經過WebSockets來同步服務端和全部的客戶端。
  • 當修改代碼時就能夠「實時部署」——客戶端會快速更新而不會丟失他們的內容。
  • 若是提供視頻觀看會更加合適【演示】
  • 和其餘的人同樣，我真心但願這個項目會成功——WEB開發須要一些像這樣有激情的項目來向前推動。
• 優勢：當你收購了web開發的一些陳規舊俗，Meteor可讓你走在前沿。
• 項目地址： GitHub,官網
• 發佈時間：還是早期版本，目前我不知道有哪些網站正式使用Meteor。可是它的核心團隊正在認真地作着這個項目。

Ember

• 做者: Yehuda Katz (Rails和Jquery的先前開發者),Ember團隊已經 Yehuda 的夥伴Tilede
• 內容:
  • 它包含創建一個"強大的Web應用"的一切,採用的是MIT許可
  • 在全部的框架中是功能最強大,固然庫的大小也很大.
  • 它的着眼點在於怎樣把怎樣把一個頁面分解成一個個有層次的控件,而後經過一個有狀態的路由系統來鏈接起來.
  • 正在開發更加精細的數據接入類庫(Ember.Data)
  • 會在運行時對全部的頁面控制,所以對於使用了不少內容的部分(如silverlight,ajax,flash)可能不合適.
  • 文件結構和URL都是固定的,可是能夠被重寫.
  • 其設計靈感來自Rails和Cocoa
  • 使用:它爲Rails提供工程模版(你也能夠經過手動配置來使它應用在別的服務端技術上)
• 優勢:常見的問題應該有常見的解決方法--Ember提供了全部的常看法決方案,你只須要考慮對你的應用程序來講那個是適用的.
• 項目地址GitHub,官網;
• 開始時間: 仍然不是1.0的發佈版本,不過很快會發布,API到時候也會發布(**譯者注:已經發布1.0的pre版本)

AngularJS

• 做者:google的開發者,主要是他們內部使用,而且採用MIT協議
• 內容:
  • MVW(Model-View-Whatever )模式
  • 基於DOM的模版聲明式綁定.
  • 內置基礎的url路由和數據序列號
  • 工具:他們實現了一個可讓你在調試時監視你的數據模型的chrome的調試插件,以及一個針對Jasmine 測試框架的插件
• 優勢:
  • 按照他們所宣傳的，這是一個將來瀏覽器會原生支持的框架，因此咱們應該如今就用這種方式來編程。
  • 對服務器端的架構和文件結構沒有影響，能夠用在不須要對整個頁面控制的小部分。
• 項目地址： GitHub,官網
• 開始時間：已發佈（曾在google使用過）

Knockout

• 做者： Knockout團隊和社區（包括我在內目前核心團隊有三個成員）
• 內容：
  • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
  • 關注與富UI：基於DOM的聲明式綁定，擁有自動依賴檢測的"觀察者「模型
  • 不強制綁定URL路由和數據——和其餘第三方庫結合（例如使用Sammy.js作路由，採用ajax方式存儲數據）。
  • 着重關注於易用性，有大量的文檔和交互的例子
• 特色：
  • 專一於UI,支持IE6
  • 對服務器架構和文件系統沒有影響。能夠用在不須要對整個頁面控制的小部分。
• 項目地址： GitHub,官網
• 開始時間： 發佈將近兩年

Spine

• 做者： Alex MacCaw
• 內容：
  • MVC in JavaScript, MIT license
  • 最初做爲O’Reilly一本書的示例代碼，最終演變爲一個開源代碼工程
  • 是Backbone的一個克隆版本（就像名字那樣）（譯者注：Spine和Backbone都有脊柱的意思)
• 特色：你但願用不一樣的方式來使用Backbone兩者不一樣能夠參看這裏
• 項目地址： GitHub,官網
• 開始時間： 已經發布1.0.0版本

Batman

• 做者：Shopify團隊（一個電子商務平臺公司）
• 內容：
  • 支持Javascript的MVC架構，幾乎是爲Rails+CoffeeScript開發者設計的。MIT 許可
  • 定製性最強的一個框架，你必須按照它的約定（例如文件結構和URL路徑），不然，就像它」高傲「的做者們所說的：「不遵循約定就別用」。 *全棧式的框架，擁有豐富的模型，視圖和控制器及路由。固然也有觀察模式的機理。 *基於DOM的模版
• 特色： 若是你使用Rails和CoffeeScript，你會駕輕就熟……
• 項目地址： GitHub,官網
• 開始時間：目前是0.9版，預計在將來幾個月內發佈1.0版本。

CanJS

• 做者：bitovi團隊（一個js諮詢培訓公司）
• 內容：
  • MVC in JavaScript, MIT licensed
  • REST-persistable模型，基礎的路由，基於字符串的模版。
  • 並不很出名（我在上週前還不知道它），儘管它是一個很老的javascript mvc項目的從新開放。
• 特色：致力於構建一個輕量的，提供上述全部框架都具備功能特性的最好的框架。
• 項目地址： GitHub,官網

總結

若是你在考慮究竟那個是最適合你的項目，我以爲應該考慮兩個方面：

• 應用範圍： 你但願一個框架或者類庫可以幫助你作多少東西？你是但願有一個可讓你從0開始全程都爲你提供架構幫助的全能框架，仍是但願本身定製模式和類庫？無論選擇那種，對不一樣的項目和團隊都是有價值的。

• 設計美學：你是否看過這些框架而且想本身構建一個小型的類庫？你喜歡這樣作嗎？不要根據侷限與描述或者功能列表去選擇。忽略你本身的編碼習慣就像僅僅根據小說的目錄去買書或者是根據我的簡歷和履從來選擇配偶。

除了不一樣的地方，我能夠確定上述這些技術都遵循的一個功能：模型和視圖分離。這是一種在20年錢就已經存在的經典設計模式。即便你在構建最簡單的web應用界面你也能從這種模式中受益。