---
layout: post
title: The quest on Ember.js
tags: [ development, ember, javascript ]
published: true
---

> `TL;DR` — I'm considering starting a series of screencasts on how to use
  Ember. Will you help me? Check the latest section at the bottom.

> Disclaimer — I have only begun looking into Ember a couple of days and
  shamefully haven't typed any code yet. This writing invites feedback and
  enlightenment.

I've been suggested [Ember](http://emberjs.com) as a strong alternative to
[Backbone](http://backbonejs.org) in order to build heavy client-side apps. I
tried Backbone in my spare time and it's awesome. However, I never had the
chance to use it in a real-life situation so I never really put it to a
stretch.

Lately I've been watching some videos on Ember and reading the guides over in
the tool's website and I must say I'm intrigued. Unlike Backbone – which is
more of a library –, Ember stands as a full MVC Javascript framework, and when
I say _full_, I mean it covers all the letters in the acronym and it does the
job in a slightly different way than we're used to. I'm writing down the sum of
my learning experience thus far so bear with me. : )

Controller: Stateless vs. Stateful
----------------------------------

All the hype on MVC is scoped to server-side, stateless frameworks like Rails,
Spring, Laravel, Play!, Django and [many
more](http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features).
The `HTTP` protocol's nature constrains the very controller's lifecycle and
purpose. A controller mediates the client and the server, providing a
representation of data that's stored in the latter and controlling the entire
logic of the application for a particular request.

If you're to use Ember.js, you need to purge that idea off your head because an
Ember controller is not sovereign in a request scope. In fact there is no
single request anymore, there's a bunch of tiny little controllers in a whole
ecosystem that is your app which happens to be enclosed in a single page. These
controllers live as long as you have the app running so they kind of become
stateful and are used more than once during their lifecycle.

Model: Persistence
------------------

As of a regular webapp, requests are made to the server and content is sent
back to the browser. We send forms to change the state of the app.

In Ember, all the communication to the server is done through `AJAX`,
preferably using something like [Ember.Data](http://github.com/emberjs/data), a
plugin that allows you to create persistable objects in your app. It's based
around `REST` so it should be easy to integrate with a Rails app or any other
framework that supports `REST`ful `URL`s and `JSON`.

You can still use regular `Ember.Object` classes to materialize domain objects
in your app. That was the whole point from the beginning of Ember's
development.

Persistence in Ember is actually a thing I find a bit more complicated than in
Backbone as the former requires a plugin, whereas the latter comes with
`REST`-based persistence built in. But again, I need to look into it a bit
more.

View: DOM integration
---------------------

The nature of a view is to provide a representation. It has the necessary power
to capture the representation's events and do something about them.

In stateless server-side apps, the view has no power: it's just an `HTML`
result. It might have a little Javascript to manipulate the DOM to an extent
but it will end up performing stateless requests to the server in order to
retrieve/send data.

### Backbone's Views

The `View` class in Backbone was built to have power over the DOM's events with
the `events` option:

{% highlight javascript %}
var TodoView = Backbone.View.extend(
  render        : function () { /* generate markup */ }
, events        : {
    "click .mark-complete": "mark-complete"
  , "change .body" : "update-todo"
  }
  
, mark-complete : function () { /* your code */ }
, update-todo   : function () { /* your code */ }
);

new TodoView({
  model : myTodo // instance of Backbone.Model
});
{% endhighlight %}

This example has:

* A `render` method which ideally generates the markup. You can use something
  like [Mustache](http://mustache.github.com) or
  [DoT](http://olado.github.com/doT/) to generate the markup and jQuery to
  manipulate the `DOM`.

  The actual content to be put on the page is not this view's responsability
  but another parent view or collection.
  
* An `events` option that specifies the events and the DOM element they affect,
  followed by the method to be called.

  Typically you update your data through these methods which, by turn, might
  trigger other events in the whole app. You register those bindings yourself
  as you build the app.
  
* All the methods defined in the `events` option.

Notice that you pass a `Backbone.Model` instance when creating a new view.

### Ember's Views

One of Ember's base features is _data binding_. Not only do objects bind
themselves but also the DOM stays updated by the same principle. If you make a
change in an object, the [Handlebars](http://handlebarsjs.com)-powered views
are instantly updated. Unlike Backbone, all the object to DOM binding is
seamless and it just works. That might be the coolest feature they have, in my
opinion.

#### Create a view

1. Create a Handlebars template in the page (don't worry, it won't be visible
   in the browser):

{% highlight text %}
<script type="text/x-handlebars">
  {{"{{#view App.TodoView" }}}}
    <input type="text" {{bindAttr value="body"}} />
  {{"{{/view"}}}}
</script>
{% endhighlight %}

2. Create a View object in your app:

{% highlight javascript %}
App.TodoView = Ember.View.extend({
    change: function() { /* update object */ }
});  
{% endhighlight %}
  
Ember views come packed with a series of custom handlers that represent the
various DOM events. In this case, `change` refers to when the input changed its
value.

Even though this approach looks more complicated, there are features in Ember
that make up for it. I still haven't delved deep enough but I noticed the
particularity.

* * *

There are a lot of other reasons for me to stick with Ember for a while. I'm
interested in knowing how statecharts and routing work. Also, the tightness and
opinionated nature of the framework made me curious as to how much of the
boilerplate is removed.
  
So I have a question for you.
-----------------------------

The title of this writing has a point.

I screencast often even though I don't bring that out too much. Anyway, I would
love to record a series of videos (preferably with someone else) in the near
future on this topic, one
[pomodoro](http://en.wikipedia.org/wiki/Pomodoro_Technique) at a time. All the
process on _design thinking_, _implementation_ and _trial & error_ would be
part of the videos. _Would you be interested in joining me?_ Remember, the
whole point of this is to develop a solution in the aspect of a rookie.

Screencasting is a hard job and it takes (a lot of) time. I'm facing a
challenge in doing this as I consider Ember to be steep to learn, but enticing
at the same time. Also, it seems there aren't many examples on how to implement
an end-to-end application if ever so lightly. A sponsor would be a great
incentive for me to rush things up and start sooner than I expect. _Would you
be interested in sponsoring the series?_