AngularJS 、Backbone.js 和 Ember.js 的比较 已翻译 100%

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 加起来还多，你自己看:

所有这些指标，显示的仅仅是每个框架的当前状态。看看哪个框架增长最快也是很有趣的，你有福了，通过谷人希的趋势跟踪，你可以得到以下答案:

http://www.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)，而且你还有可能还有一些第三方插件要加进来。

5 模板

Angular 和 Ember 都有模板引擎。而另一方面 Backbone，把这个选择权留给了你。感受模板引擎的异同最好的办法就是上点代码，好的，我们开始。我们将演示把一个列表转换成 HTML 列表的例子。

5.1 AngularJS

Angular 的模板引擎仅仅是在 HTML 上使用绑定表达式。而绑定表达式又仅仅是两层大括号而已:

<ul>
  <li ng-repeat="framework in frameworks" 
      title="{{framework.description}}">
    {{framework.name}}
  </li>
</ul>

5.2 Backbone.js

Backbone 可以和许多第三方模板引擎集成，默认的选择是 Underscore 模板。 因为 Underscore 是 Backbone 的依赖项，你已经把它加载到页面中了，你无须添加任何额外的依赖关系就可以使用它的模板引擎。不爽的是，Underscore 的模板引擎非常初级，你通常不得不把 javascript 混进去，比如说:

<ul>
  <% _.each(frameworks, function(framework) { %>
    <li title="<%- framework.description %>">
      <%- framework.name %>
    </li>
  <% }); %>
</ul>

5.3 Ember.js

Ember 当前使用的是 Handlebars 模板引擎，热门的 Mustache 模板引擎的扩展。现在还有一个新的叫做 HTMLBars 的 Handlebars 变种可用。Handlebars 不关心 DOM – 它所做的仅仅是做一个简单的字符串变换。而 HTMLBars 则可以处理 DOM，所有的变量转换都有上下文感知。由于 HTMLBars 还没有流行，我们还是来看看用 Handlebars 方式打印列表方式:

<ul>
  {{#each frameworks}}
    <li {{bind-attr title=description}}>
      {{name}}
    </li>
  {{/each}}
</ul>

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 模板里面声明绑定就可以了:

<input ng-model="user.name" type="text" />
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 表达式 在视图层被广泛应用。表达式语言非常强大，有时候是强大过头了。这诱导开发者使用各种复杂的逻辑，甚至执行赋值运算和计算全部都放在模板中。把逻辑运算放在模板中让它非常难以测试，因为它变成不可能独立测试了。看看下面的例子，演示了如何滥用这种模板语言的:

<button ng-click="(oldPassword && checkComplexity(newPassword) && oldPassword != newPassword) ? (changePassword(oldPassword, newPassword) && (oldPassword=(newPassword=''))) : (errorMessage='Please input a new password matching the following requirements: ' + passwordRequirements)">Click me</button>

许多情况下，指令名称的拼写错误，或者调用未定义 scope 方法，都会被忽略，并且很难被发现，特别是当你把复杂的指令 API 和上面提到的 scope 的继承弄到一起的时候。我见过有些苦逼花费一大堆时间抓耳挠腮想找出为什么 scope 中的一个绑定的事件没被回调函数触发，最后居然是因为用了驼峰(camelCase)命名，而没有用连字符分隔(hyphen-separated)拼写属性的名称(比如说这).