In Angular, there is a powerful concept called services. Services are used when you need to share data between controllers, like your example. Angular services are guaranteed to be singletons, but instead of passing references around, you use dependence injection instead. Ember is fun and kids like it, but grown ups appreciate the superior design in Angular.
Your kids vs grown ups comment is ENTIRELY uncalled for. If you can't justify something based on the merits, then you have no business going for ad hominem attacks. If you can make your point without ad hominem attacks, then you should.
FYI according to Stack Overflow, Steve is in his late 20s and has been a professional developer for several years. I'm in my mid-40s and have been a developer since the last millennium. Both of us have been on this site longer than you, and have much higher reputation here. Neither of us are kids. Assume that we can understand your actual substantive points, make them, and move on.
Re:AngularJS versus Ember
by steveklabnik on Sunday June 16, 2013 @10:54PM
(#5891173)
Your 'kids vs grown ups' comment just makes me want to learn Angular that much less.
(I will look into exactly what Services are, thank you.)
To spell out the question in a different way:
I have an object that represents some kind of object, like a User, for example. On every page, I display the user's name.
With the 'long lived object' strategy, I fetch the User on the first page load, and display it. The JS object then sticks around, and as I navigate, the same User object in memory is used on each 'page' to put in the username. No difference.
With the 'mostly server side' strategy, I fetch the User on the first page load and display it. When I navigate around, I then re-fetch the User on every single 'page'.
I am not familiar enough with the details of Angular (and, frankly, Ember, which I'm still new to) to tell you if this maps 1-1 with the way that they work, but it's the two different approaches in a general sense.