Backbone.js vs Ember.js

Wednesday, 11 January 2012

In the last few years a trend in web development has been gathering pace. It used to be the case that we could write all of our views and templates on the server side to rendered by a web framework. Now if you want to build a modern web app you need to be comfortable putting the bulk of that logic on the client side.


Up until very recently I had been using Backbone.js to do that. Backbone is a great way to provide structure to your client side Javascript and provides MVC tools including routing and data syncing. Due to it’s stellar documentation and wealth of examples it was the obvious choice for many developers and gained a ton of traction.

But there was always a key problem with Backbone. I felt like I was writing lots and lots of code just to do very standard interfaces. This is mainly because Backbone gives a lot of freedom in how you choose to render templates and handle events. As I got more familiar with it I realised there was scope for a meta framework that could sit on top of Backbone and perform a lot of the heavy lifting for the developer. Of course this never happened, but Ember.js did appear!


Ember.js is a new framework that specifically addresses the problems I encountered with Backbone development. Instead of manually wiring everything together you can, for example, point a view at an array and it will automatically rerendered as the array is manipulated. This is because of Ember’s brilliant binding system and tight integration with the Handlebars.js templating language.

It was such a smart move for the Ember team to rebrand the framework (it used to be called SproutCore 2.0) as it grabbed my attention and I understood the angle they were coming from immediately.

The biggest problem facing Ember right now is documentation. I found it very difficult to discover the best practices and techniques so that I wasn’t fighting against the framework. I found the most success by reading through the Ember source, the unit tests and hanging out in the IRC channel. If more example applications were available to read through this problem could be solved.

I have also found other areas of the framework slightly lacking - specifically routing and persistence where I feel Backbone is more mature. The good news is that since I started using Ember last month a ton of work has gone in to both areas resulting in ember-states and Ember Data which are great steps towards addressing these holes.

Am I Sticking With Ember?

Yes, although it’s a little rough around the edges the core idea is solid and Ember is getting better on a daily basis. It’s probably not a good fit if you need to both learn client side MVC and release an app pretty soon but it’s just a matter of time before documentation and more example apps are released. If you are familiar with Backbone or another framework give it a try and see if it cuts down the amount of boilerplate you need.

blog comments powered by Disqus