[seilund]

I would recommend you to take a deeper look at Ember.js.

The article above by Jesus Rodriguez is a good article. It shows how Angular is easy to create _very_ small widgets with. But it doesn't tell you much about how to write a big application.

My experience with Ember (we're creating a very large app with around 100 different routes) is extremely good. More functionality != more bulk. All new features we add to the app fit nicely with the existing code. We never have to go back and refactor large parts of the app. It's the same simple pattern you apply over and over again. I seem to get the opposite impression from Angular apps, where as soon as your app grows more complex you need to take a lot of things in a different direction.

Take a look for yourself at some big and serious companies who are building large open source Ember apps:

Discourse: https://github.com/discourse/discourse/tree/master/app/asset...

Travis CI: https://github.com/travis-ci/travis-web/tree/master/assets/s...

Balanced Payments Dashboard: https://github.com/balanced/balanced-dashboard/tree/master/a...

And check out the new getting started guides: http://emberjs.com/guides/ (especially the screencast by Tom Dale)

[sahrizv]

I am actually inclined towards Ember.js since the time I was faced with this choice. I just wanted to take the opinion of all the experienced developers here, to back my choice or change it. Thanks for easing the choice. I'll go through the Ember docs. :-)

[shadeless]

Thanks for sharing, it's always useful to hear about real-life usage. One thing I didn't hear much regarding Angular/Ember is testing, can you tell us how you approached it?

[mjallday]

I can't speak for OP but if you look through the Balanced Dashboard repo there are some good examples:

    https://github.com/balanced/balanced-dashboard/blob/master/test/integration/guest_user_flow.js

For the most part we use integration testing e.g. We simulate mouse clicks and key presses via jQuery and then assert changes in the page behaviour and calls made to the API (see line #85 in above link).

If you approach it like that, and I assume this would be the same for Angular, there's very little testing that's specific to the framework you're building on top of.

At Balanced, even when running unit tests on models to test features in isolation we're still not touching anything inside Ember, occasionally we may jump into the internals to short cut getting the app to a particular state but 99.9% of the time you don't need to.