Day 17, Backbone is a monster

I knew Backbone is hard, but I didn’t know it is this hard. It was even worse because the sprint was designed to push you into the unknown. It is sink or swim mode, and my pair Gary and I were drowning.

My pair and I were having such a hard time that we were unable to reason about basic things even after working on it for an entire day. Luckily, it was senior review night and Zak the senior provided generous help. After drilling him on all kinds of basic questions, I finally felt like I knew what is going on.

Another light bulb went off at midnight about the lack of controller inside Backbone. CJ came by my room at midnight and asked me what I was working on. I briefly explained my situations and he said “*** event is kind of the controller ***”. I was shocked. What? I thought this was a MVC framework and I was  expecting another component of the system called controller that was to be introduced by Marcus tomorrow. Coming from a Django background, I thought I knew something about MVC (or MTV in Django). Boy, I was wrong.


– Special keywords in Backbone:

— collection / Collection / events

– Basic Backbone flow

model –event–> view –jQuery–> DOM

model <–function_call– view <–user_events– DOM

– Every view needs an instance of a model

Rules implied in Backbone:

— One view talks to one model

— One view talks to its direct children (at least, maybe indirect children too)

— One view can NOT talk to its parents or siblings

— One register listeners to its model

— Model does NOT know anything about the views. Model emits events, and doesn’t know anything about listeners.

Models vs Views

– Models

— graph like

— objects representing some data

— structure & no sequence

— objects have types and keys

— objects are normally not repeated

– Views

— tree like

— output to users

— structure & sequence

— objects normally don’t have types, nor keys

— objects/data tend to be repeated

— has styles

Shared vs non-shared properties (???not sure)

// the following one is shared
initialize: function(){

/* the line below is implied */

/* this.attributes = {} */

this.attributes.key1 = 'value1';

// not recommended due to the lack of event emission

// key1:value1 is shared among all instances of the class


// the following one is NOT shared
this.set('key1', 'value1')

Some conventions in Backbone:

// Return this.$el in SomeView.render()


return this.$el;


// so we can use this code in index.html

//Creation of a view

var carView = new CarView({model:car});

console.log(carView.$el); //special property, always there, always a jQuery obj

//Render of a view



this.$el.html('<div></div>'); //this maybe implied ?


//Creation of a model

var Car = Backbone.Model.extend({

initialize: function(params){

this.set('key1', params.key1);


// this is run at construction time, as expected

// params is normally a {} with key:value pairs

// example: var car = new Car({key1:'car_value1'})


– Mixin can be used to add trigger / on events to an obj. For example, flying() or evented()

– Event registration: Obj.on(‘event_name’, callback/listener/handler)