AngularJS 、Backbone.js 和 Ember.js 的比较
1 介绍
我们准备在这篇文章中比较三款流行于Web的“模型-视图-*”框架：AngularJS、Backbone和Ember。为你的项目选择正确的框架能够对你及时交付项目的能力和在以后维护你自己代码的能力产生巨大影响。你也许想基于一款可靠的、稳定的和成熟的框架来构建项目，但又不想为此受到约束。Web发展迅速——新技术产生，旧的那套方法很快跟不上潮流。如此形势之下，我们准备仔细深入的比较这三个框架。
2 框架概览
今天我们提到的所有框架有许多共同点:都是开源的，遵从 MIT 协议，并且都尝试通过 MV* 模式来解决开发单页面应用的问题。它们都有类似的概念:视图，事件，数据模型和路由。我们先简单回顾一下有关的历史和背景知识，然后再展开深入比较这三款框架。
AngularJS 诞生于 2009 年，当时作为一个大型商业产品的一部分叫做 GetAngular。不久之后，Misko Hevery，GetAngular 项目创建者之一，花了仅仅三周时间，用 GetAngular 重写了一个曾经耗时 6 个月才完成的，有 17K 行代码的页面应用，并将代码削减到 1,000 行左右，于是成功的说服了谷歌开始赞助该项目，并将其开源，也就是我们今天看到 AngularJS 。Angular 的特点是拥有双向数据绑定，依赖注入，易于测试的编码风格，以及通过使用自定义指令可以简单的扩展 HTML。
Backbone.js 是一个轻量级的 MVC 框架。诞生于 2010 年，它作为那种笨重全功能的 MVC 框架，比如说 ExtJS， 的一个代替品，迅速流行开来。 很多服务都使用了它，比如 Pinterest, Flixster, AirBNB 等等。
Ember 则要回溯到 2007 年，最开始是以 SproutCore MVC 框架展现在世人面前，由 SproutIt 开发，后来是 Apple，再后来到 2011 的时候，jQuery 和 Ruby on Rails 的核心贡献者 Yehuda Katz 参与了进来。有名的 Ember 用户包括了 Yahoo!, Groupon, 和 ZenDesk。
3 社区
社区是在选择一个框架的时候，要考虑的最重要因素之一。大社区意味着更多的答案，更多的第三方模块，更多的 YouTube 教程…你，明白了么。我做了个统计，截止 2014年8月16日，Angular 是绝对的王者，作为 GitHub 上第六大星级项目，在 StackOverflow 上的提问比 Ember 和 Backbone 加起来还多，你自己看:
Github 的点赞星数
27.2k
18.8k
11k
第三方模块
800 ngmodules
236 backplugs
21 emberaddons
栈爆网的提问件数
49.5k
15.9k
11.2k
YouTube 件数
~75k
~16k
~6k
GitHub 贡献者
928
230
393
Chrome 插件用户
150k
7k
38.3k
指标
AngularJS
Backbone.js
Ember.js
所有这些指标，显示的仅仅是每个框架的当前状态。看看哪个框架增长最快也是很有趣的，你有福了，通过谷人希的趋势跟踪，你可以得到以下答案:
http://google.com/trends/explore?hl=en-US#q=ember.js,+angularjs,+backbone.js&cmpt=q
4 框架大小
页面的加载时间是你网站成功的关键。当涉及浏览速度的时候，用户没太多耐性 — 所以很多情况下你要尽可能让你的应用跑得越快越好。使用框架，有两个因素会对应用的加载时间产生影响: 框架的大小和它启动的时间。
Javascript 资源通常都会被经过精简和压缩，所以我们来比较一下压缩版。但是只看框架的大小肯定不够的。Backbone.js，尽管是最小的 (只有 6.5kb)，但是必须 Underscore.js (5kb) 和 jQuery (32kb) 或者 Zepto (9.1kb)，而且你还有可能还有一些第三方插件要加进来。
AngularJS 1.2.22
39.5kb
39.5kb
Backbone.js 1.1.2
6.5kb
43.5kb (jQuery + Underscore)
20.6kb (Zepto + Underscore)
Ember.js 1.6.1
90kb
136.2kb (jQuery + Handlebars)
框架
净大小
包含依赖之后的大小
5 模板
Angular 和 Ember 都有模板引擎。而另一方面 Backbone，把这个选择权留给了你。感受模板引擎的异同最好的办法就是上点代码，好的，我们开始。我们将演示把一个列表转换成 HTML 列表的例子。
5.1 AngularJS
Angular 的模板引擎仅仅是在 HTML 上使用绑定表达式。而绑定表达式又仅仅是两层大括号而已:
title="{{framework.description}}"> {{framework.name}}
5.2 Backbone.js
Backbone 可以和许多第三方模板引擎集成，默认的选择是 Underscore 模板。 因为 Underscore 是 Backbone 的依赖项，你已经把它加载到页面中了，你无须添加任何额外的依赖关系就可以使用它的模板引擎。不爽的是，Underscore 的模板引擎非常初级，你通常不得不把 javascript 混进去，比如说:
<% _.each(frameworks, function(framework) { %>
<%- framework.name %>
<% }); %>
5.3 Ember.js
Ember 目前用的是 Handlebars 模板引擎，热门的 Mustache 模板引擎的扩展。一个新的 Handlebars 变种，叫做 HTMLBars ，目前已经可以使用了。Handlebars 不关心 DOM – 它所做的仅仅是做一个简单的字符串变换。而 HTMLBars 则可以处理 DOM，所有的变量转换都有上下文感知。由于 HTMLBars 还没有流行，我们还是来看看用 Handlebars 方式打印列表方式:
{{#each frameworks}}
{{name}}
{{/each}}
6 AngularJS
6.1 好处
Angular 为 Web 开发带来了许多创新的概念。双向数据绑定节省了大量的样板代码。比如下面的 jQuery 代码片段:
$('#greet-form input.user-name').on('value', function() {
$('#greet-form div.user-name').text('Hello ' + this.val() + '!');
});
由于 Angular 的双向绑定，你根本就不需要自己写代码。只需要在 HTML 模板里面声明绑定就可以了:
Hello {{user.name}}!
Promises 在 Angular 中扮演了一个重要的角色。Javascript 是单线程，基于事件循环的语言，这意味着许多操作(比如说网络通讯)都是以异步方式进行的。异步的 Javascript 代码会很快的就陷入了长长的嵌套回调，也就是臭名昭著的 “Pyramid Code” 或者叫做 “Callback Hell”。
相对比另外两个，Angular 不光有着更大的社区，更多的在线文档，而且还有谷歌在背后的推广和支持。所以，核心团队还在不断增长，产出更多的创新，以及改善开发生产效率的工具，比如: Protractor, Batarang, ngmin 和 Zone.js，一抓一大把。而且，开发团队还向用户征集需求。比如说，Angular 2.0 的所有设计文档你都可以从 这里 找到，任何人都可以直接给设计文档提建议。
Angular 帮助你把构建应用的程序块划分为下面这几种类型：控制器(Controller)，指令(Directive)，工厂(Factory)，过滤器(Filter)，服务(Service)和视图(View) (就是模板)。它们被组织为模块形式，之后可以被另一个引用。每种类型有不同的作用。视图处理 UI，控制器处理 UI 背后的逻辑，服务用来处理和后台的通信，并且将共通的有关联的功能组件结合在一起，而指令通过定义新的元素，属性和行为，很容易的构造可重用的组件，以及HTML扩展。
自动脏值检查意味着，你不需要用 getter 和 setter 去访问数据模型 — 你可以修改任意范围(scope)的任意属性，然后 angular 会自动检测到变化，通知该属性的所有观察者(watcher)。
“Angular 的初衷是写出可测试的代码。” 单元测试指南中的这句话，包含了太多意思 – Angular 确实很注重分离，单元隔离，为 $http 和 $timeout 等基础内置服务提供了现成的，强大的 mock。
6.2 痛处
Angular 常被人诟病的是指令那复杂的 API。 Transclusion，尤为突出，这个概念，把许多开发者搞得一头雾水，让你满脑子各种概念，比如编译函数(compiling function)，linking，函数的预处理/后处理(pre/post linking functions)，各种 scope 类型 (transclusion/isolate/child scope)，还有各种配置设置，需要相当的时间来掌握。
Angular 中的 scope 层次结构使用的是 Prototypal 继承，这又是一个为了迎合从面向对象语言，比如 Java 和 C#，过来的开发人员而提出的概念。不理解 scope 导致许多开发者开发很受伤 (比如说: 这, 这 还有这)。
Angular 表达式 在视图层被广泛应用。表达式语言非常强大，有时候是强大过头了。这诱导开发者使用各种复杂的逻辑，甚至执行赋值运算和计算全部都放在模板中。把逻辑运算放在模板中让它非常难以测试，因为它变成不可能独立测试了。看看下面的例子，演示了如何滥用这种模板语言的:
许多情况下，指令名称的拼写错误，或者调用未定义 scope 方法，都会被忽略，并且很难被发现，特别是当你把复杂的指令 API 和上面提到的 scope 的继承弄到一起的时候。我见过有些苦逼花费一大堆时间抓耳挠腮想找出为什么 scope 中的一个绑定的事件没被回调函数触发，最后居然是因为用了驼峰(camelCase)命名，而没有用连字符分隔(hyphen-separated)拼写属性的名称(比如说这).
最后，是 Angular 的循环系统中, 要注意那“神奇的”脏值检查，它经常会给开发者惊喜。在非-Angular上下文运行的时候，很容易忘记调用 $digest() (例子)。也就是说，你必须非常小心，不要触发缓慢的观察者事件或者无限循环(例子: 这, 这 还有 这)。通常，对于一页上有大量的交互元素的页面，Angular会变得非常慢。有个很好的界定是，不要在同一页面上放超过 2,000 个活动的绑定。
7 Backbone.js
7.1 好处
Backbone 轻量，快速，内存占用小。学习曲线也是很平缓的，只需要几个简单的概念就能掌握 (模型/集合, 视图, 路由)。它有很棒的文档，代码简单，注释详细，并且这里还有一个注释版源码，用来解释框架的工作细节。实际上你可以通读整个框架的源码，用不到一个小时去熟悉它。
因为又小又基础，你可以基于 Backbone 打造你自己的框架。一些基于 Backbone 的第三方框架的例子有 Aura, Backbone UI, Chaplin, Geppetto, Marionette, LayoutManager, Thorax, Vertebrae。用 Angular 和 Ember 你一般都要用框架作者给你的选择，有些可能会不适合你的工程需求和个人风格。Angular 2.0 承诺改变这种情况，通过构建更小的独立模块，使你可以选择和组合它们。不过我们还没看到它什么时候才能交付。
7.2 痛处
Backbone 没有提供基本构造。它仅仅是提供了一些基础工具让你去创建，让你去决定如何构造应用，这有太多空要填了。比如说内存管理需要小心的处理。由于缺失视图生命周期管理，这会使得路由/状态的变化，很容易导致内存泄漏，除非你可以很清楚的处理一切。
诚然，Backbone本身不提供的功能，可以由第三方插件来填补，这也就意味着，在你创建应用的时候，有很多选择，因为一个功能通常有许多个备选插件。比如说，内嵌模型可以由下面这些插件提供:Backbone.DocumentModel, BackBone.NestedTypes, Backbone.Schema, Backbone-Nested, backbone-nestify, 这还是其中的一小部分。决定哪个更适合你的工程是需要调查的，这需要时间 — 而使用框架的一个主要目的是节省你的时间。
Backbone 缺乏对双向数据绑定的支持，意思也就是说，你必须编写大量的样板来处理模型更新之后触发的视图更新。看看上面给出的例子，想想看 Angular.js 的双向数据绑定削减了多少样板代码。
Backbone 中的视图是直接操作 DOM 的，这让它们非常难做单元测试，也就更脆弱，更难以重用。常见的例子就是用 CSS 选择器查找 DOM 元素，改变CSS 类名，添加有同样类名的新元素或者把同样的 DOM 树包装到另一个元素，都会打乱你的 CSS 选择器以及应用的渲染。
8 Ember.js
8.1 好处
Ember.js 主张约定优于配置。也就是说，无需编写大量的样板代码，Ember 会自动推导出许多配置本身，比如在定义一个路由资源的时候，可以自动判定路由的名称和控制器。Ember 甚至会在你没定义控制器的时候，自动为你的资源生成一个。
Ember 包含了一个优秀的路由和一个可选的数据层，叫做 ember data。和其他两个框架不同，它们的数据层非常小(Backbone 的集合/模型和 Angular 的 $resource)，Ember 有一个拿来即用的非常成熟的数据模块，只需要简单的配置，就可以和后台的 Ruby-on-Rails 或者其它的 RESTful JSON API 集成得非常好。它还可以通过设置 fixtures来支持面向 mock API 开发以及测试。
性能是 Ember.js 设计的主要目标。诸如 The Run Loop 这个概念，可以确保数据的变化只导致单个 DOM 更新，即使同一块数据进行了多次更新也是一样，还有计算属性的缓存, 还有可以在编译时或在服务端对 HandleBars 模板进行预编译的能力，都可以帮助你保证应用的负载，保证它跑得足够快。
8.2 痛处
Ember 的 API 在它稳定版出来之前变化太大了。这导致了有大量的过期内容和不能再运行的例子，这会新进开发者开始使用这个框架时感到非常困惑。看看 Ember Data 变更日志，你就会知道我说的是什么意思了。这里有太多的大变更了，这就让许多栈爆网的回答和编码例子变得毫无意义了(比如说这)。
Handlebars 为了保持模板和数据模型一致，用了太多的