用于 Restful 后端的 Ember.js 或 Backbone.js [英] Ember.js or Backbone.js for Restful backend

查看:13
本文介绍了用于 Restful 后端的 Ember.js 或 Backbone.js的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I already know that ember.js is a more heavy weight approach in contrast to backbone.js. I read a lot of articles about both.

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

I am asking myself, which framework works easier as frontend for a rails rest backend. For backbone.js I saw different approaches to call a rest backend. For ember it seems that I have to include some more libraries like 'data' or 'resources'. Why are there two libraries for this?

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

So whats the better choice? There arent a lot of examples to connect the frontend with the backend too. Whats a good working example for a backend rest call to this:

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

URI: ../restapi/topics GET auth credentials: admin/secrect format: json

推荐答案

与流行的观点相反,Ember.js 并不是 Backbone.js 的重量级方法".它们是针对完全不同的最终产品的不同类型的工具.Ember 的最佳点是用户将应用程序长时间保持打开状态的应用程序,可能是一整天,并且与应用程序的视图或底层数据的交互会触发视图层次结构的深刻变化.Ember 比 Backbone 大,但由于 ExpiresCache-Control 这仅在第一次加载时才重要.每天使用两天后,额外的 30k 将被数据传输所掩盖,如果您的内容涉及图像,则更快.

Contrary to popular opinion Ember.js isn't a 'more heavy weight approach' to Backbone.js. They're different kinds of tools that target totally different end products. Ember's sweet spot is applications where the user will keep the application open for long periods of time, perhaps all day, and interactions with the application's views or underlying data trigger deep changes in the view hierarchy. Ember is larger than Backbone, but thanks to Expires, Cache-Control this only matters on the the first load. After two days of daily use that extra 30k will be overshadowed by data transfers, sooner if your content involves images.

Backbone 非常适合具有少量状态的应用程序,在这些应用程序中,视图层次结构保持相对平坦,并且用户倾向于不经常访问应用程序或访问时间较短.Backbone 的代码变得简短而甜蜜,因为它假设支持 DOM 的数据将被丢弃,并且这两个项目都将被内存收集:https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone 较小的尺寸也使其更适合简短的交互.

Backbone is ideal for applications with a small number of states where the view hierarchy remains relatively flat and where the user tends to access the app infrequently or for shorter periods of time. Backbone's code gets to remain short and sweet because it makes the assumption that the data backing the DOM will get thrown away and both items will be memory collected: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone's smaller size also makes it better suited to brief interactions.

人们在这两种框架中编写的应用程序都反映了这些用途:Ember.js 应用程序包括 Square 的 Web 仪表板Zendesk(至少是代理/票务接口),以及Groupon的调度器:用户可能会花一整天时间在其中工作的所有应用程序.

The apps people write in both frameworks reflect these uses: Ember.js apps include Square's web dashboard, Zendesk (at least the agent/ticketing interface), and Groupon's scheduler: all applications a user might spend all day working in.

主干应用更关注简短或随意的交互,这些交互通常只是较大静态页面的一小部分:airbnb可汗学院,Foursquare的地图和列表.

Backbone apps focus more on brief or casual interactions, that are often just small sections of a larger static page: airbnb, Khan Academy, Foursquare's map and lists.

可以使用 Backbone 来制作 Ember 所针对的各种应用程序(例如 Rdio)增加您负责的应用程序代码的数量以避免内存泄漏或僵尸事件等问题(我个人不推荐这种方法)或 b)通过添加 3rd 方库,如 backbone.marionetteCoccyx - 这些库中有许多都试图提供类似的重叠功能并且您最终可能会组装自己的自定义框架,该框架比您刚使用 Ember 时更大并且需要更多的胶水代码.

You can use Backbone to make the kinds of applications that Ember targets (e.g. Rdio) by a) increasing the amount of application code you're responsible for to avoid problems like memory leaks or zombie events (I don't personally recommend this approach) or b) by adding 3rd party libraries like backbone.marionette or Coccyx – there are many of these libraries that all try to provide similar overlapping functionality and you'll probably end up assembling your own custom framework that is bigger and requires more glue code than if you'd just used Ember.

使用哪个"这个问题最终有两个答案.

Ultimately the question of "which to use" has two answers.

首先,在我的职业生涯中,我一般应该使用哪个":两者都一样,就像您最终会学习任何特定于您将来想做的工作的工具一样.你永远不会问Backbone 还是 D3?";Backbone 或 Ember"是一个同样愚蠢的问题.

First, "Which should I use, generally, in my career": Both, just like you'll end up learning any tools specific to work you'll want to do in the future. You'd never ask "Backbone or D3?"; "Backbone or Ember" is an equally silly question.

第二,我应该在下一个项目中具体使用哪个":取决于项目.两者都可以同样轻松地与 Rails 服务器通信.如果您的下一个项目涉及由服务器生成的页面与 JavaScript 提供的所谓丰富岛"的混合,请使用 Backbone.如果您的下一个项目将所有交互推送到浏览器环境中,请使用 Ember.

Second, "Which should I use, specifically, on my next project": Depends on the project. Both will communicate with a Rails server with equal ease. If your next project involves a mix of pages generated by the server with so-called "islands of richness" provided by JavaScript use Backbone. If your next project pushes all the interaction into the browser environment, use Ember.

这篇关于用于 Restful 后端的 Ember.js 或 Backbone.js的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