Ember.js or Backbone.js for Restful backend [closed]

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 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.

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.

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.

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.

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.

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.

To give a brief, simplified answer: for a RESTful backend, at the moment, you should use Backbone.

To give a more complex answer: It really depends on what you're doing. As others have said, Ember is designed for different things, and will appeal to a different set of people. My short answer is based on your inclusion of the RESTful requirement.

At the moment, Ember-Data (which seems to be the default persistence mechanism within Ember) is far from production ready. What this means is that it has quite a few bugs and, crucially, doesn't support nested URIs (/posts/2/comments/4556 for example). If REST is your requirement, then you'll have to work around this for the time being if you choose Ember (i.e. you'll either have to hack it in, wait, implement something like Ember-Data from scratch yourself, or use not-very-RESTful URIs). Ember-Data is not strictly part of Ember, so this is entirely possible.

The main differences between the two, aside from size, are basically:

Ember tries to do as much as possible for you, so that you don't have to write as much code. It is very hierarchical and, if your app is also very hierarchical, will likely be a good fit. Because it does so much for you, it can be difficult to figure out where bugs are coming from and to reason why unexpected behaviour is happening (there is a lot of "magic"). If you have an app that fits naturally into the type of app that Ember expects you to be building though, this likely won't be a problem.

Backbone tries to do as little as possible for you so that you can reason about what is going on and build an architecture that fits your app (rather than building an app that fits the architecture of the framework you're using). It's a lot easier to get started with but, unless you're careful, you can end up with a mess very quickly. It doesn't do stuff like computed properties, auto-unbinding events, etc and leaves them up to you, so you will need to implement a lot of stuff yourself (or at least pick libraries that do that for you), although that is rather the whole point.

Update: It appears that, as of recently, Ember does now support nested URIs, so I suppose the question comes down to how much magic you like and whether Ember is a good fit, architecturally, for your app.

I think that your question will soon be blocked :) There are a few contentions between the two frameworks.

Basically Backbone does not do a lot of things, and that's why I love it : you will have to code a lot, but you will code at the right place. Ember does a lot of things, so you'd better watch what it is doing.

Server discussion is one of the few things that Backbone does, and it does a great job with it. So I would start with Backbone and then give a try to Ember if you are not totally satisfied.

You can also listen to this podcast where Jeremy Ashkenas, creator of Backbone, and Yehuda Katz, member of Ember, have a nice discussion