Ember.js or Backbone.js for Restful backend

Question

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.

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 GET auth credentials: admin/secrect format: json

Solution 1

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.

Solution 2

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.

Solution 3

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

Comments

[Robin Wieruch]

Thank you. What can you say about the rets extensions of ember. Better use data or resource? Can you give a simple example of a rest api call?

[Nicolas Zozol]

Short answer is that libraries varies all the time and I can't give you a response based on my previous experience (I did it on myself for evaluation). I think this post will tell you more than I can : stackoverflow.com/questions/8623091/ember-js-rest-api

[Robin Wieruch]

I already saw this post. Thats why I asked :)

[Nicolas Zozol]

So the fallback is to try both by yourself, as often ;) And you'll see wich one match the best your particular problem. Or start with Backbone which is not opiniated and more stable.

[Mauvis Ledford]

Great response, Trek. Just wanted to comment here that Expires and Cache-Control help far less than people think—especially in terms of mobile devices which often ignore them. I remember a version of iOS ignored them completely (but still listend to HTML5 cache manifest). Additionally these header values won't help during the first visit from a user—which generally is the most critical in deciding whether the user will stay and use your app. Saying all that 30kb file difference doesn't seem like that big of a deal to me. Is that raw or a minified and gzipped 30k difference?

[deepak]

@NicolasZozol which podcast? link ?

[Trek Glowacki]

If you go look at actual applications that are the style Ember is intended to help create, you'll find there's no escaping those pesky kbs. Either they're coming from Ember and your application code is smaller, or they're coming from backbone plugins, or they're coming from code you write yourself. Wunderlist, which you'd think would be "simple" clocks in at around 300kb of transfer. I'd imagine it'd be similarly sized with Ember, perhaps smaller – having never written an exact copy Wunderlist I can't say with 100% certainty.

[Mauvis Ledford]

I agree, my most popular backbone app clocks in at 178kb+templates compressed and minified. Just pointing out how we shouldn't rely on browser caching.

[Trek Glowacki]

"crucially, doesn't support nested URIs (/posts/2/comments/4556 for example)" Here's the relevant commit from a couple weeks ago: github.com/emberjs/data/commit/…. It know it can be hard to keep up with a rapidly moving, pre-release framework, but we should always aim for accuracy when speaking with authority and offering advice!

[bengillies]

Cool, thanks. Updated my answer. I presume that was introduced in the big relationship merge last week or so. I did have a look and read through the changes listed but could find no mention of urls and the issues I was tracking were still open when I checked them. Thanks for pointing out the commit - it can be hard to locate without already knowing its existence.

[Trek Glowacki]

It is indeed from the recent merge of the relationship-improvements branch. We've been slowly following up on old issues and closing them this week.

[Trek Glowacki]

javascriptjabber.com/004-jsj-backbone-js-with-jeremy-ashkena‌​s from back in February. This is before it become clearer that these frameworks didn't really exist in overlapping arenas. You can hear Yehuda and Jeremy just talking past each other, not really doing any comparisons.

[Nicolas Zozol]

Oups, yes it's this one. Well I remmeber that at the beginning, they are taunting a bit, but I'm french and I may have misunderstood.

[Mike Clymer]

Trek, you are spot on with your analysis of using Backbone in apps with extended usage patterns, and complex state management. I went through the experience of converting a legacy app over to Backbone and had to do exactly what you listed. We needed to integrate Marionette as well as write plenty of glue code for things like pre/post route filtering, memory leak mitigation, and better event management.

[Shiprack]

"You'd never ask Backbone or D3" - sure, but I can easily imagine a project where I'd use D3 in conjunction with Backbone. Its probably much harder to imagine a project where Backbone and Ember are used together on a single page. So, I find the question "Backbone or Ember" quite fair. Here's another post I found quite informative, because it compares the two frameworks more deeply: net.tutsplus.com/tutorials/javascript-ajax/…

[Admin]

Backbone + Marionette is an equally good approach to Ember. Check out backbonerails.com