我已经知道 ember.js 是一种比backbone.js 更重要的方法。我阅读了很多关于两者的文章。
我在问自己，哪个框架更容易作为 rails rest 后端的前端。对于backbone.js，我看到了调用rest后端的不同方法。对于余烬，我似乎必须包含更多的库，如“数据”或“资源”。为什么有两个库呢？
那么更好的选择是什么？也没有很多例子可以将前端与后端连接起来。后端休息调用的一个很好的工作示例：
URI：../restapi/topics 得到 身份验证凭据：admin/secrect 格式：json
【问题讨论】：
标签： ruby-on-rails rest backbone.js ember.js frontend
我认为您的问题很快就会被阻止:) 这两个框架之间存在一些争论。
基本上，Backbone 不会做很多事情，这就是我喜欢它的原因：你必须编写很多代码，但你会在正确的地方编写代码。 Ember 做了很多事情，所以你最好看看它在做什么。
服务器讨论是 Backbone 所做的为数不多的事情之一，而且它做得很好。所以我会从 Backbone 开始，如果你不完全满意，我会尝试 Ember。
您还可以收听 this podcast，其中 Backbone 的创建者 Jeremy Ashkenas 和 Ember 的成员 Yehuda Katz 进行了精彩的讨论
【讨论】：
与流行的观点相反，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's web dashboard、Zendesk（至少是代理/票务接口）和 Groupon's scheduler：用户可能整天工作的所有应用程序在。
主干应用更侧重于简短或随意的交互，通常只是较大静态页面的一小部分：airbnb、Khan Academy、Foursquare's map and lists。
您可以使用 Backbone 来制作 Ember 所针对的各种应用程序（例如 Rdio）a) 增加您负责的应用程序代码的数量以避免内存泄漏或僵尸事件等问题（我个人不推荐这种方法）或b）通过添加像backbone.marionette或Coccyx这样的第三方库 - 有很多这些库都试图提供类似的重叠功能，而您最终可能会组装自己的自定义框架，该框架比仅使用 Ember 更大并且需要更多的胶水代码。
“使用哪个”这个问题最终有两个答案。
首先，“在我的职业生涯中，我一般应该使用哪个”：两者都一样，就像您最终会学习任何特定于您将来想做的工作的工具一样。你永远不会问“Backbone 还是 D3？”； “Backbone 或 Ember”是一个同样愚蠢的问题。
第二，“我应该在下一个项目中具体使用哪个”：取决于项目。两者都可以同样轻松地与 Rails 服务器通信。如果您的下一个项目涉及由服务器生成的页面与 JavaScript 提供的所谓“丰富岛”的混合，请使用 Backbone。如果您的下一个项目将所有交互推送到浏览器环境中，请使用 Ember。
【讨论】：
Expires 和Cache-Control 的帮助远比人们想象的要少——尤其是在经常忽略它们的移动设备方面。我记得有一个版本的 iOS 完全忽略了它们（但仍然听 HTML5 缓存清单）。此外，这些标头值在用户第一次访问期间无济于事——这通常是决定用户是否会留下并使用您的应用程序的最关键。说所有 30kb 的文件差异对我来说似乎没什么大不了的。这是原始的还是缩小和压缩后的 30k 差异？
给出一个简短的简化答案：对于 RESTful 后端，目前，您应该使用 Backbone。
给出一个更复杂的答案：这真的取决于你在做什么。正如其他人所说，Ember 是为不同的事物而设计的，并且会吸引不同的人群。我的简短回答是基于您包含 RESTful 要求。
目前，Ember-Data（这似乎是 Ember 中的默认持久性机制）还远未准备好生产。这意味着它有很多错误，而且至关重要的是，它不支持嵌套 URI（例如 /posts/2/cmets/4556）。如果 REST 是您的要求，那么如果您选择 Ember，那么您将不得不暂时解决这个问题（即，您要么必须破解它，等待，自己从头开始实施类似 Ember-Data 的东西，要么不使用-非常RESTful URI）。 Ember-Data 严格来说不是 Ember 的一部分，所以这是完全可能的。
两者的主要区别，除了尺寸，基本上是：
Ember 尝试为您做尽可能多的事情，这样您就不必编写尽可能多的代码。它是非常分层的，如果您的应用程序也非常分层，那么它可能非常适合。因为它为您做了很多事情，所以很难弄清楚错误来自哪里以及为什么会发生意外行为（有很多“魔法”）。如果您的应用自然适合 Ember 期望您构建的应用类型，那么这可能不是问题。
Backbone 尽可能少地为您做事，以便您可以推断正在发生的事情并构建适合您应用的架构（而不是构建适合您正在使用的框架架构的应用）。上手要容易得多，但除非你小心，否则很快就会一团糟。它不执行计算属性、自动取消绑定事件等操作，而是由您自己决定，因此您需要自己实现很多东西（或者至少选择为您执行此操作的库），尽管那是而是重点。
更新：最近看来，Ember 现在确实支持嵌套 URI，所以我想问题归结为您喜欢多少魔法以及 Ember 在架构上是否合适，为您的应用程序。
【讨论】：