AngularJS, Backbone.js or Ember.js – Which One to Choose for Your Project?
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, 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 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.
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
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.
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.
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.
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.
Other posts in this series with Craig McKeachie:
- 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