6 ms·

An In-Depth Introduction To Ember.js

73 points by elie_CH 13y ago

moneypenny 13y ago
Ah, Ember, such promise, such expectations. Too little, too late. I spent about 13 months working with it, but it has proved a complete waste of time. In getting other developers up and running, to having to put up with Ember-Data's endless deficiencies, to waiting for updates and news, well, the momentum has gone. There's better choices out there. Ember is hard to learn, too heavy, and not good enough. Skate to where the puck is going. Google Trends: http://www.google.com/trends/explore?q=angularjs%2C+ember.js%2C+backbone.js#q=angularjs%2C%20ember.js%2C%20backbone.js&cmpt=q http://www.google.com/trends/explore?q=angularjs%2C+ember.js...
Mc_Big_G 13y ago
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 13y ago
  True. That's how you should implement the flow control after validation.
Tzunamitom 13y ago
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/
ekidd 13y ago
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-introduction-to-ember-js/#what_about_not_using_emberdata http://coding.smashingmagazine.com/2013/11/07/an-in-depth-in... 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.
runnr_az 13y ago
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 13y ago
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?
- michaelrkn 13y ago
  Angular and Ember have the same use case. They're just different approaches to client-side MVC.
- machty 13y ago
  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.
  - atburrow 13y ago
    Thanks for this response. I think I may have to do a crash course on each one for a few days to make a more informed decision. I've always used Backbone to quickly prototype, but I like the idea of having a more complete toolkit once prototyping is done.

73 points by elie_CH 13y ago

Ah, Ember, such promise, such expectations. Too little, too late. I spent about 13 months working with it, but it has proved a complete waste of time. In getting other developers up and running, to having to put up with Ember-Data's endless deficiencies, to waiting for updates and news, well, the momentum has gone. There's better choices out there. Ember is hard to learn, too heavy, and not good enough. Skate to where the puck is going. Google Trends: http://www.google.com/trends/explore?q=angularjs%2C+ember.js%2C+backbone.js#q=angularjs%2C%20ember.js%2C%20backbone.js&cmpt=q http://www.google.com/trends/explore?q=angularjs%2C+ember.js...

Mc_Big_G 13y ago

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 13y ago
True. That's how you should implement the flow control after validation.

Tzunamitom 13y ago

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/

ekidd 13y ago

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-introduction-to-ember-js/#what_about_not_using_emberdata http://coding.smashingmagazine.com/2013/11/07/an-in-depth-in... 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.

runnr_az 13y ago

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 13y ago

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?

michaelrkn 13y ago
Angular and Ember have the same use case. They're just different approaches to client-side MVC.
machty 13y ago
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.
- atburrow 13y ago
  Thanks for this response. I think I may have to do a crash course on each one for a few days to make a more informed decision. I've always used Backbone to quickly prototype, but I like the idea of having a more complete toolkit once prototyping is done.