首先要特別說明一下，作者認為以下四個功能是十分重要的：
- UI Bindings（UI綁定）：作者想說的不僅僅是模板，而是想談一種在底層模型出現變化時，視圖層能夠自動相應地更新的陳述性方法。一旦您用過了支持UI Binding的框架（例如Flex）就很難放手回頭了。
- Composed Views（模塊化視圖）：與所有的軟件開發者一樣，作者也喜歡編寫模塊化、可重用的代碼。基於這樣的原因，當給UI編程的時候，作者喜歡使用視圖的方法來創作（個人更偏好在模板層時使用），當然這樣也就需要擁有足夠豐富的視圖組件來支持。關於這一點有一個可重用的頁面小工具的范例。
- Web Presentation Layer（web表示層）：我們是在為web編寫程序，最不想要的就是Native風格的小工具；但是也沒有什么理由來為一個web框架來創建它自己的布局管理器。HTML和CSS是目前解決樣式與布局的最好的方法，他們被這樣應用着，框架也應該以這一點為核心。
- Play Nicely With Others（兼容，友好）：不得不承認，jQuery是十分犀利的。作者不喜歡那種綁定着一個sub-par jQuery副本的框架，而直接推薦使用jQuery的那種框架才是作者需要的。
候選方案
下面這個表格列出了12個框架對於上述幾種特性的支持關系，在后面的部分會詳細敘述，您也可以在之后的文章中點擊相應的鏈接來獲取更多的信息。
1. Backbone.js
Backbone.js是web最火的框架，如果不了解它將寸步難行，眾多知名品牌均支持該框架，令人印象深刻，自然地成為作者最先進行嘗試的框架。作者用它來建造了一個Group Talent內部用行政管理方面功能的feature應用。
優點：強大的社區，還有大量的實力支持。例如它本身就較多地使用了Underscore.js（也是一個強大的框架）。
缺點：抽象功能不夠強，以及一些需要的功能還沒實現。整個框架十分輕量級，產出的結果是一大堆引用文件和樣板：而且應用的規模越大這一點就會越明顯。
2. SproutCore 1.x
SproutCore最開始是蘋果公司用於其iCloud上面的。除了名字起得很不好之外，它實際上是一個非常優秀的框架，也是最大的框架之一。
優點：支持綁定，忠實的社區粉絲，優秀的feature很多。
缺點：過於死板，難以去除無用的feature，強制使用一種Native風格的范例，嚴重的問題在於該框架不允許使用HTML來做布局。
3. Sammy.js
Sammy是作者偶然發現的一個比較小的框架，因為它太簡化了，基本不能占據列表的席位。其核心feature是一個路由系統，讓應用與AJAX進行交換。
優點：簡單的學習曲線，與服務器端的app集成更加容易。
缺點：太過於簡單，對於大型應用就有些捉襟見肘。
4. Spine.js
器如其名，Spine顯然是受到Backbone的強烈影響，像Backbone一樣也是一個非常輕量級的框架，遵循相似的模型。
優點：輕量級，文檔做得很好。
缺點：從根本上就有缺陷。Spine的一個核心概念是“一個堅果外殼中的一堆異步的UI集，這意味着UI應該是在理想化條件下永遠不會阻塞的”。而做了一系列的非阻塞式實時應用之后，作者可以說這簡直是不現實的，除非后端是像Operational Transformation之類的。
5. Cappuccino
Cappuccino是一款更加獨特的框架，自帶編程語言Objective-J，還能嘗試着在瀏覽器中仿真Cocoa。
優點：大型的構想出的框架，良好的社區環境，強大的繼承模型。
缺點：在您所有能用Javascript仿真的語言之外，Objective-C是作者最不想選用的。它起源一位iOS開發人員，作者到現在還沒想明白用瀏覽器編寫Objective-J是什么意思。
6. Knockout.js
K.O.是一個MVVM框架，受到其支持者的大量好評。它強調陳述式UI綁定和自動UI刷新。
優點：支持綁定，文檔做得出色，引導系統超級贊。
缺點：綁定語法晦澀，缺乏堅實的視圖組件層次結構。作者希望能夠輕松地重用組件，也覺得定義成一個MVVM框架是有害的。這些框架中基本沒有MVC，但都是（MVP,MVVM之類的）的變種。
7. Javascript MVC
作者的興趣是充分地披露各種框架，對Js MVC並沒有花太多時間來評估。
優點：堅實的社區基礎和積累。
缺點：基於Strings的繼承模型很尷尬，控制器太接近視圖又缺乏綁定機制。命名方式太不受保護了，相當於這樣的情況：如果RoR可以說是“Rudy web Framework”的簡寫。
8. Google Web Toolkit
GWT是一系列的客戶端工具包，除了框架之外還包含很多其他工具。它可以把java語言編譯成Javascript，支持標准Java庫的一個子集，最初是Google公司使用在Wave上面的。
優點：綜合寬泛的框架，擁有強大的社區支持。基於Java的堅實組件繼承模型，在巨型客戶端應用上表現出色。
缺點：除了Google說的之外，GWT將經不住時間的檢驗。就好像最初DART那樣，很明顯Java不是web的未來。更嚴重的是，客戶端對於Java的抽象有一點不合適。
9. Google Closure
如果說Google Closure僅僅是一個js框架，倒不如說更像是一個工具包。附帶編譯器和優化器。
優點：由Google用在其很多主流app上面。良好的基於組件的UI編寫系統。
缺點：不支持UI綁定。
10. Ember.js
Ember（之前是SproutCore 2.0）是競爭者中的新丁。它是一個嘗試：從SproutCore2.0中抽取分離其核心feature並轉變成為一個更加緊湊的模型框架，更加適合web。
優點：特別豐富的模板系統，擁有可編寫的視圖和UI綁定。
缺點：由於太新，文檔跟不上。
11. Angular.js
Angular是在作者發布評估結果之后才發現的一個很好的框架，由Googler開發，包含了很多有趣的設計選擇。
優點：關於模板的范圍和控制器的設計考慮的很周到。具有依賴注入系統（作者本人是一個iOS粉絲）。支持豐富的UI綁定語法，從而使得過濾和轉換這樣的工作開銷很小。
缺點：代碼庫很不健全，也不夠模塊化。視圖也不夠模塊化（關於這點在Batman.js的缺陷中討論的更加細致）
12. Batman.js
Batman由Shopify創作，是另一款與Knockout和Angular具有相似脈絡的框架。Batman擁有良好的UI綁定系統，是基於HTML屬性的。Batman是唯一的一款使用慣用語法Coffeescript編寫的框架，並且緊密地與NODE.Js集成在一起，甚至可以到擁有其（可選的）Node.js服務器的程度。
優點：代碼庫十分清晰，綁定方法優良又簡單，耐用，流程化。
缺點：作者非常不喜歡這種“獨行俠”式的作風，更不用說這種加強單一控制器的主意了。與Knockout和Angular一樣，在組件嵌套的時候遭受同樣的折磨。作者需要的不僅僅是模板，還更想要陳述式的可重用的模板框架。相比，Ember在框架之上擁有的是一個基於EMBER他們自己的邏輯（可能是在控制器層上的）的整套組件能陳述式重用的方法。
贏家
最終，Ember.js是能滿足作者全部需求的唯一一款框架。最近作者將一個小的Backbone應用轉換成了Ember來實驗，除了一些性能方面的小問題之外，作者對於產生的代碼庫更為欣慰。由Yehuda Katz支持，整個圍繞Ember.js技術討論社區也十分奇妙：這一定會是一個值得期待的好框架。