

An In-Depth Introduction To Ember.js - elie_CH
http://coding.smashingmagazine.com/2013/11/07/an-in-depth-introduction-to-ember-js/

======
Mc_Big_G
I only reviewed it quickly, but I think they should be using the "then"
pattern of promises when saving and transitioning.

So this:

this.get('model').save();

this.transitionToRoute('users');

Should be:

var controller = this;

this.get('model').save().then(function(model) {

    
    
      controller.transitionToRoute('users');
    

}).fail(function(error) {

    
    
      //Feedback for the user
    

});

~~~
ulisesrmzroche
True. That's how you should implement the flow control after validation.

------
ekidd
I'm really loving the new Promises/A+ support in Ember—lots of weird corner
cases just got a lot cleaner, and it's much easier to bypass Ember-Data when
the need arises. See this section of the original post for an example:

[http://coding.smashingmagazine.com/2013/11/07/an-in-depth-
in...](http://coding.smashingmagazine.com/2013/11/07/an-in-depth-introduction-
to-ember-js/#what_about_not_using_emberdata)

The first rule of Ember.js happiness is "Don't fight with Ember Data." When
Ember Data does what you want, it's amazing. When you want to do something
that it doesn't support, just fall back to jQuery and promises at the model
layer, as shown above.

------
Tzunamitom
Really good site. I've also found Ember Sherpa to be very useful once you're
up and running: [http://embersherpa.com/](http://embersherpa.com/)

------
runnr_az
I'm doing my latest project in Ember... it's cool, but even with a whole bunch
of javascript experience, it's been a steep learning curve. I'm starting to
get it and I like what I see, but I'd definitely welcome any resources people
have in terms of getting to know it in a deeper way.

------
atburrow
I've always been meaning to take a look at Ember. When I first started seeing
discussions about it about 2 years ago, there weren't many guides or quick
examples on how it is different than other frameworks out there. What would
the use case be for Ember.js vs something like AngularJS?

~~~
machty
Angular folk are often quick to point out that "Angular isn't a framework;
it's an HTML compiler", or, as their homepage states, "AngularJS is a toolset
for building the framework most suited to your application development."
Angular doesn't necessarily set out to solve all of the problems and use cases
that developers might run into, but rather Angular intends to give you all of
the proper data-binding, dependency injection, and testability primitives as a
foundation to build your app upon.

Because it doesn't intend to solve all the problems that a framework might,
Angular is far fewer conventions about how to organize large-scale
applications than a much heavier and opinionated framework like Ember. This
doesn't mean Angular doesn't scale, or that it can't be used to build large
apps, but it does explain why it's common for different teams to build large
Angular apps in totally different ways, using different patterns, etc.

Ember on the other hand sets out to establish way more conventions, built
right into the framework, for solving problems common to most web apps. These
patterns are rigorously battle-tested since everyone is using them, and as
such, it's easy (once you're past the learning curve), to drop into someone
else's Ember app and know exactly where to go to diagnose a problem. That
being said, when these patterns aren't helpful for an app's specific needs,
most of Ember's patterns/abstractions are, like Angular, built upon composable
primitives that you can use to assemble your own data structures, custom
classes, etc., to tailor to your app's needs.

~~~
mjackson
Very well said.

One thing I might add for others who read this is that many of Ember's design
patterns are modeled after Cocoa, which has proven to be one of the world's
most robust platforms for building apps. If you're familiar with Cocoa's two-
stage object instantiation, MVC, or first responder patterns you should be
able to recognize them fairly easily in Ember.

