用于 Restful 后端的 Ember.js 或 Backbone.js [关闭]

Posted 2023-02-19

【中文标题】用于 Restful 后端的 Ember.js 或 Backbone.js [关闭]

【英文标题】：Ember.js or Backbone.js for Restful backend [closed]

【发布时间】：2012-10-11 09:36:45

【问题描述】：

我已经知道 ember.js 是一种比backbone.js 更重要的方法。我阅读了很多关于两者的文章。

我在问自己，哪个框架更容易作为 rails rest 后端的前端。对于backbone.js，我看到了调用rest后端的不同方法。对于余烬，我似乎必须包含更多的库，如“数据”或“资源”。为什么有两个库呢？

那么更好的选择是什么？也没有很多例子可以将前端与后端连接起来。后端休息调用的一个很好的工作示例：

URI：../restapi/topics 得到 身份验证凭据：admin/secrect 格式：json

【问题讨论】：

一定要喜欢一个“不具建设性”的问题，但这个有用且经过深思熟虑的答案仍然获得了 240 多票。

【参考方案1】：

我认为您的问题很快就会被阻止:) 这两个框架之间存在一些争论。

基本上，Backbone 不会做很多事情，这就是我喜欢它的原因：你必须编写很多代码，但你会在正确的地方编写代码。 Ember 做了很多事情，所以你最好看看它在做什么。

服务器讨论是 Backbone 所做的为数不多的事情之一，而且它做得很好。所以我会从 Backbone 开始，如果你不完全满意，我会尝试 Ember。

您还可以收听 this podcast，其中 Backbone 的创建者 Jeremy Ashkenas 和 Ember 的成员 Yehuda Katz 进行了精彩的讨论

【讨论】：

谢谢。你对 ember 的 rets 扩展有什么看法。更好地利用数据或资源？能举个简单的rest api调用例子吗？

简短的回答是图书馆一直在变化，我不能根据我以前的经验给你一个回应（我自己做了评估）。我认为这篇文章会告诉你更多：***.com/questions/8623091/ember-js-rest-api

我已经看过这篇文章了。这就是我问的原因:)

@NicolasZozol 哪个播客？链接？

javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkenas 从二月份回来。这是在这些框架在重叠领域中并不真正存在之前变得更加清晰。你可以听到 Yehuda 和 Jeremy 只是互相交谈，并没有真正进行任何比较。

【参考方案2】：

与流行的观点相反，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。

【讨论】：

很好的回应，Trek。只是想在这里评论一下Expires 和Cache-Control 的帮助远比人们想象的要少——尤其是在经常忽略它们的移动设备方面。我记得有一个版本的 ios 完全忽略了它们（但仍然听 html5 缓存清单）。此外，这些标头值在用户第一次访问期间无济于事——这通常是决定用户是否会留下并使用您的应用程序的最关键。说所有 30kb 的文件差异对我来说似乎没什么大不了的。这是原始的还是缩小和压缩后的 30k 差异？

如果您查看 Ember 旨在帮助创建的样式的实际应用程序，您会发现无法逃避那些讨厌的 kb。它们要么来自 Ember 并且您的应用程序代码更小，要么来自主干插件，要么来自您自己编写的代码。 Wunderlist，您认为这将是“简单”的时钟，传输量约为 300kb。我想它与 Ember 的大小相似，也许更小——我从来没有写过一个精确的副本 Wunderlist 我不能 100% 肯定地说。

我同意，我最流行的主干应用程序的时钟大小为 178kb+模板压缩和缩小。只是指出我们不应该依赖浏览器缓存。

Trek，您对在具有扩展使用模式和复杂状态管理的应用程序中使用 Backbone 的分析是正确的。我经历了将遗留应用程序转换为 Backbone 的经验，并且必须完全按照您列出的方式进行操作。我们需要集成 Marionette 并编写大量粘合代码，用于路由前/后过滤、内存泄漏缓解和更好的事件管理。

“你永远不会问 Backbone 或 D3”——当然，但我可以很容易地想象一个项目，我会将 D3 与 Backbone 结合使用。可能很难想象在一个页面上同时使用 Backbone 和 Ember 的项目。所以，我觉得“Backbone or Ember”这个问题很公平。这是我发现的另一篇信息量很大的帖子，因为它更深入地比较了这两个框架：net.tutsplus.com/tutorials/javascript-ajax/…

【参考方案3】：

给出一个简短的简化答案：对于 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 在架构上是否合适，为您的应用程序。

【讨论】：

“至关重要的是，不支持嵌套 URI（例如 /posts/2/cmets/4556）”这是几周前的相关提交：github.com/emberjs/data/commit/…。它知道要跟上一个快速发展的预发布框架可能很困难，但在与权威人士交谈和提供建议时，我们应该始终以准确为目标！

酷，谢谢。更新了我的答案。我想这是在上周左右的大关系合并中引入的。我确实查看并阅读了列出的更改，但找不到任何提及 url 的内容，并且当我检查它们时，我正在跟踪的问题仍然存在。感谢您指出提交 - 在不知道它的存在的情况下很难找到它。

确实来自最近的关系改进分支合并。我们一直在慢慢跟进旧问题并在本周关闭它们。