José Mota — The blog

The quest on Ember.js

16 August 2012

  • development
  • ember
  • javascript

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 as a strong alternative to Backbone 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. 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, 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 RESTful URLs 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:

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
});

This example has:

The actual content to be put on the page is not this view's responsability but another parent view or collection.

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.

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-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):
<script type="text/x-handlebars">
  {{#view App.TodoView}}
    <input type="text"  />
  {{/view}}
</script>
  1. Create a View object in your app:
App.TodoView = Ember.View.extend({
    change: function() { /* update object */ }
});  

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

Creative Commons License

comments powered by Disqus