Emberjs vs Knockoutjs

Originally Published on BootstrapToday Blog

BootStrapToday is around for about 2 years now. Recently we have been working on making it faster. We have done many small changes and will continue to make improvements. We are also working on redesigning the user interface to make it simpler for the user and more maintainable for us.

Some background:

BootStrapToday uses django and postgresql on the backend. On the browser side, we have used jquery and a lot of custom javascript and ajax calls. All this custom javascript is slowly becoming difficult to maintain. Also making sure everything works on all major browsers is difficult. For example, today when a user uses ‘quick edit’ to edit a ticket and submits it, updating the status of tickets in the ticket list requires an ajax call to server to get updated list. This  increases load on server. Later this year we are also planning on creating a mobile app.

Hence we are  redesigning the UI and have some idea of how things will look like. We are also  looking around for a javascript framework that can help in making these ideas into reality. I started by looking around and got a useful comparison of various javascript MVC frameworks.  After studying for some more time, I decided to do a quick prototype of ticket list and ticket details+edit display using the Emberjs(SproutCore 2.0) and Knockoutjs frameworks. I am not an expert in Javascript. Hence it took me some time to create two prototypes. The code is probably not the ‘best examples’ of using Emberjs or Knockoutjs but it gave us an insight into what will work for us.

Specifically we were looking for following features.

• UI Bindings: Client side Template, declarative bindings to models and auto updating views.


• Works well with Django.


• Works with jquery and other existing components.


• Ajax.

EmberJs (SproutCore 2.0):

Ember is javascript MVC framework. As the Ember introduction says

Ember makes it easy to divide your application into models, views, and controllers, which improves testability, makes code more modular, and helps new developers on the project quickly understand how everything fits together. The days of callback spaghetti are over.

Ember also supplies built-in support for state management, so you'll have a way to describe how your application moves through various nested states (like signed-out, signed-in, viewing-post, and viewing-comment) out of the box.

First problem I faced with Ember is the ‘template syntax’. Ember uses Handlebars as template engine. At places Handlebar template syntax is similar to Django template syntax. So Django tries to parse this template and interpret it.  So the possible solutions were:

• Use a different template system than Dajngo’s default template system. This was not a viable option since it meant that we  throw away all existing templates and also  educate the team on different template syntax.


• Needed a way to tell Django ‘don’t interpret’ this part of the template. Unfortunately there is no good standard way to do this in Django. I ended up in using the ‘raw’ template tag described in ‘http://www.holovaty.com/writing/django-two-phased-rendering/’. However, this code is GPL licensed. We can use it for prototyping but we cannot include it in our product.

BootStrapToday uses slightly older version of jquery. It seems Ember requires jquery
1.71.6+  (Edit : Peter Wagenet has clarified that Emberjs works with jquery 1.6+ ).

Ember properties and computed properties worked well. Also, I implemented a computed property which when called, queried the necessary data from server using an ajax call. However, it means every time when a property value is queried, it will result in an ajax call. Obviously that’s not a very good idea. However, Ember has a nice touch that you can make a property ‘cacheable’. Once you marked a property as cacheable(), it stores the last returned value and reuses that instead of computing it again. That worked well for reducing the number of ajax calls.

Then I tried to implement Ticket edit functionality using the existing Django form. Currently Ember documentation is very limited on how to use various HTML input fields, and there is no information on using existing html forms with Ember properties. I could not figure out how to reuse the existing  Django forms. It means I had to re-implement the forms as Handlebars templates and input field ids etc. have to match with ids that Django expects. Other option was to write custom form fields which will generate the Handlebars template code rather than HTML generated by default Django fields.  This means a lot of work and not much benefit. This is one area where Knockoutjs declarative data-binding shines.

KnockoutJS

Knockout (KO)  is javascript MVVM framework.  KO Observables page has a small introduction to MVVM pattern. Key features of KO as described on the KO Introduction page are:

• Elegant dependency tracking - automatically updates the right parts of your UI whenever your data model changes.


• Declarative bindings - a simple and obvious way to connect parts of your UI to your data model. You can construct  complex dynamic UIs easily using arbitrarily nested binding contexts


• Trivially extensible - implement custom behaviours as new declarative bindings for easy reuse in just a few lines of code.

The big advantage that KO has over Ember is the documentation. The documentation and Live Examples are a GREAT way to learn and experiment with KO.

KO template syntax is different than Django templates. So using KO with Django templates is simple.

KO Observables is somewhat equivalent to Ember properties. However there are few key differences. In Ember, the dependencies of properties are defined by the developer. In KO Observables, dependencies among observables are automatically determined.  Now this is good and bad. The good part is that as a developer you don’t have to worry about explicitly determining and defining dependencies.

KO Computed Observables documentation says following about the dependency tracking.

It’s actually very simple and rather lovely. The tracking algorithm goes like this:

1. Whenever you declare a computed observable, KO immediately invokes its evaluator function to get its initial value.


2. While your evaluator function is running, KO keeps a log of any observables (or computed observables) that your evaluator reads the value of.


3. When your evaluator is finished, KO sets up subscriptions to each of the observables (or computed observables) that you’ve touched. The subscription callback is set to cause your evaluator to run again, looping the whole process back to step 1 (disposing of any old subscriptions that no longer apply).


4. KO notifies any subscribers about the new value of your computed observable.

The line in bold has a side effect.  Let us suppose that I want to load some property from server (like description of a ticket) when it is accessed first time. Now since KO invokes the evaluator function immediately, it means it will trigger an ajax query to the server even though user may not need the property. Since KO invokes evaluator function, to get the dependencies of Computed Observable, if there is some way to manually define the dependencies then this evaluator call is not required. I could not find a way to do this. Hence I have to do some tricks to load make necessary data from server when user needs it. Basically I load the data in some click handling functions.

Also I could not find anything equivalent to ‘cacheable’ in Ember.

At this point loading a ticket list from server and displaying the details when a ticket is selected from list was working using KO and Ember.

Then I started implementing ticket edit functionality and here KO has significant advantage over Ember for our needs.  Because KO uses declarative data binding, attaching KO observables to an existing Django form was trivial and I could reuse existing Ticket edit form.  For testing I used a simple function like the one given below to add ‘data-bind’ attribute to various form fields. Then I called the ‘form.as_table’ in template and the bindings worked like charm.

def add_databinding(form, fld_observable_map):
'''
add data binding attribute to all form fields.
'''
    for name, field in form.fields.items():
        if name in fld_observable_map:
            field.widget.attrs['data-bind'] = "value:%s" % fld_observable_map[name]

Both KO and Ember are useful and interesting frameworks (something you should keep an eye on). However, today KO satisfies our needs better than Ember.

Now we are working on a django app to simplify using KO with Django. I will keep you updated on any interesting things that happen along the way.

Updates: BootStrapToday new design is based on Knockoutjs. You can watch the video below to see how new design based on KO looks like.

You can also signup for Free to test drive new design by clicking below