What Should Beginners Choose: AngularJS, Ember.js, or Backbone.js?

Published Sep 10, 2014Last updated Jul 31, 2017

Should you use AngularJS, Backbone or Ember? Which framework should beginners choose? Dean Sofer of AngularUI and Craig McKeachie, author of the JavaScript Framework Guide, offer their insight in this post.

Dean Sofer

AngularJS v.s. Ember.js v.s. Backbone.js: a Short Overview

If you’re starting from scratch, I’d recommend Angular. Naturally, I’m going to be biased, but I think Angular is the way to go because it’s taking off. It will remain that way unless problems arise from the roadmap, within the community, the project, or the development. It might happen, since Angular is getting a little more complicated, but right now it’s hot to get.

Ember was a solid project, but Backbone was so popular at the time and had such a foothold Ember wasn’t able to supersede it. However, Angular took a lot of what Ember does and made it even easier than PHP where any dumbass can write horrible code—people can’t even argue with the simplicity of its use.  Before I picked up Angular, I tried out other things like Knockout, MVC, Backbone, Ember, and other frameworks. I ended up with Angular because it takes less lines of code. It has less characters, less lines, it’s shorter, and it doesn’t use setters and getters for data binding. To me that is so much easier to wrap my head around. You cand write scope.age=23 and scope.name=John, and people can read that and understand that versus scope.setdata(age,23). Angular is much easier to understand, except when you get into creating directives…which is a whole other beast.

Ember used to have the advantage of a router, but UI Router pretty much brought AngularJS up to speed, so I tell people they should definitely not be building projects without UI router. Therefore, I currently don’t see any thing that compels me to choose Ember over Angular.

However, Ember and Angular are really close to each other, so if you know Ember better than Angular and you don’t have a reason to switch, don’t. Because the one detriment you’re going to have is the learning curve, and that’s for any project or framework.

Backbone, on the other hand, is quite different than Angular. Backbone is a widget builder that just builds blocks of HTML with Javascript tied to them, and that’s it. It’s all about render functions in Backbone, while Angular and Ember are live templating engines, as are other frameworks such as Knockout. The whole live templating engine where you simply put bindings on dom elements and having data come back to you in a really easy accessible manner is the direction we’re going. I think Backbone is going in the wrong direction, so if you’d ask me whether to go with Ember or Backbone, I’d say Ember. Of course, this is just my opinion based on what I understand.

Codementor JavaScript Frameworks Office Hours - Choosing Your Religion: AngularJS, Backbone, Ember

Craig McKeachie

Codementor Craig McKeachie also had an Office Hours dedicated to the subject of JavaScript frameworks and provided us a more in-depth analysis:

Angular vs Ember vs Backbone: What Should JavaScript Beginners Learn?

My learning path was going from jQuery to Angular before jumping to Backbone, and finally Ember. If I had to do it again, I think it would have been a much better experience for me to have learned Backbone.js first. Some people can be up in arms and say things such as “You’re just wasting your time,” or “Why learn this stuff that doesn’t matter for JavaScript?”, but from a learning perspective, I think it’s not bad if you’re doing it just to get prepared for actual MVCs, considering how Backbone.js is more like a library than a framework. Basically, I’m sure a lot of relatively new JavaScript developers run across a lot of broad statements where people point out what framework is good, what is better, and what is lacking. However, without some context within which to digest those statements, they end up being an opinion about things.

I personally like to think about frameworks by breaking them down to features and giving concrete examples, since I think this really informs a lot of understanding of what’s not there. I’ve written on on my blog before about how to learn JavaScript frameworks quickly, and I also rewritten it for SitePoint. For a quick example, let’s look at the routing feature of each framework. You need this feature if you’re in a client-side app and virtually switching pages on the client-side. So, whenever you click a link or change an URL in the address bar, that URL change or window.location change is being intercepted on the client, and a new virtual template will be loaded with new data. Here in Backbone is a really simple example of routing by switching between the “Home” and “About” page:

