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

[nathanhammond]

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.

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

[sehr]

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.