
Ember Tutorial - hpvic03
http://ember.vicramon.com/
======
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](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.

~~~
walkon
> We use Ember at work, although I wish we used React.

Could you expand on why you prefer React? I have not tried React yet, but am
interested to hear thoughts from someone who's used both.

~~~
adamnemecek
I'm interested in that too. Is it fair to compare Ember and React though? It
seems like they are trying to solve different issues.

~~~
KurtMueller
Think of Angular directives, Ember components, and React components as
attempting to solve the problem of web components in your view.

I'm using react right now in a rails application at work. While it hasn't
totally replaced my haml views, I definitely sprinkle it in where appropriate.
It does a great job of handling dynamic uis and gives a standard, easy to
understand structure to my javascript. I think of it is as a next step beyond
jQuery.

In my opinion, React forces you to think of your view as a hierarchy. You are
forced to think about what components make up your view and what its
responsibilities should be. React components also come with some standard
methods in regards to the lifecycle of each components and the state of your
data as it flows up and down the hierarchy of your components.

I've really enjoyed the experience thus far. I'm not necessarily a fan of
putting any sort of html-like structure in my javascripts, but Pete Hunt, one
of the core contributors to React, explains his reasonings quite well in many
talks you can find on Youtube.

\--

Also, Khan Academy uses Facebook React in its perseus q&a system. You can view
blog posts by two Khan developers about React here:

[http://benalpert.com/2013/06/09/using-react-to-speed-up-
khan...](http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-
academy.html)

[http://joelburget.com/backbone-to-react/](http://joelburget.com/backbone-to-
react/)

~~~
adamnemecek
Indeed but Ember components are only a part of the Ember framework.

What you describe in the rest of your comment is equally applicable to Ember
(if not more, since Ember goes beyond the view layer).

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

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

This was a single value (e.g. 'selectedItem') populated by a Ember.Select
view/component. After changing the selection a number of times, all things
watching 'selectedItem' completely stop firing off (until a page refresh). No
idea why.

~~~
nathanhammond
There is going to be some future work on some of the form elements. They're
really not quite where they need to be.

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

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

~~~
Nemcue
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)).

~~~
hpvic03
To persist data you'll want a backend. That's a fairly important piece of any
application which is why I included it in the tutorial. You could ignore the
Rails parts of the tutorial and create your own backend.

~~~
pyre
Persist across clients, maybe, but it's also possible to use localStorage to
persist data on a single client.

~~~
TheBrockEllis
You could also use something like Firebase as a datastore that could persist
across multiple clients but also be implemented in javascript.

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

~~~
pyre
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).

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

~~~
zyxley
font-family: "Monaco", "Consolas", "Ubuntu Mono", "whatever", "other",
"fonts", monospace;

~~~
hpvic03
Thx. Fixed.

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

