Avoiding Memory leaks with CanJS

If you are building a single page application memory leaks can be a real problem, specially if you are application is meant to stay on the screen for long periods of time without the user refreshing it.

In this post I want to show how you can effectively avoid these leaks when developing with CanJS.

Example

For example the following control creates two potential memory leaks:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var Control = can.Control({
  init: function (ele, options) {

      // # 1
      window.on('resize', function (event) {
          // ... do something on resize
      });

      // # 2
      setInterval(function () {
          // ... do some polling
      }, 2000);

  }
});

When the control is initialised, we are listening to the window resize event (#1) and creating a timeout (#2). Everything is fine until the control is removed from the DOM.

When the element is removed from the DOM we will end up with a ghost object still listening for the resize event and still running an interval, even if there is nothing in the DOM.

If we don’t unbind the events properly the browser doesn’t have a way to know that our control object should be garbage collected. We have created a memory leak.

This gets even worst if we have an application that adds and removes a control several times, which is normal in an application with multiple views. In that case we just keep piling ghost objects potentially consuming a lot of memory and creating strange bugs as we have multiple unintended objects listening to the same events.

The CanJS way

Getting rid of the first memory leak is quite easy in CanJS, instead of binding the event manually like shown above, you use the special CanJS syntax:

1
2
3
4
5
6
7
8
9

var Control = can.Control({
  init: function (ele, options) {

  },

  '{window} resize': function () {
      //... do something on resize
  }
});

The {window} resize declaration tells CanJS to listen for the event we want but unbinding it automatically when the control is destroyed.

The destroy method

The second leak has to be removed a bit more manually:

1
2
3
4
5
6
7
8
9
10
11

var Control = can.Control({
  init: function (ele,
      this.interval = setInterval(function () {
          // ... do some polling 
      }, 2000);
  },

  destroy: function () {
      removeInterval(this.interval);
  }
});

We need to manually remove the interval in the destroy method of our control, the good thing is that we don’t need to call this destroy method manually if we follow the correct pattern below.

Destroying a control

CanJS will destroy a control automatically when its element is removed from the DOM. But you have to be sure that the element is removed, not just reused.

For example, this wouldn’t work:

1
2
3
4
5
6

// Create a control using an existing element in the DOM
var controlA = new ControlA($('existing-element'), {});

// Later reuse the element for a different control
var controlB = new ControlB($('existing-element'), {});
// This will not call destroy() on controlA

On the other hand, removing the element first will give us the behaviour we expect:

1
2
3
4
5
6
7
8
9

// Create a document fragment first 
// this will be used as the element for the new control
var view = $('<div>');

// Create the control, and pass the newly created element fragment
var controlA = new ControlA(view, {});

// Append that newly created element to our container
$('.my-app').append(view);

1
2
3
4
5
6
7
8
9

// Later when replacing this control make sure to remove the element first
$('.my-app').empty();

// Removing the control element will automatically call .destroy on your control

// Repeat the process for the new control
var view = $('<div>');
var controlB = new ControlB(view, {});
$('.my-app').append(view);

By removing the elements entirely from the DOM, CanJS will trigger destroy and unbind the events. So that’s it, avoiding memory leaks is quite straight forward when following the right patterns.

During my time using CanJS I haven’t found a canonical way of doing form validations with it, so here I want to share the way I am doing them at the moment.

First let’s start with a model:

1
2
3
4
5
6

var Person = can.Map({
  init: function () {
      this.validatePresenceOf('firstName');
      this.validatePresenceOf('lastName');
  }
}, {});

This model is using the validation plug-in to mix-in the validation functions.

Then we need a control:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

var Control = can.Control({

  init: function (ele, options) {
      this.person = new Person();
      this.errors = new can.Map();

      var args = {person: this.person, errors: this.errors};
      var view = can.view('view', args);
      this.element.html(view);
  },

  'form submit': function () {
      // get errors from person if any
      var errors = this.person.errors();

      // pass the errors to our errors observable
      this.errors.attr(errors, true);

      if (errors) {
          console.log(errors);
      } else {
          // proceed to saving here
      }
      return false;
  }

});

Note how I create a errors can.Map and pass it to the view. This map will allow me to show any validation errors to the user. In form submit we retrieve the errors from the form (using the validation plug-in) and pass those errors to the errors can.Map.

Our view looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<script type="text/mustache" id="view">

  <form>
      <label for="first_name">First Name:</label>
      <input type="text" can-value='person.firstName' name="first_name" />
      {{showErrors errors 'firstName'}}
      <br>

      <label for="last_name">Last Name:</label>
      <input type="text" can-value='person.lastName' name="last_name" />
      {{showErrors errors 'lastName'}}
      <br>

      <input type="submit" value="Save" />
  </form>
</script>

Note the showErrors helper. Which looks like this:

1
2
3
4
5
6
7
8

Mustache.registerHelper('showErrors', function (errors, prop) {
  var attr = errors.attr(prop);
  if (attr) {
      return prop + ' ' + attr[0];
  } else {
      return '';
  }
});

This helper will display the error an error to the user if there is any.

Here is a fiddle with a complete example.

Here is a simple tutorial on how to build a filtered list in CanJS. For example, lets say that we have a list of people and we want to display people that have birthdays this month.

Our mustache template would like something like this:

1
2
3
4
5
6
7
8
9

<script type="text/mustache" id="view">
  <h2>Birthday this month</h2>

  <ul> 
      {{#birthdayThisMonth people}}
          <li>{{name}} - {{birthdate}}</li>
      {{/birthdayThisMonth}}
  </ul>
</script>

people is a CanJS model list , birthdayThisMonth is a Mustache helper. This Mustache helper looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

birthdayThisMonth: function (people, options) {
  var person, bd, bdMonth, thisMonth;

  if (people && people.length) {
      var res = [];
      for (var a = 0; a < people.length; a++) {
          person = people[a];
          bd = person.attr('birthdate');
          bdMonth = new Date(bd).getMonth();
          thisMonth = (new Date).getMonth();

          if (bdMonth === thisMonth) {
              // we want to display this birthday
              // so add this to the array
              // options.fn is a function that will return the final string using the mustache template
              res.push(options.fn(person));
          }
      }
      // we have an array, but we need to return a string
      return res.join(' ');
  }
}

Then we just need to pass the helper to the view (or declare it as global helper):

1
2
3
4

var helpers = {
  birthdayThisMonth: function (...) { ... }
}
var view = can.view('view', {people: people}, helpers);

JsBin here.

Some time ago I read the book Practical Object-Oriented Design in Ruby by Sandi Metz, while an excellent book there is one thing that bothered me while reading it.

That is the pattern for dependecy injection proposed on the book. It goes something like this:

1
2
3
4
5
6
7
8
9
10
11

  class Car
    def initialise(engine)
      @engine = engine
    end

    def start
      engine.start
    end
  end

  car = Car.new(engine)

In this example the class Car takes an engine dependecy, each time you want to create a car you have to pass an engine to it. This can easily become a cumbersome way of instantiating objects because you need to know a lot about your object just to create them. In this case I need to know that Car takes an engine and specifically which engine depending on the type of car I want to create.

To deal with this the suggested solution is to use an injector. See the definition in wikipedia. The injector is in charge of creating the instances you need and injecting the right dependecies.

Although this is a powerful pattern I believe it mostly an unnecessary complication, specially in dynamic languages like ruby. Let me explain why.

What do we want to achieve with DI?

The main reason for using DI is to be able to swap the dependencies of an object at run time, this is mostly useful for testing. To achieve this there is a dead simple way to do it without having to deal with the complexity of injectors.

The simple way to do it

Instead of passing the dependecy when instantiating an object, we can simply let the object have default dependecies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  class Car

    attr_writer :engine

    def start
      engine.start
    end

    def engine
      @engine ||= Engine.new
    end
  end

  car = Car.new

If we just create a car we get a default engine for it, so we don’t need to bother with injectors.

What do we gain:

• External code doesn’t need to know about the internals of our objects
• We have sane default dependecies
• We can easily swap the dependecies at run time

In your test you can simply do this:

1
2
3
4

  car = Car.new
  car.engine = FakeEngine

  car.start

So that’s it, DI doesn’t have to be complicated at all in ruby.

The Go programming language has capture my attention lately. There are several things I really like about:

• Simplicity: Go is a small language but still very flexible, I appreciate this simplicity as it can be learnt fairly quick.
• Static typing: I like knowing that my code is correct without having to write a bunch of test you to deal with the lack of static typing.
• No classes: Instead of classes Go simply uses interfaces to determine what objects has what methods, I personally find this a flexible and powerful approach.
• Concurrency primitives: Go has baked in all the necessary language constructs for dealing with concurrency in a clean and coherent way.

As part of learning Go I wanted to compare how concurrency compares to Node. For this I created a simple prototype that captures a common pattern:

• Fetch two values from different urls in parallel.
• When those two values have arrived, send them together to another url.

The Server

I made a simple Node server for this. The code is here. This server has the following API:

• http://localhost:8080/x => returns “Hello”
• http://localhost:8080/y => returns “World”
• http://localhost:8080/concat?x=value&y=value => takes two values and returns them concatenated

The Node Client

For the Node code I am using promises, here is the complete client code in JavaScript.

Note the following lines:

1
2
3
4
5
6
7
8
9
10
11
12

var request = require('request');
var Q = require('q');

var defX = Q.defer(); // will be resolved when x arrives
var defY = Q.defer(); // will be resolved when y arrives

var oneAndTwo = Q.all([defX.promise, defY.promise]).then(processConcat);

var baseUrl = "http://localhost:8080";

request(baseUrl + '/x', makeValueHandler(defX));
request(baseUrl + '/y', makeValueHandler(defY));

I create two deferreds: defX and defY. Then I create a promise that is the combination of defX and defY.

Immediately after that I make the first two calls to the server in parallel. When those to calls are done the deferreds will be resolved and the function processConcat will be called with the results (in the correct order).

The JavaScript code is not complex but is not completely straightforward either, you still need to scan up and down when reading the source code to understand exactly what is happening.

The Go Client

The complete client in Go is here.

The key lines of code are below:

1
2
3
4
5
6
7
8
9
10

var cx chan string = make(chan string)
var cy chan string = make(chan string)

go getValue("/x", cx)
go getValue("/y", cy)

x := <-cx
y := <-cy

processConcat(x, y)

Here we create two channels (a way of communicating when using concurrent processes in Go), one for value x and the other for value y.

Immediately after that we fetch the values from the server but using the special go keyword. This means that those call will be made in their own processes so they will not block. These two requests happen in parallel.

The next two lines wait for the results of the API calls, the results are communicated using the channels.

The Go code looks a lot like typical sync code but still it is all happing in parallel thanks to the goroutines. So this code is as fast (event faster) than the Node version but simpler to understand IMO.

Conclusion

I am excited about Go, it has a lot to offer in multiple spaces. I will like to explore how something like Node Streams will look in Go.

There is a typical progression when developing an application. First we start with something simple, with a few models, things are simple to test. At this stage we can afford to build all the objects we need in our test without too much concern for speed and complexity.

1
2
3
4
5
6

describe User do
  let(:user) { User.new(name: ‘John’) }
  it "has a name" do
      expect(user.name).to eq(‘John’)
  end
end

But soon things get complicated, we add more and more models to our application that depend on each other. Tests reflect this as well, we have to create a lot of objects in our tests to test simple things.

1
2
3
4
5
6
7
8
9
10
11
12

describe User do
  let(:english) { Language.new(name: ‘English’) }
  let(:australia) { Location.new(name: ‘Australia’, language: ‘english’) }
  let(:melbourne) { Location.new(name: ‘Melbourne’, parent: australia) }
  let(:office) { Workspace.new(name: ‘Melbourne Office’, location: melbourne) }
  let(:user) { User.new(name: ‘John’, workspace: office) }
  
  it "has a language" do
      expect(user.default_language).to eq(english)
  end
  
end

The example above creates all the objects that are needed to test user.default_language. We need to know a lot about our application just to run a test. Soon our test become a burden to write and very slow to run.

Mocks, Stubs!

It is evident that we are just doing too much in our test, we should just be creating the object we care about and mock the rest. Let’s rewrite this using doubles and stubs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

describe User do
  let(:english) { double.as_null_object}
  let(:office) { double.as_null_object }
  let(:user) { User.new(name: ‘John’, workspace: office) }
  
  before do
      office(:language).and_return(:english)
  end
  
  it "has a language" do
      expect(user.default_language).to eq(english)
  end
  
end

This is faster and simpler, we are just creating the object under test (user) and doubles for the other objects. We don’t need know about all the relationships in our application, just knowing the interface we care about in the objects directly related is enough. In this case just knowing that office responds to language is all we need.

But there is of course a problem. What happens in office doesn’t respond to language anymore? Say that someone changes office.language to office.default_language. Our test will still pass! We have created an alterative universe in our test.

Integration test

Many experience developers will tell us that the solution to this conodrum is to have good integration test. That is partially true, integration tests are likely to fail when the interface between the objects is changed.

But guess what will happen? We will go and fix the integration test and then we will back to green. But wait, we forgot to fix the unit tests but everything passes! Unfortunatelly we cannot rely on due dilligence of people fixing all that should be fixed.

Now we are even in a worst situation, our tests are all green but our app is broken. So integration tests are not a reliable solution.

Your application:

Safe mocking / stubbing

We still want the benefits of lean, fast tests but without the dangers of alternative realities. So what is the solution?

I found that safe testing libraries are the best solution out there. This library will take care of checking that the methods you call actually exist in the mocked object. This frees us to still use doubles and stubs in our test without worring about the possibility of getting out of sync with the real application.

From all the libraries I have tried, (Bogus)[https://github.com/psyho/bogus] is the most complete one. A test using Bogus will look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

describe User do
  fake(:english) { Language}
  fake(:office) { Workspace }
  let(:user) { User.new(name: ‘John’, workspace: office) }
  
  before do
      stub(:office).language { english }
  end
  
  it "has a language" do
      expect(user.default_language).to eq(english)
  end
  
 end

Bogus will check that office.language is an actual method and that it takes the number of parameters we send. In this way we can have the benefits of stubbing and mocking without the drawbacks. I highly recommend that you try it in your project.

I learnt a new trick over the weekend using Angular, how to build a recursive tree of objects using directives. In this post I want to share how to do it.

Let’s say that you have some data that looks like this, it can be as deep as you want:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

   [
      {    name: 'Europe',
          children: [
              {    name: 'Italy',
                  children: [
                      {    name: 'Rome' },
                      {    name: 'Milan'    }
                  ]},
              {    name: 'Spain'}
          ]
      },
      {    name: 'South America',
          children: [
              {    name: 'Brasil'   },
              {    name: 'Peru' }
          ]
      }
  ];

And using this data you want to build a tree, e.g.:

Europe
    Italy
        Rome
        Milan
    Spain
South America
    Brasil
    Peru

So to build something like this you will need some kind of recursive code to loop over all the elements and their children.

Let’s start with the html:

1
2
3
4
5
6
7

<html ng-app='APP'>
  ...
  <div ng-controller="IndexCtrl">
  
  </div>
  ...
</html>

First we have a controller ‘IndexCtrl’ which looks like this:

1
2
3
4
5
6

var app = angular.module('APP', []);


app.controller('IndexCtrl', function ($scope) {
  $scope.locations = [ ..this is the array of locations shown above ..];
});

Here we have $scope.locations pointing to the array of locations we want to render in our tree.

Then we need a directive for rendering a collection, the html for the collection looks like this:

1
2
3

<div ng-controller="IndexCtrl">
  <collection collection='locations'></collection>
</div>

This directive takes a collection parameter which are the locations we want to render.

Our directive definition looks like this:

1
2
3
4
5
6
7
8
9
10

app.directive('collection', function () {
  return {
      restrict: "E",
      replace: true,
      scope: {
          collection: '='
      },
      template: "<ul><member ng-repeat='member in collection' member='member'></member></ul>"
  }
})

• restrict: ‘E’ tells angular that we want to apply this directive to any html tags matching collection.
• replace: true tells angular that we want to replace the tag with the content of specified template in the directive.
• scope: creates a new scope for the directive.
• collection: ‘=’ tells angular to use the collection attribute in the directive and create a variable in the directive scope with the same name, = means that it should be passed as an object.
• template: “…” is the new html that will be inserted instead of the original tag.

Notice the following code in the template:

1

<member ng-repeat='member in collection' member='member'></member>

This is another directive, used to render each member of the collection (we use the build-in ng-repeat for looping), in this directive we pass the current member as the member attribute.

The directive for member looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

app.directive('member', function ($compile) {
  return {
      restrict: "E",
      replace: true,
      scope: {
          member: '='
      },
      template: "<li></li>",
      link: function (scope, element, attrs) {
          if (angular.isArray(scope.member.children)) {
              element.append("<collection collection='member.children'></collection>");
              $compile(element.contents())(scope)
          }
      }
  }
})

This looks a lot like the collection directive, except for the link function. I will explain what is happening here, but before that, let me tell you about my first approach for trying to do this.

The first thing I tried is to simply add the collection directive inside the template:

1

template: "<li> <collection collection='member.children'></collection></li>"

But this doesn’t work, it throws angular into an endless loop, because it tries to render the collection directive regardless if the member has children or not.

So instead you need to add the collection directive manually only if there are children, thus the link function:

1
2
3
4
5
6
7
8
9

link: function (scope, element, attrs) {
  //check if this member has children
  if (angular.isArray(scope.member.children)) {
      // append the collection directive to this element
      element.append("<collection collection='member.children'></collection>");
      // we need to tell angular to render the directive
      $compile(element.contents())(scope);
  }
}

Note the line $compile(element.contents())(scope);. As the html is appended manually we need to tell angular to re-render the directive.

That is it, here is the complete example. Thanks.

Update 2013-12-31: Please read the comments, there are some good suggestions on how to do this better.

Recently I was trying to find out a way of sharing some business logic between the client and the server. We have a reactive UI where results get calculated as you change values. These are complex formulas we rather not write in both Ruby and JavaScript so we don’t have to maintain them in two places.

The easiest solution would have been to make ajax calls to the server with the parameters get the results. But we wanted a UI that reacts immediately so needed to have the code loaded in the browser.

So this a solution I come up with, in summary:

• Formulas are stored as plain JavaScript
• Ruby Models load and use those formulas using V8
• The formulas are served to the front end as partials

Here is a rundown of what I did step by step. I will use a simple interest formula in this example.

Storing the formulas

I needed the formulas to be accessible as partials so I added them in the view folder:

In app/views/formulas/_interest.js

1
2
3

function formula(principal, rate, years) {
  return principal * rate * years;
}

Using the formulas in my Ruby models

In order to run the JavaScript on the server you will need therubyracer gem, in Gemfile:

gem 'therubyracer'

In app/models/contract.rb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Contract

  def initialize(principal, rate, years)
      @principal, @rate, @years = principal, rate, years
  end

  def interest
      cxt = V8::Context.new
      source = Rails.root.join('app', 'views', 'formulas', '_interest.js')
      cxt.load(source)
      cxt.eval("formula(#{@principal}, #{@rate}, #{@years})")
  end

end

The JavaScript code is loaded inside the interest method and ran with the provided parameters. In this way the code is accessible as a plain ruby method and only needs to be tested in one place. In my test:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

require 'spec_helper'

describe "Contract" do

  let(:principal) { 100 }
  let(:rate) { 0.5 }
  let(:years) { 5 }
  let(:contract) { Contract.new(principal, rate, years) }

  it "returns the right interest" do
      expect(contract.interest).to eq(250)
  end
  
  ...
end

Loading the formulas in the front-end

I couldn’t find a way of injecting the JS code into the assets pipeline, so instead I just loaded in a partial that gets loaded in the application layout.

In app/views/layouts/application.html.erb:

<%= render 'formulas/index' %>

In app/views/formulas/_index.html.erb

1
2
3
4
5
6
7
8
9
10

<script>
  (function (APP) {
      "use strict";
      (function (formulas) {
          formulas.interest = <%= render 'formulas/interest.js' %>
          ...
      })(APP.formulas || (APP.formulas = {}));

  })(window.APP || (window.APP = {}));
</script>

This piece of JavaScript creates a global object APP if not found, then an object formulas inside APP and finally adds my interest formula to APP.formulas.interest.

Using the formulas in the front end

Once the formulas are loaded as shown above they can be used as:

1

var res = APP.formulas.interest(principal, rate, years);

So this is a way of sharing code between the back and the front end. If you how how could be improved or of a cleaner way altogether I would love to hear about it, maybe some DSL that can be used in both places.

Selecting a JavaScript MVC framework can be hard work. There are so many factors to consider and so many options out there that selecting a framework can be overwhelming. To have an idea of all the possible alternatives have a look at TodoMVC.

I have had the opportunity to use four of these frameworks: Angular, Backbone, CanJS and Ember. So I decided to create a comparison to help you decide which one to use. I will go through several factors that you might want to consider when choosing one.

To each factor I have assigned a score between 1 and 5. Where 1 is poor and 5 is great. I have tried to be impartial in my comparison, but of course my objectivity is heavily compromised as the scores are based mostly on my personal experience.

Features

There are really important features a framework should have to provide the necessary foundation to build useful applications. Does it do view bindings? two way bindings? filters? computed properties? dirty attributes? form validation? etc. This can be a very long list. Below is a comparison of what I consider the really important features in a MVC framework:

Observables: Objects that can be observed for changes.

Routing: Pushing changes to the browser url hash and listening for changes to act accordingly.

View bindings: Using observable objects in views, having the views automatically refresh when the observable object change.

Two way bindings: Having the view push changes to the observable object automatically, for example a form input.

Partial views: Views that include other views.

Filtered list views: Having views that display objects filtered by a certain criteria.

Update 2014-07-08: As of version 2.0 CanJS now supports two way bindings.

Scores

So based on these features my scores are:

It is important to note that Backbone can do most of this things with a lot of manual code or with the help of plug-ins. But I am only considering the available features in the core framework.

Flexibility

There are hundreds of awesome plug-ins and libraries out there that do specialised things. They usually do these things better than what comes bundle with a framework. So it important to be able to integrate these libraries with the chosen MVC framework.

Backbone is the most flexible framework as it is the one with the less conventions and opinions. You are required to make a lot of decisions when using Backbone.

CanJS is almost as flexible as Backbone as it allows you to easily integrate other libraries with minimum effort. With CanJS you can even use a totally different rendering engine if you want, I have used Rivets extensively with CanJS without any issues. Although I recommend using what comes with the framework.

Ember and Angular are still flexible frameworks to some degree but you will find that you could end up fighting the framework if you don’t like the way it does certain things. There are some things that you just need to buy into when using Ember or Angular.

Learning curve and documentation

Angular

Angular has a very high wow factor at the beginning. It can do some amazing things – like two-way bindings – without having to learn much. And it looks quite easy at first sight. But after you have learnt the very basics it is quite a steep learning curve from there. It is a complex framework with lots of peculiarities. Reading the documentation is not easy as there is a lot of Angular specific jargon and a serious lack of examples.

Backbone

The basic of Backbone are quite easy to learn. But soon you find that there are not enough opinions there to know how to best structure your code. You will need to watch or read a few tutorials to learn some best Backbone practices. Also you will find that you will probably need to learn another library on top of Backbone (e.g. Marionette or Thorax) to get things done. So I don’t consider Backbone the easier framework to learn.

CanJS

CanJS is in comparison the easiest to learn of the bunch. Just by reading the one page website (http://canjs.us/) you will know most of what you need to be productive. There is of course more to learn, but I only had the need to reach for help in rare occasions (tutorials, forum, irc).

Ember

Ember also has a steep learning curve like Angular, I believe that learning Ember is easier than Angular but it requires a highest learning investment at the beginning to get basic things done. Angular in contrast lets you do some amazing things without learning too much. Ember lacks this early wow factor.

Scores

Developer productivity

After you learn the framework well what really matters is how productive you are with. You know: conventions, magic, doing as much as possible quickly.

Angular

Once you know Angular well you be can very productive with it, no doubt about that. It just doesn’t get the highest score because I think that Ember has gone a step further in this category.

Backbone

Backbone requires you to write a lot of boilerplate code, which I think is totally unnecessary. This is in my opinion a direct threat against developer productivity.

CanJS

CanJS neither shines nor disappoints in this area. But due to the low learning curve you can be quite productive with it very early on.

Ember

Ember really shines here. Because it is full of strong conventions it does a lot of stuff automagically for you. All you need to do is learn and apply those conventions and Ember will to the right thing.

Scores

Community

How easy is to find help, tutorials and experts?

The Backbone community is huge, there is no doubt about that. You can find dozens of tutorials about Backbone, a very active community on StackOverflow and IRC.

The Angular and Ember communities are pretty big as well. Also lots of tutorial and activity in StackOverflow and IRC, but not as much as Backbone.

The CanJS community on the other hand is small in comparison, but fortunately is quite active and helpful. I haven’t found the smaller size of the CanJS community to be a liability.

Ecosystem

Is there an ecosystem of plug-ins and libraries?

Here again Backbone beats the others hands down. There are tons of plug-ins for it. The Angular ecosystem is getting quite interesting as well with things like Angular UI. I think that the Ember ecosystem is less developed but it should get better due to Ember’s popularity. CanJS has the smallest ecosystem if any.

Size

This might be an important consideration, specially if you are doing mobile development.

Size library alone (no dependecies, just min)

Backbone is the smallest and people often point to this fact. But this is not the end of the story.

Size with dependencies

At 80k Angular is the only library of the bunch that doesn’t require extra libraries to work.

However all the other need other libraries to work:

Backbone needs at least Underscore and Zepto. You can use the mini-templates in underscore for rendering views, but most of the time you will want to use a nicer template engine like Mustache. This is 61K.

CanJS needs at least Zepto. This is 57K.

Ember needs jQuery and Handlebars. This is 269K.

Scores

Performance

I don’t consider performance to be a critical factor on choosing a framework because they are all performant enough for most of the things they will be used for. But this of course depends on what you are doing with it. If you are building a game performance should be a big consideration.

I have seen and made many performance tests with these libraries e.g. this one. But I am not totally convinced on the reliability of these tests. It is really hard to be sure that the test is really testing the right things and in the right way.

However, from what I have seen and read CanJS seems to have the edge when it comes to performance, specially in rendering view bindings. On the other hand I believe that Angular is the less performant based on the fact that it does dirty checking of objects. This cannot possibly be as performant as the others. See this.

Scores

Maturity

Is this a mature framework, has it been proven in production, are there many website using it?

Backbone has a ton of websites built with it. Its code base hasn’t had major changes in the lasts two year which is a great thing from the maturity perspective.

Although Ember is not that new, it has had major changes along the way, just reaching a stable form in the last couple of months. So at this time I don’t consider it to be a mature framework.

Angular seems more stable and proven than Ember. But not as much as Backbone.

CanJS may seem like an unproven solution because you cannot find a ton of site built with it. But CanJS comes with a lot more backing than what you first perceive. CanJS is an extraction of JavaScriptMVC a library that has been around since 2008 and has lots of experience build in.

Memory leak safety

This is an important consideration if you are building single page apps that are intended to stay open for a long time. You don’t want your application to leak memory, this can be a real problem. Unfortunately this can happen quite easily, specially if you are creating listeners for DOM events yourself.

Angular, CanJS and Ember will deal with this effectively as long as you follow their best practices. Backbone on the other hand requires you to do this work manually in a teardown method.

Testability

How easy is to test you code? The keys to have great testable code are modularity (have small pieces that can be tested in isolation) and dependency injection (being able to change dependencies in your tests).

You can do this with any of the frameworks if you learn the right patterns, but it is not easy and it requires you to get out of your way to apply them.

Modularity and dependency injection are core features of Angular, it actively discourages you from doing things in any other way. This usually leads to code that is easier to test. Because of this I consider Angular to has an advantage in this area.

Update 2013-05-08: Updated testability to explain better the Angular approach.

Personal taste

This is probably one of the biggest factors when choosing a library.

• Do you like declarative html? –> Angular
• Do you like using a template engine? –> Backbone, Can and Ember
• Do you like an opinionated framework? –> Ember
• Do you want a framework that stick closely to the original SmallTalk MVC pattern? –> None here, maybe CanJS is the closest.
• Do you want to use what seems cool at the moment? –> Ember, Angular

There is no way to score this.

Tally

Well, putting all together this is my tally. Remember this is just my opinion, please let me know if you think I have scored a library really wrong.

If you put the same weight to every factor it is a tight competition, there are no clear winners or losers. So I guess it all comes down to personal taste or how much weight you apply to each particular factor.

A note about Backbone (Impartiality ends here)

I have tried to stay impartial during my post but I cannot finish it without sharing my current opinion about Backbone.

Backbone was a great library two years ago, but I am convinced that there are better things now. I believe that many people choose Backbone just because of its popularity, it is a vicious circle.

Backbone trumps ultimate flexibility over developer convenience. But I think that it has traded too much, as it seriously lacks features and developer productivity. Yes, there are lots of plug-ins to compensate for this, but then you will be learning Backbone and something else on top.

Backbone can also be very tempting because of its big community and the ecosystem, but this advantage will disappear as the other frameworks become more popular.

Because of this I strongly feel that you should think twice before choosing Backbone for your next project.

Update 2013-04-20: Added testability. Update 2013-04-18: Made it clear that the last section is just my opinion. Removed the inflammatory “It is time to move on” statement.

When I first started learning about JavaScript object model my reaction was of horror and disbelief. I was totally puzzled by its prototype nature as it was my first encounter with a prototype based language. I didn’t help that JavaScript has a unique take on prototypes as it adds the concept of function constructors. I bet that many of you have had similar experience.

But as I used JavaScript more I didn’t just learn to understand its object model but also started love parts of it. Thanks to JavaScript I have find out the elegance and flexibility of prototypes languages. I am now quite fond of prototype languages because they have a simpler and more flexible object model than class based languages.

Prototypes in Javascript

Most guides / tutorials start explaining JavaScript objects by going directly to ‘constructor functions’, I think this is a mistake, as they introduce a fairly complex concept early on making Javascript look difficult and confusing from the start. Let’s leave this for later. First let’s start with the basics of prototypes.

Prototype chains (aka prototype inheritance)

Every object in Javascript has a prototype. When a messages reaches an object, JavaScript will attempt to find a property in that object first, if it cannot find it then the message will be sent to the object’s prototype and so on. This works just like single parent inheritance in a class based language.

Prototype inheritance chains can go as long as you want. But in general it is not a good idea to make long chains as your code can get difficult to understand and maintain.

The __proto__ object

To understand prototype chains in JavaScript there is nothing as simple as the __proto__ property. Unfortunately __proto__ is not part of the standard interface of JavaScript, not at least until ES6. So you shouldn’t use it in production code. But anyway it makes explaining prototypes easy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// let's create an alien object
var alien = {
  kind: 'alien'
}

// and a person object
var person = {
  kind: 'person'
}

// and an object called 'zack'
var zack = {};

// assign alien as the prototype of zack
zack.__proto__ = alien

// zack is now linked to alien
// it 'inherits' the properties of alien
console.log(zack.kind); //=> ‘alien’

// assign person as the prototype of zack
zack.__proto__ = person

// and now zack is linked to person
console.log(zack.kind); //=> ‘person’

As you can see the __proto__ property is very straightforward to understand and use. Even if we shouldn’t use __proto__ in production code, I think that these examples give the best foundation to understand the JavaScript object model.

You can check that one object is the prototype of another by doing:

1
2

console.log(alien.isPrototypeOf(zack))
//=> true

Prototype lookups are dynamic

You can add properties to the prototype of an object at any time, the prototype chain lookup will find the new property as expected.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var person = {}

var zack = {}
zack.__proto__ = person

// zack doesn't respond to kind at this point
console.log(zack.kind); //=> undefined

// let's add kind to person
person.kind = 'person'

// now zack responds to kind
// because it finds 'kind' in person
console.log(zack.kind); //=> 'person'

New / updated properties are assigned to the object, not to the prototype

What happens if you update a property that already exists in the prototype? Let’s see:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var person = {
  kind: 'person'
}

var zack = {}
zack.__proto__ = person

zack.kind = 'zack'

console.log(zack.kind); //=> 'zack'
// zack now has a 'kind' property

console.log(person.kind); //=> 'person'
// person has not being modified

Note that the property ‘kind’ now exists in both person and zack.

Object.create

As explained before __proto__ is not a well supported way of assigning prototypes to objects. So the next simplest way is using Object.create(). This is available in ES5, but old browsers / engines can be shimmed using this es5-shim.

1
2
3
4
5
6
7
8

var person = {
  kind: 'person'
}

// creates a new object which prototype is person
var zack = Object.create(person);
  
console.log(zack.kind); // => ‘person’

You can pass an object to Object.create to add specific properties for the new object

1
2

var zack = Object.create(person, {age: {value:  13} });
console.log(zack.age); // => ‘13’

Yes, the object you need to pass is a bit convoluted, but that is the way it is. See the docs here.

Object.getPrototype

You can get the prototype of an object using Object.getPrototypeOf

1
2

var zack = Object.create(person);
Object.getPrototypeOf(zack); //=> person

There is no such thing as Object.setPrototype.

Constructor Functions

Constructor functions are the most used way in JavaScript to construct prototype chains. The popularity of constructor functions comes from the fact that this was the only original way for constructing types. It is also an important consideration the fact that many engines are highly optimized for constructor functions.

Unfortunately they can get confusing, they are in my opinion one of the main reasons why new comers find JavaScript puzzling, but they are a big part of the language and we need to understand them well.

Functions as constructors

In JavaScript you create an instance of a function like this:

1
2
3
4
5
6

function Foo(){}

var foo = new Foo();

//foo is now an instance of Foo
console.log(foo instanceof Foo ) //=> true

In essence functions when used with the keyword new behave like factories, meaning that they create new objects. The new object they create is linked to the function by its prototype, more on this later. So in JavaScript we call this an instance of the function.

‘this’ is assigned implicitly

When we use ‘new’, JavaScript injects an implicit reference to the new object being created in the form of the ‘this’ keyword. It also returns this reference implicitly at the end of the function.

When we do this:

1
2
3
4
5
6

function Foo() {
  this.kind = ‘foo’
}

var foo = new Foo(); 
foo.kind //=> ‘foo’

Behind the scenes it is like doing something like this:

1
2
3
4
5
6
7
8

function Foo() {
  var this = {}; // this is not valid, just for illustration
  this.__proto__ = Foo.prototype;
  
  this.kind = ‘foo’
  
  return this;
}

But keep in mind that the implicit ‘this’ is only assigned to a new object when using ‘new’. If you forget ‘new’ keyword then ‘this’ will be the global object. Of course forgetting new is a cause of multiple bugs, so don’t forget new.

One convention that I like is capitalizing the first letter of a function when it is intented to be used as a function constructor, so you now straightaway to you are missing the new keyword.

The ‘function prototype’

Every function in JavaScript has a special property called ‘prototype’.

1
2
3
4

function Foo(){
}

Foo.prototype

As confusing as it may sound, this ‘prototype’ property is not the real prototype (__proto__) of the function.

1

Foo.__proto__ === Foo.prototype //=> false

This of course generates a lot of confusion as people use the term ‘prototype’ to refer to different things. I think that a good clarification is to always refer to the special ‘prototype’ property of functions as ‘the function prototype’, never just ‘prototype’.

The ‘prototype’ property points to the object that will be asigned as the prototype of instances created with that function when using ‘new’. Confusing? This is easier to explain with an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function Person(name) {
  this.name = name;
}

// the function person has a prototype property
// we can add properties to this function prototype
Person.prototype.kind = ‘person’

// when we create a new object using new
var zack = new Person(‘Zack’);

// the prototype of the new object points to person.prototype
zack.__proto__ == Person.prototype //=> true

// in the new object we have access to properties defined in Person.prototype
zack.kind //=> person

That is mostly everything there is to know about the JavaScript object model. Understanding how __proto__ and function.prototype are related will give you countless hours of joy and satisfaction, or maybe not.

Mistakes, confusing? Let me know.