Ember Tutorial

[rubiquity]

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

[xiaomai]

> 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.

[steveklabnik]

> The first place I see MVC JS frameworks fall apart is when they have both Controllers and Routers.

You have to remember that MVC is a very, very loosely defined term. The Ember MVC is very, very different than the Rails MVC. Ember's is much closer to Cocoa or Smalltalk in this regard.

To see how these bits fit together in Ember, I highly recommend seeing Tom's talk on URLs and their importance: http://vimeo.com/77760308 (you can skip the first 12:35 or so, and around 30:38 is where it really gets into it.)

[jashkenas]

The reason why Backbone views are so minimal is precisely so that you can use the HTML/UI abstraction of your choice.

For some teams that's Underscore templates, for some it's Handlebars, for some it's in-house widget libraries, for some it's React.

[Nemcue]

> "(...) got the mental model for JavaScript apps right from the start."

If you remove the Views from Backbone the only thing left of value are the Models and Collections. Are you saying they got those "right"? I really have no idea what that means. On the contrary — I think Backbone got a number of things wrong. Their router especially.

> "Ember just seems to have been marketed much better than Batman was (...)"

You said that Batman was buggy and got MVC wrong. Perhaps Ember is /not/ buggy and actually manages to deal with state quite well?

[3pt14159]

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.

[chrishenn]

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!

[pyre]

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'),

[HNJohnC]

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.

[TheBrockEllis]

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]

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...

[pyre]

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]

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.

[cocoflunchy]

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]

Hmm.. what's a good alternative font?

[basiliothecat]

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.

[ulisesrmzroche]

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