Ember.js 和 Angular.js 的比较

本文编译自 Tom Dale（Ember.js 的核心开发人员）在 Quora 对一个问题的回答，深入对比了 Ember.js 和 Angular.js。

我是 Ember.js 的开发者之一，经常有人问我应该使用 Angular.js 还是 Ember.js？我认为在做出选择之前，你要知道自己想构建什么样的应用。

这两个框架表面上有一些相似之处：都使用绑定，都比其他框架（例如 Backbone.js）更易于开发 Web 应用。

我首先介绍一下 Ember.js 项目的由来。从 2009 年开始，我一直在苹果公司参与 SproutCore 的开发。这是一个类似于 Cocoa 的 JavaScript 开源框架，后来演变成了你现在看到的 iCloud。当时，我的周围都是一些世界上最最棒的 Cocoa 开发者。

多年来在客户端应用方面，似乎没有出现真正的新突破。自 80 年代开始，我们一直遵循一种固定的模式——代码运行在本地计算机上，从网络上获取数据，然后在本地处理，并显示在屏幕上。而如今唯一有变化的是，代码运行在浏览器的沙箱环境中，然后加载所需的“二进制”文件，用户不再需要把软件安装到自己的硬盘中。

在考虑这些问题时，我首先会想到：在我们之前，人们已经做了什么？我认为很难去争辩框架是否成功，以 Cocoa 为例，无论在 Mac 还是 iOS 上，Cocoa 都可以让开发者轻松编写受欢迎的应用。

我们希望开发者能够创建可以和原生应用竞争的 Web 应用。要做到这一点，首先开发者需要先进的工具和正确的概念，帮助他们沟通和协作。

在开发 Ember.js 的过程中，我们花了大量时间从一些原生应用的框架（例如 Cocoa）中引入一些概念，但后来我们觉得这些概念带来的困扰多于帮助，或者并不适合用来构建 Web 应用程序。因此，我们开始转向其他流行的开源项目，比如 Ruby on Rails 和 Backbone.js，从中寻找灵感。

因此，Ember.js 最终变成了一个综合的、强大的、符合现代 Web 特性的、轻量级的工具。

在我看来，与 Ember.js 相比，Angular.js 更像一个研究项目。这一点从二者使用的术语中可见一斑：Ember.js 使用的是模型、视图和控制器，而 Angular.js 让你学习作用域、指令和模板嵌入。

我完全支持这种研究项目，希望它们能变得更好。但是，要记住，应用是要放到生产环境的。

一些大公司已经在 Ember.js 上投入了时间和精力，比如新版 ZenDesk 已经使用 Ember.js 重写（他们对 Backbone.js 失望后，决定改用 Ember.js），Square 的整个 Web 层面都是基于 Ember.js 实现的（因为他们想要一个漂亮的响应式 UI），Groupon 的移动版 Web 应用也是使用 Ember.js 开发的。此外，还有很多创业公司通过 Ember.js 获得了成功，并开始向 Ember.js 社区贡献。

而我目前所看到使用 Angular.js 开发的大多数应用只是演示项目而已，或这是 Google 的内部项目。

我和 Yehuda（Ember.js 开发者之一）一直积极邀请真正的用户参与 Ember.js 框架的设计和维护，这可以确保我们在 Ember.js 中添加的功能在实际开发中有用。

事实上，过去几个月，大多数 Ember.js 的开发工作都是由社区的核心贡献组完成的，他们来自不同的公司。如果我和 Yehuda 哪天有什么事情，或者我们的公司倒闭了，Ember.js 还能持续发展。这是一个真正的社区项目，而不是“Google”的项目。

回到技术细节。Angular.js 的官网上写道“Angular.js是 HTML 的未来，其目的是构建 Web 应用。”阅读 Angular.js 应用的代码时能明确看出这一点——用户界面由 HTML 标记定义，并且使用有语义意义的属性（比如 data-ng-repeat）装饰。

而 Ember.js 使用 Handlebars 描述 HTML，来展现应用的界面。从美观角度上看，你可以想想自己更喜欢 Handlebars 的句法（例如 ``），还是更喜欢 Angular.js 那样通过额外的属性注解 HTML 的做法。我个人认为，HTML 属性有点杂乱，难以阅读。当然，你可以使用其中任何一种方式。如果 Ember.js 不存在，而我又必须使用一个使用数据属性的框架，那么我会考虑 Angular.js。

抛开美观不谈，我相信，Ember.js 使用基于字符串的模板也为我们带来了一些优势：

• 基于字符串的模板可以在服务器上预编译。这样可以减少启动时间，也意味着渲染模板可以像调用函数一样简单。
• Angular.js 需要在应用程序启动时遍历整个 DOM，应用越大，启动速度越慢。
• 如果想在服务器上渲染应用（让 Google 爬虫索引，或让首次加载的速度更快），Angular.js 需要启动整个浏览器环境，例如 PhantomJS，对资源消耗很大。而 Handlebars 完全就是 JavaScript 字符串，所以只需要 Node.js 或 Rhino 这样的东西。
• 如果应用越来越大，可以轻易分隔字符串模板，还可以使用惰性加载。

此外，Handlebars 只允许绑定属性，而 Angular.js 允许嵌入实时更新的任意表达式。很多人最初把这视为 Ember.js 的缺陷，但事实上：

• Ember.js 有简单的方法使用 JavaScript 创建可计算属性，可以包含任意表达式。
• 每次更新时，Angular.js 都必须重新计算这些表达式，这意味着需要在应用中绑定更多的元素，速度会变慢。
• 因为 Ember.js 只允许绑定属性，我们很容易利用 ECMAScript 6 的性能优势，如Object.observes。由于 Angular.js 发明了带有自定义解析器的 JavaScript 子集，所以很难优化代码。

一般情况下，Angular.js 依靠一种叫做“ 脏检查（dirty checking）”的机制来确定对象是否已经更改。“脏检查”的方式是，扫描每个对象和绑定的所有属性，比较当前值和之前已知的值。如果发生了变化，就要更新绑定。正如你能想到的那样，代码中对象越多，消耗就越高。

我认为这很好地说明了 Ember.js 和 Angular.js 理念上的区别。Ember.js 和 Angular.js 都力求简单和易用。而 Ember.js 使你不必担心代码中是否有超过 2000 个绑定。如果你在编写大型应用，那么你已经解决了你所担心的最大的事情。对于中小型应用来说，Angular.js 同样适用，因为这些应用不会触及 Angular.js 的限制区。

在 Ember.js 中，我们总是希望利用浏览器和语言中的新功能，以便使事情变得更容易。例如，一旦 ES6 的 代理对象可用，我们不会再要求你使用 get() 和 set() 方法。

这就是为什么我认为，如果想构建雄心勃勃的应用，应该选择 Ember.js。

我们从不拒绝从其他框架中吸取知识，因为这些框架已经知道构建大型应用的最佳方式。

我们已经有了一个梦幻般的社区，有一群最聪明的 Web 开发人员，他们致力于解决现实中遇到的难题。

此外，在开发过程中，我们对于性能方面和如何利用语言新特性方面也考虑了很久。Ember.js 是我和 Yehuda 一起开发的，他是 TC39 委员会（负责 JavaScript 下一个版本的制定）的成员，JavaScript 经验丰富。

我们已经发布了 1.0 版 API，因此你可以开始学习了，不用担心以后会有重大变化。