var HomeView = Backbone.View.extend({ 
  template: '<h1>Home</h1>',
    initialize: function () { 
    render: function () { 
var AboutView = Backbone.View.extend({
  template: '<h1>About</h1>', 
    initialize: function () { 
    render: function () { 
  var AppRouter = Backbone.Router.extend({ 
  	routes: {
    	'': 'homeRoute', 
        'home': 'homeRoute', 
        'about': 'aboutRoute',
    homeRoute: function () { 
    	var homeView = new HomeView(); 
    aboutRoute: function () { 
    	var aboutView = new AboutView(); 
  var appRouter = new AppRouter(); 

JSFiddle Link

You can see from the example above that the homeRoute is set to default '', in which the browser would go to the HomeView and load the HTML. Basically, the route maps to a function or some JavaScript code that loads a new view end, so it’s just like a server-side framework’s MVC router, only it’s happening on the client. Here is how you’d do the router in Angular’s built-in provider:

var routingExample = angular.module('FunnyAnt.Examples.Routing', []);
routingExample.controller('HomeController', function ($scope) {});
routingExample.controller('AboutController', function ($scope) {});

routingExample.config(function ($routeProvider) {
    when('/home', {
        templateUrl: 'embedded.home.html',
        controller: 'HomeController'
    when('/about', {
        templateUrl: 'embedded.about.html',
        controller: 'AboutController'
        redirectTo: '/home'

JSFiddle link

In which when you go to a particular path, you’d run the route controller and then load the template, which is similar to what Backbone does. It’s a way to dynamically load the page and virtually switch it. In Ember, however, you’d notice a lot less code because Ember embraces convention:

App = Ember.Application.create();

App.Router.map(function() {
    //first paramater refers to the template
    this.route('home', { path: '/' });

JSFiddle Link

Once you understand what these codes do, you can look at all the frameworks in a much more unbiased perspective and also realize they’re a lot more alike than they are different. Personally, I don’t think it’s useless to learn any of them, since I think once you get a framework, you’d get it. Everyone wants you to believe the framework they use is better and more different, but that’s mainly because of the pros and cons of each framework. What you really need to understand is the concept of Single-Page Applications (SPA), and how JavaScript MVC frameworks help you build a SPA. In terms of the learning curve, I think it is big across all frameworks. AngularJS may seem intimidating because it used to have documentation so awful it was almost comical, especially since they allowed people to comment in the bottom and when you’re digging through them for something useful you may be amused by what people post there. Nowadays the AngularJS docs are much better. Furthermore, the community around Angular is extremely big, so if you ask anything on Stack Overflow, you’ll get an answer in no time compared to other frameworks.

However, how difficult you find Angular will also depend on what background you’re coming from. If you come from a Java enterprise or a .NET enterprise where you use Inversion of Control (IoC) containers every day and now what dependency injections are, you’ll have less of a problem with AngularJS. If you come from a creative media background, code CSS and jQuery plugins but aren’t used to the enterprise-y stuff, then you may find it more of a challenge to learn Angular. Tom Dale did a great job for Ember’s documentation and their web components are much easier to understand than AngularJS’s directives, but when it comes to getting questions answered, I personally found it a bit more difficult, though that has a lot to do with the number of people using the framework. Backbone is small, so it’s relatively simple to “get”. So, if you have the time, it is a pretty good idea to learn Backbone first to get more familiar with how MVC works, since as you can see from the examples above MVC frameworks are all pretty similar.

The Pros and Cons of each Framework




If you’re in an enterprise shop, particularly one with Java or Ruby on Rails background, you will really like what Angular offers in terms of testing. While other web frameworks may support testing, Angular goes beyond that and has built-in dependency injection, which is a big plus on Angular’s side if you really care about testing.


AngularJS has always been pushing the envelop on browser support. In addition, it thought about mobile support before other frameworks, along with ECMAScript 6 and web components. Thus, AngularJS’s team is very forward-thinking and have a lot of vision.


The Built-in Router

Most people don’t actually use the router in AngularJS. Of course, there is an open source alternative, AngularUI Router, which basically erases this weakness, but to be fair by comparing framework to framework straight up, Ember was the first there with a really strong router while Angular’s native router is not so great. For example, if you have a list of items and the details for those items, you would picture in a Ruby on Rails app to have a /list-route, and then a /details-itemID for the detail. However, in reality, people will want to see the list and details on the same page, they might want the list on a left-hand side of the menu. When they click an item they would expect to be able to drill into its details. While this kind of complex interaction is possible with the basic Angular router, you’d actually be hiding and showing things, which is not very native. You don’t have the ability to put the code in its own isolated place for a detailed view and put the list view in its own isolated place.

In contrast, if you have a robust router as in Ember or the AngularUI router, you’d have a nested view, where a detail route would be underneath a list route and can be composed or pulled apart in a nested hierarchy, which is super powerful. In addition, both Ember and AngularUI router also allows you to have named views, which is useful if you’re going to divide your page into a header, footer, sidebar, left navigation, and so on. Basically, named views will also allow you to have an isolated set of code, a controller (in Angular’s case), and a scope to each of those pieces so you can compose them up. The native Angular router does not have such a feature. The Angular team is currently rewriting the router for their new framework, and details about it hasn’t been released. However, with the AngularUI Router, this shouldn’t be an issue in choosing which framework to use.


Directives are Angular’s core feature, and also a big weakness because so many people find it difficult to write them. Angular is talking about fixing this in newer versions, but at the moment directives can make Angular rather tough for some developers.



the Router

As mentioned before, Ember’s built-in router is very strong. It is a full state-machine, as is the AngularUI Router for Angular.


Ember has done pretty well with their vision, such as seeing object.observe() beforehand, following Angular’s path and thinking about web components early, etc.

The Component Model

Unlike Angular’s directives, Ember’s web components are much simpler because they’re not trying to do much. Instead, their components are trying to be simple UI widgets or components, so the API is much cleaner and easier to understand.



Ember doesn’t do the dirty checking that is common in Angular. They use getters and setters, and you need to remember them to access properties on your objects. This can be a pain because you can forget and actually just . to a property and then get a strange bug in the application. You’d then have to spend some having to track that error down, so it’s not as natural as having properties that are just raw, plain-old JavaScript objects as they are in Angular.




If you have a legacy or a brown-field app, want to clean up the messy jQuery code, and haven’t decided what framework to adopt, it may be a good idea to bring Backbone in. It’s super small, more of a library than a framework, and you can use it to refactor old code, clean things up, and get some more modularity around the things you’re doing.

Performance Control

Compared to other frameworks, Backbone gives you a lot more control over performance, particularly in mobile scenarios. Therefore, if you’re someone who’s really comfortable in JavaScript and don’t want a framework in your way, or if you’re concerned about running into performance bottlenecks that may result from a framework’s 2-way data binding, you may be comfortable with Backbone.



As Backbone is more like a library, which means it doesn’t try to put much of its opinion on you, this also means it doesn’t help you as much and doesn’t write as much of your code for you. This is not to say you’re not going to be productive with backbone, but you certainly would have more code to write. A large reason for that would be the lack of 2-way data binding, which is a key feature a lot of people really liked about Angular and Ember.


As Backbone does not have much of an opinion, architecture is unclear at times, which can make it challenging to get up to speed on some things.

Memory Leaking

This is a big con of Backbone, since if you’re not a JavaScript guru and don’t always know what you’re doing with JavaScript, Backbone might not be a good choice to adopt as it may be easier for you to end up leaking memory when you’re writing applications.


As far as Angular and Ember go, it would be a reasonable choice to pick either. Backbone may sound less preferred, though this actually has to do with the generations of what has happened in building rich JavaScript applications. At first, there was plain old JavaScript, in which back in the day no one wanted to write it when it was just that due to all of the cross-browser issues. Then jQuery came along, and since it can be summarized to be a DOM manipulation library, it removed the cross-browser issues. It also had an AJAX API that enabled a lot of things, so it was sort of the second step in the evolution of building JavaScript applications. The third generation would be Backbone and Knockout. Those two came about because people were realizing at that point that they weren’t able to reuse code and pages when they wrote jQuery applications, and they felt as though they were writing these nested codes. Of course, they could write good jQuery code, but it wasn’t leading them into success all the time. Promises make things better, but you can still quickly break the back button by making a few AJAX calls with your jQuery code.

As you build more of your app in JavaScript, you eventually hit the edge of jQuery. Backbone helped make code cleaner, and there were a lot of micro-frameworks competing against it, but Backbone won. In addition, people really liked the 2-way data-binding in Knockout. Finally, the next evolution of frameworks came along, which is Angular and Ember. They gathered all the ideas of what people liked and put together a more inclusive framework as opposed to a library. Therefore, if you think about the generations of JavaScript’s evolution, personally I’d prefer to be using the newer generation of tools. However, as mentioned before, there are exceptions to that, and the most common being performance. There’s a lot of magic happening for you in Angular and Ember, and with this magic, particularly in the data-binding front, you could run into some performance concerns—particularly on the mobile side.

The Angular team sort of recognized this issue, and in version 1.3, one of the major features was improved performance. On the other hand, if you look at what the Ember team is doing besides building tools, you’d notice their HTMLbars project. It will sort of revolutionize their data-binding approach, as well as their approach to the DOM and their templating engine. As a result, Ember has gotten a lot faster as well. Thus, in early versions of Angular and Ember, there were mobile performance problems if you had a lot of items on a page, while in Backbone you could have a fine grain control over things. Altogether, which framework you choose will depend on what you’re doing with the framework, but hopefully this will give you a simple idea.

What Others Are Choosing

For me it would be subjective to say which I see more of, but you can look at online statistics from github stuff as well as questions on stack overflow to get an idea. From my experience via picking up corporate training gigs, Angular clearly has a popularity advantage over Ember, but it took a big hit in the last few weeks in its announcement of a new 2.0, and Ember came out strong. If you’re in a Rails shop and have a lot of Rails developers, you might want to think hard about Ember because the conventions are so similar. This is because one of the core contributors to Ember was on the jQuery core team and Rails core times, and he is now the creator of Ember with Tom dale with other people. So, basically Ember is very friendly to Rails developers in terms of built tools and developer experience. Also, if you really care about URLs and SEO and you still want to use one of these rich frameworks, Ember’s built-in router would make it a bit more SEO-friendly. However, JavaScript Frameworks, SPA, and SEO generally aren’t compatible, and you can read more about it here.

Codementor Craig McKeachie has been a software developer for nearly 20 years, mostly on the Microsoft stack. At one point he was a Microsoft Certified Trainer, though in recent years he has gotten a lot more interested in front-end development (HTML, CSS, and JavaScript), usability and user experience after working as a consultant at a few different digital interactive agencies on projects.

Discover and read more posts from Dean Sofer
get started