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，所以你能够开始学习了，不用担忧之后会有重大变化。