
Advice On & Instruction in The Use of Ember.js - tomdale
http://trek.github.com/
======
fusiongyro
Here's my petition for the site to join the contrast rebellion:

<http://contrastrebellion.com/>

The page is basically unreadable in FF 7.0.1 on RHEL 5.3. I realize light grey
on white with a really thin font is dead sexy on your Mac (probably looks
great on my home computer as well) but it's useless to me at work.

~~~
trek
I agree. You should take this up with the Github page folks, specifically
<https://github.com/orderedlist>. It's his template.

~~~
fusiongyro
Thanks for changing this. You didn't have to, but it really helps, and I'm
looking forward to really giving it the close read it deserves tomorrow.

------
skilesare
I've now shipped an Ember.js application and a knockout.js application. I
enjoyed ember quite a bit but feel that knockout gives me all the magic with
half the complexity.

It is true as the author mentions that it doesn't aim to fix the
UI/statefullness issue, but I slapped on Backbone Routing on to my knockout
code and it made capturing 'state' and urls a breeze.

The last time I used ember was 0.9.6 and I don't think this routing stuff was
even in it so I was excited to see talk about it. Unfortunately it looks to be
even more complicated then I expected it to. :(

Knockout may be creating some massive memory footprint in the background that
will bite me down the line, but I'm writing significantly less code than I was
with Ember. For example, In ember you have to create view objects and if you
want your view objects to sync data with your controller you have to
explicitly define them:

App.userController = Ember.Object.create({

    
    
      content: Ember.Object.create({
    
        firstName: "Albert",
    
        lastName: "Hofmann",
    
        posts: 25,
    
        hobbies: "Riding bicycles"
    
      })
    

});

App.UserView = Ember.View.extend({

    
    
      templateName: 'user',
    
      firstNameBinding: 'App.userController.content.firstName',
    
      lastNameBinding: 'App.userController.content.lastName'
    

});

Now I get to do my handlebars template <script>

<div>{{firstName}}</div>

</script>

In knockout just have to do: App.UserController = {

content = ko.observable(new content());

}

ko.applyBindings(App.UserController);

And now I get to do a knockout template inline with my html:

<div data-bind="text: content.firstName"></div>

It just seems like there are fewer steps with knockout and I'm getting more
done. The html is a lot uglier, but it also clearer what is going on when I
read it.

The ember guys have come a long way on their doc and they should be commended
on it. I like the patterns they are talking about I'm just not sold that it
has to be done the way they are doing it. Thanks to the author for putting
together such an in depth post to me in the right direction in getting back
into Ember.

~~~
gfunk911
That's not really accurate. There are several shorter ways to do that in
Ember.

    
    
      App.UserView = Ember.View.extend({
        templateName: 'user',
      });
    

View:

    
    
      <script>
      <div>{{user.firstName}}</div>
      </script>
    

No need for the intermediate bindings. Effectively this is what you're doing
in Knockout with the "content." prefix

~~~
skilesare
But what are you binding to? If it is something in your controller you have to
explicitly add it with the myvarBinding declaration.

------
tberman
As the guy who wrote the first bits of the Rdio code in question, it seems
worth mentioning that the part in question has nothing to do with Backbone, or
Ember, or anything else. That code is a cleanup function on an object that
helps to abstract HTML5 <audio> vs our Flash fallback.

No matter what framework you are using, if you are solving the problems that
we are solving, you are going to end up with that code.

Now, that said, I agree that learning all of the frameworks out there is
advantageous, but you can't assume that the code in the blog post is
indicative of anything having to do with Backbone or any other framework.

~~~
trek
Is this _entirely_ true? Clearly cleanup of event names like "loadedmetadata"
is related to the audio element but '_bubbleProfilingEvent', '_logEvent', and
general .unbind calls are on backbone-related objects, yeah?

~~~
jmtulloss
The only backbone related code in that snippet is the .unbind() call and the
.trigger call. This is needed because this is our wrapper around the media
element; it is an event emitter. If you're going to make something emit custom
events, you'll need code to emit them and clean them up when you're done.

One area where backbone is lacking is lifecycle management. You do sometimes
have to unbind things in order to prevent leaks. Backbone is very minimal in
this regard. At Rdio, we've built our own tools on top of Backbone to abstract
lifecycle away from the developer as much as possible. That being said, that
weakness isn't illustrated in the code example picked by the blog post.

------
judofyr
Let me tell you why I don't care about Ember.js at the moment:

It's an "all or nothing"-solution. I couldn't care less about Stateful Single-
Page Applications. I'll take a stateless, curlable, crawlable (remember
Google?), old-style web site _any_ time. Of course, some parts might require
more dynamicness than other, and in that case it's _lovely_ to jump to client
side MVC. But it doesn't seem that Ember.js wants to play this game. Every
time I look at Ember it seems that it wants to define the architecture of my
application. Thank you very much, I like my stateless-ness very much!

