7 ms·

Ember Tutorial

127 points by hpvic03 12y ago

ulisesrmzroche 12y ago
Good work, bro! Main criticism is that the 1st chapter took forever though.
chrishenn 12y ago
I've been working with Ember over the past few months and am still impressed with how simple and productive it makes every day tasks. Basic CRUD stuff, especially render code, is a lot less drudge work. I'm even more excited for where the community is leading the framework, through projects like ember-cli and htmlbars. Ember is conceptually pretty massive though. A tutorial like Michael Hartl's Rails tutorial would be a huge benefit, it looks like that's what this is aiming for. Thanks!
- HNJohnC 12y ago
  I hope it works out for you but that's just about exactly how I felt immediately before I realized it was not going to work for a very large project, switched to Angular and haven't looked back since. There was no comparison at all for me between Ember and Angular but everyone's needs are different.
  - sehr 12y ago
    What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.
    - deleted 12y ago
      [deleted]
    - pyre 12y ago
      Ember's examples on their site are always the simplest use-case. For example, find me an example on their site of saving a complex relationship that was newly created by your application. Let's take the example of an invoice. Let's say you have an Invoice model, and an InvoiceLineItem model in a one-to-many relationship. How do I save the creation of a new invoice (with line items) as a single transaction? As far as I can tell, you can't without breaking from Ember Data's very strict 'this is the way things should be done' model. You have to create a new Invoice, then create the InvoiceLineItems doing something like this: var self = this; self.get('store').createRecord('invoice', { .. attributes .. }).save().then(function (invoice) { return Ember.RSVP.all(self.get('lineItems').map(function (item) { return self.get('store').createRecord('invoiceLineItem', { invoice: invoice, .. attributes .. }).save(); }); }).then(function (invoiceLineItems) { // do something }).then(null, function (error) { console.error(error); }); Note that this isn't even taking into account how to rollback INSERTs if, for instance a single invoiceLineItem fails to be created. The 'other' way to do it is to create just an Invoice model, and have a lineItems attribute of type 'raw' and just create a RawTransform that's just as pass-through of whatever the JSON has for that attribute. It works, but at the same time, feels like it's going against the Ember Data Way, especially if you have a need for an InvoiceLineItem to be its own model (i.e. to be able to maintain relationships to other things and look one up by ID via the API). Then you might have something like: - Invoice and InvoiceLineItem models - A RawTransform: App.RawTransform = DS.Transform.extend({ deserialize: function (data) { return data; }, serialize: function (data) { return data; }, }); - An attribute like so (on Invoice model): lineItems: DS.attr('raw'), - Code that looks like this: var self = this; self.get('store').find('invoice', invoiceId).then(function (invoice) { self.get('store').pushPayload('invoiceLineItem', { invoiceLineItems: invoice.get('lineItems') }); });
      - lookingsideways 12y ago
        If your API supports it you can use the EmbeddedRecordsMixin[0]. In general though, what would be a sane default for handling multiple REST API calls to single-model endpoints? [0]: http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin.html http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin....
      - Nemcue 12y ago
        I really wish there was some thorough examples of using Ember + Ember-Data. Ideally it would be backend agnostic (mocked client side xmlhttprequest) and go from doing simple things like saving a model all the way to doing more complex things like you showed. Drupal for instance has a /really/ great project that maintains a bunch of thorough examples (https://drupal.org/project/examples https://drupal.org/project/examples) which were indispensable when I did Drupal a while back.
        adamnemecek 12y ago
        There really should be better examples. In the mean time, you should check out the Balanced Dashboard, I've learned a good amount from it https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard
        pyre 12y ago
        It's kind of funny, but I don't even remember simple things being spelled out. For example, in their use cases all of the models and routes are single words like: post, comment, todo, etc. In some places, you see 'Post' and others 'post', but there is nothing explicitly spelling out how that works for multi-word items (e.g. MultiWord => multiWord). Same with underscores in route names (e.g. route name 'multi_word.item.index' => MultiWordItemIndexRoute).
        deleted 12y ago
        [deleted]
        zyxley 12y ago
        Yeah, the magic rejiggering of names everywhere with no clear documentation of what mapped to what† killed my interest in Ember the first time I tried to actually use it for even a fairly simple app. † Plus the enforced snakeCase/CamelCase everywhere, but that's more to do with me far preferring names_with_underscores in general.
- pyre 12y ago
  On the other hand, I've found many things lacking in Ember.js, though most of my gripes are with ember-data, so I don't know if you're thinking of that as part of Ember.js. A couple of examples of Ember.js-specific gripes though: - We have a table with one of the filters just stops working after changing the value 4 ~ 5 times. I've dug into this, but I can't really figure it out without going into the Ember.js internals (which I have done before, but the time sink isn't currently worth it). I've boiled it down to the fact that at some point Ember.js stops responding to changes on a particular attribute. Computed properties stop working sooner, but even a .observes('attribute') stops triggering after 5 or 6 changes. I get that software is not bug-free, but how am I supposed to even debug something like that? It would be fairly difficult (and time-consuming) to boil it down to a simple test case, as this is the only place we're seeing this happen and it's in a large Ember.js application. - There is no case/switch statement in Handlebars. I'm left with deeply nested if/unless blocks, or tons of computed properties on controllers/views that generate this stuff. E.g.: {{#if valueLoading}} Loading... {{else}} {{#if valueLoadingFailed}} Error! {{else}} {{#if value.length}} <ul> {{#each item in value}} <li> {{item}} </li> {{/each}} </ul> {{else}} No Items. {{/if}} {{/if}} {{/if}} vs. {{#if value.length}} <ul> {{#each item in value}} <li> {{item}} </li> {{/each}} </ul> {{else}} {{stateMessage}} {{/if}} ... and on the controller ... stateMessage: function () { return this.get('valueLoading') ? 'Loading...' : this.get('valueLoadingFailed') ? 'Error!' : this.get('value.length') === 0 ? 'No Items.' : ''; }.property('valueLoading', 'valueLoadingFailed', 'value.length'),
  - nathanhammond 12y ago
    1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad. 2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.
    - pyre 12y ago
rubiquity 12y ago
The more I look at Ember the more it reminds of a framework named Batman[0] I used over two years ago. It's almost a complete replica, all the way down to Ember.Object being identical to Batman.Observable. The problem with Batman (aside from being buggy) was that it tried to do this same MVC that we use on the server on the client, and the mapping just doesn't make sense. HTTP "MVC" doesn't have state between requests whereas client-side MVC has state for the entirety of the app. Rails, for example, has a Router and Controller due to the synchronous nature of how a request comes in and gets turned into a response. The first place I see MVC JS frameworks fall apart is when they have both Controllers and Routers. Ember Controllers look like little more than Decorators. I imagine these would be called a ViewModel if named appropriately. Over two years later, I can't help but feel Backbone (minus the underabstracted View layer, which can be easily replaced with React) got the mental model for JavaScript apps right from the start. Ember just seems to have been marketed much better than Batman was, which is no surprise, Yehuda is good at doing that. 0 - http://batmanjs.org http://batmanjs.org
- 3pt14159 12y ago
  Ember handles App state very well. It is easy to take advantage of local storage when you need it, and the way that changes in the data are bound with changes in the view makes it very easy to create pro-level web applications.
  - deleted 12y ago
    [deleted]
  - rubiquity 12y ago
    Nothing about what you just said is specific to Ember. Two-way data-binding is common in just about every framework, or can be added in cases like Backbone. Easily using localStorage is also common because just about every JS framework uses the Adapter pattern for persistence.
- xiaomai 12y ago
  > Ember just seems to have been marketed much better than Batman was, which is no surprise, Yehuda is good at doing that. I don't think this is fair. We use Ember at work, although I wish we used React. We started out on Backbone and it was miserable. Ember has gotten popular because it and Angular were seen as the successors to Backbone for a long time. Ember is designed in a much more thoughtful (and I think better) way than Angular. Yehuda has done a lot of good work on Rails, Bundler, jQuery. That probably helps sell people on his projects. I wouldn't chalk it up to marketing.
TheBrockEllis 12y ago
As a new comer to Ember, I am quite confused as to the necessity of the Rails portion of the tutorial. I read through the intro and the first chapter and all I could gather was that it was for the "back end". I really wish there was a great, up-to-date tutorial that was back-end agnostic so that newbies don't have to possibly learn two new frameworks at once.
- genghisjahn 12y ago
  Totally agreed. I went glassy eyed at "First create new rvm gemset to sandbox our gems:" If you are a RoR person, I'm sure this tutorial is just great. But for the rest of us...
  - hpvic03 12y ago
    That's a valid complaint. I wrote it with a Rails backend because that's a pretty popular backend choice for Ember, and they work together well. Perhaps I can just extract out the Ember portion -- It should still be applicable regardless of the backend.
    - endemic 12y ago
      Maybe stub out the backend with an Express app? Express seems simple enough that even if you're not familiar with it, you can still understand what it's trying to do.
      - TheBrockEllis 12y ago
        And you'd keep most of the code in javascript so new comers wouldn't get "culture shock" by having to learn completely new syntax. +1
    - Nemcue 12y ago
      Do you even /need/ a backend though? It would be much simpler if you keep it entirely client side, using something like Pretender (https://github.com/trek/pretender https://github.com/trek/pretender).
cocoflunchy 12y ago
You shouldn't use Monaco as your only font for your pre and code elements. It comes up as sans-serif on windows and linux...
- hpvic03 12y ago
  Hmm.. what's a good alternative font?
  - zyxley 12y ago
    font-family: "Monaco", "Consolas", "Ubuntu Mono", "whatever", "other", "fonts", monospace;
    - hpvic03 12y ago
      Thx. Fixed.
pyre 12y ago
My favourite Ember (Data) quirk: this.get('store').createRecord('ModelName', { .. attrs .. }).save().then(function (model) { // Ember.isNone(model) === true }, function(error) { console.error(error); }); The fix: s/ModelName/modelName/ This works sometimes, and not others. The only indication of failure is the fact that the model is not loaded from the JSON response to the POST/PUT request. It's a subtle bug. I wasted a bunch of time tracking this down through the Ember Data internals (for a co-worker, but the original bug/typo could easily have been mine). The other quirk is converting snake case to camel case and back: address_1 =(to camelcase)=> address1 =(to snakecase)=> address1 Oops! We only use capital letters to determine where underscores go! ;-)
- Nemcue 12y ago
  This should be quite easy to fix, one would think. If the name can't resolve to a model class then it should be very vocal about it (i.e. throw error). I think you should create an issue for it on Github if there's not one already.
  - pyre 12y ago
    The funny thing was that the only thing preventing it from working (even though it shouldn't) was a one or two line change in the internal code that loads payloads into models. I actually thought that it was a bug until I realized what was happening (though it was still difficult because one of the methods that was being used is/was monkey-patched on at runtime, and therefore don't exist on any of the classes in the code).
basiliothecat 12y ago
Just finishing my first app using Ember and don't think that i'll go that route again. Speaking of which - this controller-route separation feels a bit unnatural. At least the way it's implemented. There are lots of good parts to it - that same convention of configuration saves lots of boilerplate, data binding is usually really nice, overal separation of concerns when doing it ember-way is rather good (far from great though), but lots of small nuisances here and there make up for a dubious overall experience.

127 points by hpvic03 12y ago

Good work, bro! Main criticism is that the 1st chapter took forever though.

I've been working with Ember over the past few months and am still impressed with how simple and productive it makes every day tasks. Basic CRUD stuff, especially render code, is a lot less drudge work. I'm even more excited for where the community is leading the framework, through projects like ember-cli and htmlbars. Ember is conceptually pretty massive though. A tutorial like Michael Hartl's Rails tutorial would be a huge benefit, it looks like that's what this is aiming for. Thanks!

HNJohnC 12y ago
I hope it works out for you but that's just about exactly how I felt immediately before I realized it was not going to work for a very large project, switched to Angular and haven't looked back since. There was no comparison at all for me between Ember and Angular but everyone's needs are different.
- sehr 12y ago
  What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.
  - deleted 12y ago
    [deleted]
  - pyre 12y ago
    Ember's examples on their site are always the simplest use-case. For example, find me an example on their site of saving a complex relationship that was newly created by your application. Let's take the example of an invoice. Let's say you have an Invoice model, and an InvoiceLineItem model in a one-to-many relationship. How do I save the creation of a new invoice (with line items) as a single transaction? As far as I can tell, you can't without breaking from Ember Data's very strict 'this is the way things should be done' model. You have to create a new Invoice, then create the InvoiceLineItems doing something like this: var self = this; self.get('store').createRecord('invoice', { .. attributes .. }).save().then(function (invoice) { return Ember.RSVP.all(self.get('lineItems').map(function (item) { return self.get('store').createRecord('invoiceLineItem', { invoice: invoice, .. attributes .. }).save(); }); }).then(function (invoiceLineItems) { // do something }).then(null, function (error) { console.error(error); }); Note that this isn't even taking into account how to rollback INSERTs if, for instance a single invoiceLineItem fails to be created. The 'other' way to do it is to create just an Invoice model, and have a lineItems attribute of type 'raw' and just create a RawTransform that's just as pass-through of whatever the JSON has for that attribute. It works, but at the same time, feels like it's going against the Ember Data Way, especially if you have a need for an InvoiceLineItem to be its own model (i.e. to be able to maintain relationships to other things and look one up by ID via the API). Then you might have something like: - Invoice and InvoiceLineItem models - A RawTransform: App.RawTransform = DS.Transform.extend({ deserialize: function (data) { return data; }, serialize: function (data) { return data; }, }); - An attribute like so (on Invoice model): lineItems: DS.attr('raw'), - Code that looks like this: var self = this; self.get('store').find('invoice', invoiceId).then(function (invoice) { self.get('store').pushPayload('invoiceLineItem', { invoiceLineItems: invoice.get('lineItems') }); });
    - lookingsideways 12y ago
      If your API supports it you can use the EmbeddedRecordsMixin[0]. In general though, what would be a sane default for handling multiple REST API calls to single-model endpoints? [0]: http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin.html http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin....
    - Nemcue 12y ago
      I really wish there was some thorough examples of using Ember + Ember-Data. Ideally it would be backend agnostic (mocked client side xmlhttprequest) and go from doing simple things like saving a model all the way to doing more complex things like you showed. Drupal for instance has a /really/ great project that maintains a bunch of thorough examples (https://drupal.org/project/examples https://drupal.org/project/examples) which were indispensable when I did Drupal a while back.
      - adamnemecek 12y ago
        There really should be better examples. In the mean time, you should check out the Balanced Dashboard, I've learned a good amount from it https://github.com/balanced/balanced-dashboard https://github.com/balanced/balanced-dashboard
      - pyre 12y ago
        It's kind of funny, but I don't even remember simple things being spelled out. For example, in their use cases all of the models and routes are single words like: post, comment, todo, etc. In some places, you see 'Post' and others 'post', but there is nothing explicitly spelling out how that works for multi-word items (e.g. MultiWord => multiWord). Same with underscores in route names (e.g. route name 'multi_word.item.index' => MultiWordItemIndexRoute).
        deleted 12y ago
        [deleted]
        zyxley 12y ago
        Yeah, the magic rejiggering of names everywhere with no clear documentation of what mapped to what† killed my interest in Ember the first time I tried to actually use it for even a fairly simple app. † Plus the enforced snakeCase/CamelCase everywhere, but that's more to do with me far preferring names_with_underscores in general.
pyre 12y ago
On the other hand, I've found many things lacking in Ember.js, though most of my gripes are with ember-data, so I don't know if you're thinking of that as part of Ember.js. A couple of examples of Ember.js-specific gripes though: - We have a table with one of the filters just stops working after changing the value 4 ~ 5 times. I've dug into this, but I can't really figure it out without going into the Ember.js internals (which I have done before, but the time sink isn't currently worth it). I've boiled it down to the fact that at some point Ember.js stops responding to changes on a particular attribute. Computed properties stop working sooner, but even a .observes('attribute') stops triggering after 5 or 6 changes. I get that software is not bug-free, but how am I supposed to even debug something like that? It would be fairly difficult (and time-consuming) to boil it down to a simple test case, as this is the only place we're seeing this happen and it's in a large Ember.js application. - There is no case/switch statement in Handlebars. I'm left with deeply nested if/unless blocks, or tons of computed properties on controllers/views that generate this stuff. E.g.: {{#if valueLoading}} Loading... {{else}} {{#if valueLoadingFailed}} Error! {{else}} {{#if value.length}} <ul> {{#each item in value}} <li> {{item}} </li> {{/each}} </ul> {{else}} No Items. {{/if}} {{/if}} {{/if}} vs. {{#if value.length}} <ul> {{#each item in value}} <li> {{item}} </li> {{/each}} </ul> {{else}} {{stateMessage}} {{/if}} ... and on the controller ... stateMessage: function () { return this.get('valueLoading') ? 'Loading...' : this.get('valueLoadingFailed') ? 'Error!' : this.get('value.length') === 0 ? 'No Items.' : ''; }.property('valueLoading', 'valueLoadingFailed', 'value.length'),
- nathanhammond 12y ago
  1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad. 2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.
  - pyre 12y ago

rubiquity 12y ago

The more I look at Ember the more it reminds of a framework named Batman[0] I used over two years ago. It's almost a complete replica, all the way down to Ember.Object being identical to Batman.Observable. The problem with Batman (aside from being buggy) was that it tried to do this same MVC that we use on the server on the client, and the mapping just doesn't make sense. HTTP "MVC" doesn't have state between requests whereas client-side MVC has state for the entirety of the app. Rails, for example, has a Router and Controller due to the synchronous nature of how a request comes in and gets turned into a response. The first place I see MVC JS frameworks fall apart is when they have both Controllers and Routers. Ember Controllers look like little more than Decorators. I imagine these would be called a ViewModel if named appropriately. Over two years later, I can't help but feel Backbone (minus the underabstracted View layer, which can be easily replaced with React) got the mental model for JavaScript apps right from the start. Ember just seems to have been marketed much better than Batman was, which is no surprise, Yehuda is good at doing that. 0 - http://batmanjs.org http://batmanjs.org

3pt14159 12y ago
Ember handles App state very well. It is easy to take advantage of local storage when you need it, and the way that changes in the data are bound with changes in the view makes it very easy to create pro-level web applications.
- deleted 12y ago
  [deleted]
- rubiquity 12y ago
  Nothing about what you just said is specific to Ember. Two-way data-binding is common in just about every framework, or can be added in cases like Backbone. Easily using localStorage is also common because just about every JS framework uses the Adapter pattern for persistence.
xiaomai 12y ago
> Ember just seems to have been marketed much better than Batman was, which is no surprise, Yehuda is good at doing that. I don't think this is fair. We use Ember at work, although I wish we used React. We started out on Backbone and it was miserable. Ember has gotten popular because it and Angular were seen as the successors to Backbone for a long time. Ember is designed in a much more thoughtful (and I think better) way than Angular. Yehuda has done a lot of good work on Rails, Bundler, jQuery. That probably helps sell people on his projects. I wouldn't chalk it up to marketing.

TheBrockEllis 12y ago

As a new comer to Ember, I am quite confused as to the necessity of the Rails portion of the tutorial. I read through the intro and the first chapter and all I could gather was that it was for the "back end". I really wish there was a great, up-to-date tutorial that was back-end agnostic so that newbies don't have to possibly learn two new frameworks at once.

genghisjahn 12y ago
Totally agreed. I went glassy eyed at "First create new rvm gemset to sandbox our gems:" If you are a RoR person, I'm sure this tutorial is just great. But for the rest of us...
- hpvic03 12y ago
  That's a valid complaint. I wrote it with a Rails backend because that's a pretty popular backend choice for Ember, and they work together well. Perhaps I can just extract out the Ember portion -- It should still be applicable regardless of the backend.
  - endemic 12y ago
    Maybe stub out the backend with an Express app? Express seems simple enough that even if you're not familiar with it, you can still understand what it's trying to do.
    - TheBrockEllis 12y ago
      And you'd keep most of the code in javascript so new comers wouldn't get "culture shock" by having to learn completely new syntax. +1
  - Nemcue 12y ago
    Do you even /need/ a backend though? It would be much simpler if you keep it entirely client side, using something like Pretender (https://github.com/trek/pretender https://github.com/trek/pretender).

cocoflunchy 12y ago

You shouldn't use Monaco as your only font for your pre and code elements. It comes up as sans-serif on windows and linux...

hpvic03 12y ago
Hmm.. what's a good alternative font?
- zyxley 12y ago
  font-family: "Monaco", "Consolas", "Ubuntu Mono", "whatever", "other", "fonts", monospace;
  - hpvic03 12y ago
    Thx. Fixed.

pyre 12y ago

My favourite Ember (Data) quirk: this.get('store').createRecord('ModelName', { .. attrs .. }).save().then(function (model) { // Ember.isNone(model) === true }, function(error) { console.error(error); }); The fix: s/ModelName/modelName/ This works sometimes, and not others. The only indication of failure is the fact that the model is not loaded from the JSON response to the POST/PUT request. It's a subtle bug. I wasted a bunch of time tracking this down through the Ember Data internals (for a co-worker, but the original bug/typo could easily have been mine). The other quirk is converting snake case to camel case and back: address_1 =(to camelcase)=> address1 =(to snakecase)=> address1 Oops! We only use capital letters to determine where underscores go! ;-)

Nemcue 12y ago
This should be quite easy to fix, one would think. If the name can't resolve to a model class then it should be very vocal about it (i.e. throw error). I think you should create an issue for it on Github if there's not one already.
- pyre 12y ago
  The funny thing was that the only thing preventing it from working (even though it shouldn't) was a one or two line change in the internal code that loads payloads into models. I actually thought that it was a bug until I realized what was happening (though it was still difficult because one of the methods that was being used is/was monkey-patched on at runtime, and therefore don't exist on any of the classes in the code).

basiliothecat 12y ago

Just finishing my first app using Ember and don't think that i'll go that route again. Speaking of which - this controller-route separation feels a bit unnatural. At least the way it's implemented. There are lots of good parts to it - that same convention of configuration saves lots of boilerplate, data binding is usually really nice, overal separation of concerns when doing it ember-way is rather good (far from great though), but lots of small nuisances here and there make up for a dubious overall experience.