我已经知道 ember.js 是一种比backbone.js 更重量级的方法。我读了很多关于两者的文章。
我在问自己，哪个框架更容易作为 rails rest 后端的前端。对于backbone.js，我看到了调用rest后端的不同方法。对于余烬，我似乎必须包含更多的库，如“数据”或“资源”。为什么有两个库呢？
那么更好的选择是什么？也没有很多例子可以将前端与后端连接起来。后端休息调用的一个很好的工作示例：
URI：../restapi/topics 获取身份验证凭据：admin/secrect 格式：json
与流行的观点相反，Ember.js 并不是 Backbone.js 的“重量级方法”。它们是针对完全不同的最终产品的不同类型的工具。Ember 的最佳点是用户将应用程序长时间保持打开状态的应用程序，可能是一整天，并且与应用程序视图或底层数据的交互会触发视图层次结构的深刻变化。Ember 比 Backbone 大，但多亏了Expires，Cache-Control这仅在第一次加载时很重要。经过两天的日常使用，额外的 30k 将被数据传输所掩盖，如果您的内容涉及图像，则更快。
Backbone 非常适合具有少量状态的应用程序，其中视图层次结构保持相对平坦，并且用户倾向于不经常访问应用程序或访问时间较短。Backbone 的代码变得简短而甜蜜，因为它假设支持 DOM 的数据将被丢弃，并且这两个项目都将被内存收集：https ://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone 的较小尺寸也使其更适合简短的交互。
人们在这两个框架中编写的应用程序都反映了这些用途：Ember.js 应用程序包括Square 的 Web 仪表板、Zendesk（至少是代理/票务界面）和Groupon 的调度程序：用户可能整天都在使用的所有应用程序。
Backbone 应用程序更侧重于简短或随意的交互，这些交互通常只是较大静态页面的一小部分：airbnb、可汗学院、Foursquare 的地图和列表。
您可以使用 Backbone 来制作 Ember 所针对的应用程序类型（例如Rdio），方法是 a) 增加您负责的应用程序代码量以避免内存泄漏或僵尸事件等问题（我个人不推荐这种方法）或者 b) 通过添加诸如主干.marionette或Coccyx 之类的 3rd 方库——这些库中有许多都试图提供类似的重叠功能，您最终可能会组装自己的自定义框架，该框架更大并且需要更多的胶水代码如果您刚刚使用过 Ember。
最终，“使用哪个”的问题有两个答案。
首先，“在我的职业生涯中，我通常应该使用哪个”：两者都一样，就像您最终会学习任何特定于您将来想做的工作的工具一样。你永远不会问“Backbone 还是 D3？”；“骨干还是余烬”是一个同样愚蠢的问题。
第二，“我应该在下一个项目中具体使用哪个”：取决于项目。两者都可以同样轻松地与 Rails 服务器通信。如果您的下一个项目涉及由服务器生成的页面与 JavaScript 提供的所谓“丰富岛”的混合，请使用 Backbone。如果您的下一个项目将所有交互推送到浏览器环境中，请使用 Ember。
给出一个简短的、简化的答案：对于 RESTful 后端，目前，您应该使用 Backbone。
给出一个更复杂的答案：这真的取决于你在做什么。正如其他人所说，Ember 是为不同的事物而设计的，并且会吸引不同的人群。我的简短回答是基于您包含 RESTful 要求。
目前，Ember-Data（这似乎是 Ember 中的默认持久性机制）还远未做好生产准备。这意味着它有很多错误，而且至关重要的是，它不支持嵌套 URI（例如 /posts/2/comments/4556）。如果 REST 是您的要求，那么如果您选择 Ember，那么您将不得不暂时解决这个问题（即，您要么必须破解它，等待，自己从头开始实现类似 Ember-Data 的东西，要么不使用-非常RESTful URI）。Ember-Data 严格来说不是 Ember 的一部分，所以这是完全可能的。
两者之间的主要区别，除了尺寸，基本上是：
Ember 试图为您做尽可能多的事情，这样您就不必编写尽可能多的代码。它是非常分层的，如果您的应用程序也非常分层，那么它可能非常适合。因为它为您做了很多事情，所以很难弄清楚错误来自哪里以及为什么会发生意外行为（有很多“魔法”）。如果您的应用程序自然适合 Ember 期望您构建的应用程序类型，那么这可能不会成为问题。
Backbone 尝试为您做尽可能少的事情，以便您可以推断正在发生的事情并构建适合您的应用程序的架构（而不是构建适合您正在使用的框架架构的应用程序）。上手要容易得多，但除非你小心，否则很快就会一团糟。它不做计算属性、自动解除绑定事件等事情，而是让你自己决定，所以你需要自己实现很多东西（或者至少选择为你做这些的库），尽管那是而是重点。
更新：最近看来，Ember 现在确实支持嵌套 URI，所以我想问题归结为您喜欢多少魔法以及 Ember 在架构上是否适合您的应用程序。
我认为您的问题很快就会被阻止:) 这两个框架之间存在一些争论。
基本上 Backbone 不会做很多事情，这就是我喜欢它的原因：你必须编写很多代码，但你会在正确的地方编写代码。Ember 做了很多事情，所以你最好看看它在做什么。
服务器讨论是 Backbone 所做的为数不多的事情之一，它在这方面做得很好。所以我会从 Backbone 开始，如果你不完全满意，我会尝试使用 Ember。
您还可以收听这个播客，其中 Backbone 的创建者 Jeremy Ashkenas 和 Ember 的成员 Yehuda Katz 进行了精彩的讨论