AngularJS vs Ember.js -- Comparing Apples to Oranges

Are you trying to make a decision on whether to use Angular or Ember for your ambitious web application? You have big plans for your project and are weary of making a technical decision that might come back to bite you in the ass. We empathize with that.

There are a bunch of useful technical posts out there that compare and contrast these two frameworks so we’ll avoid singing that tune, again. In fact, we’ve compiled a few links and share those toward the end of the post. We encourage you to read those before you make a final decision.

First, full disclosure: We are big fans of Ember.js.

Why? The short-version is that it falls in line with what worked best for our clients, ourselves and follows patterns that we have seen lead to long-lasting healthy web applications.

The long version is that it also happens to support IE9 (kind of), which was a make or break criteria for the client at the start of their project. It just happened to turn into a tool that we really enjoy, allowing us to create apps that we, and our clients, have been extremely happy with. These are the small technical choices that determine whether or not a tool is right for a project. We did drop IE9 support before the end of the project, but were ultimately content with our choice.

With a steep learning curve, this was not always the case. Ember requires you to learn how to do things “The Ember way”, and enforces relatively stringent patterns for how best to organize code when compared to other frameworks. As an agency that has embraced Ruby on Rails since early 2005, we have seen this 'convention over configuration' approach yield mature and maintainable projects lasting years of active development by multiple teams. It is our opinion that when the framework makes some foundational decisions for us, it frees mental space for the more important problems.

In our opinion, the best tool, is the one that facilitates the long-term success of a project.

The people you hire to work on your application today are not guaranteed to be the folks working on it in four years. The best case scenario is that your application should outlast any single developer and/or development team.

We are acutely aware of the importance of planning for the long term. The majority of our projects have been inherited. Either built overseas, or by other development teams. When a framework like Ember.js or Rails encourage common patterns and practices they provide us a foundational knowledge of how an application works, before we even have a chance to work on a client’s project. It is these vital elements of standardization that allow us to begin developing quickly, efficiently and are what ultimately facilitate the longevity of a project.

"Which one is better?" is not a question with a single acceptable answer.

Each is the best tool for a job, both are powerful and extendable for many purposes beyond their supposed 'best use case'.

Whether or not these differences directly correlate to "better" or "worse" depend entirely on you, the project, and the development team. As with any framework, each will certainly bring challenges of it's own...both in the short, and long term.

Below are several recent ( < 1 year old ) posts summarizing what we feel are fair and useful comparisons between some of the more popular frameworks today.

• Mist.io - Javascript MVC Showdown
• Roma Rimsha - Clash of the Titans: Angular vs. Backbone vs. Ember
• Smashing Boxes - Choosing a Front End Framework

We made the decision to invest time, money, and energy into Ember.js because it made the most sense for our client’s projects. We don’t take these decisions lightly. We also don’t believe it makes sense for every project that comes our way.

So, Angular or Ember? That’s a big decision.