AngularJS, Backbone.js or Ember.js – Which One to Choose for Your Project?
This JavaScript comparison series is based on a Codementor Office Hours session with Craig McKeachie, author of the JavaScript Framework Guide. Let’s discuss about the pros and cons of AngularJS, Backbone.js, and Ember.js to help you better decide which JavaScript MV* framework to choose for your project.
Introduction
Although I mostly come from a .NET and dabbled in some Rails and PHP along the way, for the past year or so I’ve been full-time getting up-to-speed with learning JavaScript frameworks. I’ve consulted businesses for a few years, so I think I can understand most people’s perspectives, whether they’re coming from a media perspective or an enterprise side. I’ll try to give you an unbiased analysis here, though which framework you choose depends on your needs. If i came up here and just said “this one’s better than this one”, I think it would be disingenuous. So, here are a few pros and cons of each framework.
AngularJS
PROS:
Testing
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.
Vision
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.
CONS:
The Built-in Router
Most people don’t actually use the router in AngularJS. Of course, there is an open source alternative, AngularUI Router, and there was actually a Codementor Office Hours by Dean Sofer, who is part of the AngularUI team who briefly talks about it. AngularUI Router 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
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.
Ember.js
PROS:
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.
Vision
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.
CONS:
Testing
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.
Backbone.js
PROS:
Lightweight
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.
CONS:
Productivity
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.
Architecture
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.
Conclusion
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 the newest version (1.3) that just came out not long ago, 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.
Other posts in this series with Craig McKeachie:
- Should You Use a JavaScript MVC to Build Your Web Application?
- Angular vs Ember vs Backbone: What Should JavaScript Beginners Learn?
- Should You Wait Until Angular 2.0 is Released Before Learning AngularJS?
- MV* Frameworks Office Hours Q&A: REACT.js, Angular Design Practices, and More
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.
If you’re interested in Craig’s book JavaScript Framework Guide but would prefer speaking to him one-on-one to make your decision, Craig is offering his book & videos (valued at $99) for free if you schedule an hour-long session with him on Codementor. If you schedule 2 hours, he would throw in the next tier package (valued at $249, which includes the ng-book). You’ll get the team package (valued $999) free of charge if you schedule a 4 hour session with him.