~~~
wycats
> I couldn't care less about Stateful Single-Page Applications. I'll take a
> stateless, curlable, crawlable (remember Google?), old-style web site any
> time

I take it that all of your applications involve public content with minimal if
any enhancements to logged in users?

~~~
judofyr
Yes, but even from a user's point of view I'm delighted when I use stateless
web "apps". Facebook is an excellent example: There's quite a lot of AJAX-
magic, but it still feels (and functions) as a stateless web site. No silly
"double loading"; easy to bookmark; links I can Cmd-Tab; the page doesn't
magically fail when my internet connection is broken.

I am aware of that most the issues with single-page applications comes from
the applications themselves, not the architecture (i.e. is the developers',
not the technology's fault) but there seems to be quite a lot of complexity
with this architecture. I've seen very few applications that handles all of
these issues.

~~~
wycats
> Yes, but even from a user's point of view I'm delighted when I use stateless
> web "apps". Facebook is an excellent example: There's quite a lot of AJAX-
> magic, but it still feels (and functions) as a stateless web site.

> No silly "double loading";

What does double-loading mean?

> easy to bookmark; links I can Cmd-Tab;

The primary goal of the Ember router is to provide this functionality out of
the box. The reason you get a single callback with an object regardless of how
you arrived at a given state to is to ensure that entering through the router
(cmd-tab, bookmark) is the same as transitioning in the app.

If you use the router with the Ember `{{action}}` helper, there isn't really
any way to have URLs that don't have the features you desire.

> the page doesn't magically fail when my internet connection is broken.

I don't know exactly what this means. Surely when your internet connection is
broken, regular "stateless" pages don't work either?

Are you just saying that there are fewer problem states as an end user? Either
the page loaded or it didn't? I've personally had a ton of issues with
Facebook Ajax requests failing when I'm in a flaky connection scenario
resulting in a generally unusable page.

Can you elaborate on what you mean here?

~~~
sirclueless
> What does double-loading mean?

Basically, a web app that is usable (or at least readable) before all your
JavaScript initialization is done. With Facebook, as soon as the HTML and CSS
hits your browser it can render a more or less complete page. With Ember.js,
that doesn't happen until the application is initialized and all your
templates are rendered.

~~~
eddieplan9
To be fair, that totally depends on how the application is written. You can
have server-side-rendered page with single-page application, with or without
Ember.js.

~~~
sirclueless
With Ember.js the routing framework is client-side and Ember.js stores all
dynamic values in the URL fragment. The server doesn't see enough information
to render a page, even if you were willing in theory to duplicate your
rendering logic server-side.

~~~
eddieplan9
You can use HTML5 pushState in Ember.js [1] and Backbone so application state
is captured in actual URL path instead of URL location hash. The server can
see enough information to render a page.

[1] [http://www.kaspertidemann.com/how-to-make-ember-js-use-
histo...](http://www.kaspertidemann.com/how-to-make-ember-js-use-history-
states-for-routing/)

------
railsjedi
Perfect article and explanation. After having bought into Ember a couple
months ago and using it heavily, it's been really hard to express to others
why it feels so revolutionary.

Ember really changes JS development in ways that the other frameworks don't
even attempt. And in a way this hurts it in the perception of developers,
since it more often than not is just tagged as "too complicated" or "too much
to learn".

The more great articles like this, and I think there'll be a solid chance
Ember catches on in a big way the same way Rails did. With 1.0rc, the tech
seems to be solid enough now and it just needs a push on the other stuff
(education, marketing, etc). And most importantly: some more successful Ember
apps out in the wild (I'm working on that one).

~~~
MatthewPhillips
But Rails was built for a different world, so trying to recreate what made
Rails nice in the browser feels like an answer searching for a problem.
Client-side JavaScript frameworks should be compared to UIKit and the Android
SDK, not to Rails, which was only interested in routing, fetching, and
rendering. Giving me code organization without giving me structure is only
helping with a tiny sliver of the problem.

~~~
railsjedi
Sorry, I just meant compared to Rails in terms of impact. Ember is nothing
like Rails architecturally. There's a good comparison here:
<http://emberjs.com/guides/ember_mvc/>

So yeah. Ember's problem is convincing people there's a problem (hint: there
definitely is).

~~~
MatthewPhillips
Those are implementations details, to the developer they serve a similar
purpose. This is my problem with it, a web framework that gives equal weight
to M, V, and C is missing the point; in the client the View is _fucking
everything_. It is where any developer will spend the vast majority of their
time; not in code organization. The frameworks and I mean this plurally, that
win will be those that give structure to applications. Here's how the Android
SDK provides structure to applications:
[http://developer.android.com/design/patterns/app-
structure.h...](http://developer.android.com/design/patterns/app-
structure.html). Web frameworks need the same thing. They should ship with
HTML, JS, and CSS.

~~~
jguimont
Then you do not understand what M and C does. It might be called a client but
it is a stateful client. Views come and go , you organize your code in C and M
and you'll have a robust long lasting application (in a desktop app, a mobile
app or a browser app).

~~~
MatthewPhillips
> Views come and go , you organize your code in C and M and you'll have a
> robust long lasting application (in a desktop app, a mobile app or a browser
> app).

That's because we're not writing good reusable views. We're writing one-off
views that corresponding to the current needs of the current application we're
working on. Here's a good view:
[http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/...](http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UITabBar_Class/Reference/Reference.html#//apple_ref/doc/c_ref/UITabBar)

It was created 5 years ago and I'm pretty sure it's got a lot of life left in
it still.

------
drek
Does anyone else thing that the documentation for ember.js is really lacking?
Some of the classes it has aren't even documented (ContollerMixin comes to
mind) and others are lacking in the documentation depratment. Also, I don't
seem to be able to find a full listing of instance methods for a class, I have
to climb up the inheritance tree in the docs class by class.

~~~
Vekz
I have to agree. I found my self reading the source a lot while working with
ember. That lead to discovering said hidden classes like ControllerMixin.

------
tgriesser
With regards to view cleanup code in Backbone - in the github develop branch
[1], the view is now a little more active in its memory cleanup. A dispose()
function was recently added which removes any handlers added in the view's
'events' object, as well as any collection or model listeners where the view
is passed as the third argument (callback context). This function is also
called by the view's .remove(), taking care of the majority of basic memory
cleanup needs when the element is cleared from the screen.

[1]:
[https://github.com/documentcloud/backbone/commit/3ae1af6df1b...](https://github.com/documentcloud/backbone/commit/3ae1af6df1b542bfb3e38f2fdfe7a471f2b830a0)

~~~
judofyr
You can also use Coccyx [1] which clears events on all objects (not just
this.model and this.collection) and also adds recursive view disposal.

[1]: <https://github.com/onsi/coccyx>

------
programminggeek
Ember looks cool, but knockout lets me ship fast and it's less "magic".

Also, I think single page apps have a place as part of a greater architecture,
but not as the entire app. If I wanted an entire app everything to be JS,
fine, use Ember or something like it, but most parts of the web don't need
this and single page apps make the web a bit worse if not done correctly.

Single page apps are the new hotness, but once the fad is over and the newness
wears off, they'll be fit into their proper place over time and won't take
over the entire app.

~~~
wycats
> Ember looks cool, but knockout lets me ship fast and it's less "magic".

I'd appreciate it if you could quantify what you mean exactly by "magic". For
example, one key difference between Ember and Knockout is that Ember's binding
system automatically avoids triggering the same side-effect from multiple
pieces of code.

For example, if you had a piece of the DOM that was calculated from several
observables (the stupid example is a full name calculated from a salutation,
first name and last name), and made changes to all three of those in separate
lines of code (possibly in different areas of your codebase), Ember would
ensure that the DOM only updated a single time, not three times. This is true
no matter where the three lines of code are, without you needing to take any
special action to coalesce the changes.

This aspect of Ember's codebase adds some magic, in that it introduces a
higher-level abstraction that knows about computed properties and their side-
effects (the "run loop"), but the end result is more predictable propagation
of side-effects in an Ember application. Ember applications don't need to know
about the specific mechanism that makes this work, but good Ember developers
are aware that many side-effects happen asynchronously in an Ember
application.

The browser does something similar when you make changes to DOM structures: it
only updates the rendered version of the DOM once all of the JavaScript code
handling an event has completed.

I would agree that something simpler would probably be a better fit for simple
"islands of richness" on an existing application, but there are definitely a
large number of applications with significant amounts of logic happening on
the client side, even if those applications run inside of an area of a larger
traditional page.

In general, I would say that Ember is a good fit for applications that will
end up with more than 100k of application code. That sounds like a lot of
code, but it's really only a lot of code for islands of richness. Applications
like rdio, documentcloud, soundcloud and other popular Backbone applications
can easily reach 500k or even a megabytes or two of code.

~~~
skilesare
I think ember and knockout do the same thing here. In fact my impression was
that knock out actually only rerenders the part of the template that was
affected while ember does the whole view. This may have changed since 0.9.6.

------
Vekz
Glad to see this article. The recent buzz around convention and best practices
in Backbone.js has been frustrating. A lot of the recent Backbone discussion
are issues that have been thoughtfully addressed in Ember.js.

I feel that Backbone.js was first on the scene and hence has found its way
into the current developer lexicon and toolset, leaving Ember.js unfairly
looked over.

------
KaoruAoiShiho
As I said in another thread, despite hilarious disagreement by jashkenas,
<http://news.ycombinator.com/item?id=4427974> that Backbone is perfect for big
projects so long as you build on top of it with other libraries.

Ember.js is just too opinionated for its own good.

------
adolph
This is such a timely article, thanks! I was just listening to the video on
this week's JavaScript Weekly and considering where to start among the js
application frameworks. It would be nice if the author expanded on the
different categories of js app frameworks.

Video: Beyond the DOM: Sane Structure for JS Apps:
<http://www.youtube.com/watch?v=cd7HHN6IkrU>

------
aidos
For anyone trying to follow along with the tutorial beware that there's a typo
the whole way through the code that stops it from running.

connnect -> connect

------
adamnemecek
Speaking of which, can anyone recommend good ember.js resources and/or open
source projects? Something that is not a todo list would be great.

~~~
railsjedi
pangratz has created an awesome example dashboard app (along with source)
<http://code418.com/ember.js-dashboard/>. He also wrote up a dev blog series
on it: <http://code418.com/>

------
robotmay
Do any of these JavaScript frameworks have decent documentation yet? API docs
are all well and good, but I'd really like some examples other than to-do
applications. All they really need is an equivalent to the Rails guides at
<http://guides.rubyonrails.org>, which are ample.

Frankly I'd take any example application over a to-do app at this point.

As an aside, I've been using Sammy.js (<http://sammyjs.org>) more than most of
these other frameworks lately, as the effort involved is disproportionate to
the rewards unless you're building the entire frontend in JavaScript. For any
less-than-enormous project, you really don't need all that complexity.

~~~
bertomartin
Heard about sammy, but never looked into it until now. It looks really
interesting. I've been looking at emberjs for the past couple of days and I do
like what I see, but I always felt it was a little too heavy for what I really
wanted. I'm just not ready to make my app just an api enpoint...it's just too
much abstraction. Regardless, I'll continue to follow emberjs.

------
throwa
Emberjs in production:

[https://github.com/emberjs/ember.js/wiki/Production-
Deployme...](https://github.com/emberjs/ember.js/wiki/Production-Deployments-
Page)

------
shocks
<http://emberjs.com/>

The font here really sucks, for me anyway. I cannot see the "cross" of the t.
It just looks like an l. Anyone else see this?

------
leepfrog
fantastic article!

~~~
blktiger
+1

------
inetsee
Can anyone tell me whether a website built with Ember.js's default settings
suffers from the same readability problems with font and contrast? If so, that
tells me that I probably won't want to invest any time in learning to use
Ember.js.

~~~
tomdale
Is this a serious question, or just snark? Ember.js does not ship with a
default stylesheet—it's up to you to style. It just generates plain HTML.

~~~
inetsee
This was a serious question. My vision is not what it was when I was younger.
I am finding more and more websites are very difficult for me to read, and
this one was unreadable for me without the help of Evernote's Clearly
extension.

I am a firm believer in the utility of web frameworks, and I'm always willing
to look at new ones. I assumed that the tutorial website had been built using
Ember.js, and my first impression was not favorable.

~~~
inafield
You may need to adjust your monitor settings or buy a new monitor. The
difference between #232323 and #FBFAF7 should be enough contrast. The Trek
logo is even higher contrast as #FFF and #171717.

~~~
mikejarema
I believe trek has updated the site's theme in the interim. I was also having
some contrast and font size issues, and the new theme definitely addresses my
complaints.

