observer pattern interesting use cases

gistfile1.js

/*

It's interesting to think about event/observer libraries for the first time after years of using
the same library, making messes, and trying to figure out how best to build reasonably large
browser apps. I realize that I want an event library that eases writing MVC applications in JavaScript.

*/

/*

An example of the kind of code and mess that might appear in an view class.

*/
APP.BoxView = function(model, controller) {
    this.model = model || new BoxModel();
    this.controller = controller || new BoxController();
    this.rootEl = document.createElement('div');

    // subscribe to DOM node(s) using listener functions and specifying thisObj
    LIB.on(this.rootEl, 'click', this.handleClick, this);
    // subscribe to model(s) using listener functions and specifying thisObj
    this.model.subscribe('change', this.handleModelChange, this);
};

APP.BoxView.prototype.handleClick = function() {
    // might subscribe/unsubscribe to more DOM nodes or models here
};

APP.BoxView.prototype.handleModelChange = function() {
    // might subscribe/unsubscribe to more DOM nodes or models here
};

APP.BoxView.prototype.destroy = function() {

    // Need to know exactly what to unsubscribe from to clean up properly.
    // This is error prone and can result in zombie views that
    // cannot be garbage collected.

    // unsubscribe from DOM node(s)
    LIB.off(this.rootEl, 'click', this.handleClick, this);

    // unsubscribe from model(s)
    this.model.unsubscribe('change', this.handleModelChange, this);
};


/*

What I'd rather write to make cleanup easier, more maintainable and less error prone.

*/
APP.BoxView = function(model, controller) {
    this.model = model || new APP.BoxModel();
    this.controller = controller || new APP.BoxController();
    this.rootEl = document.createElement('div');

    // subscribe to DOM node(s) and model objects or anything else
    // implementing the EventTarget interface using
    // listener objects and specifying method name using 
    // the same subscription interface.
    evento.addEventListener(this.rootEl, 'click', this, 'handleClick');
    evento.addEventListener(this.model, 'change', this, 'handleModelChange');
};

APP.BoxView.prototype.handleClick = function() {
    // might subscribe/unsubscribe to more DOM nodes or models here
};

APP.BoxView.prototype.handleModelChange = function() {
    // might subscribe/unsubscribe to more DOM nodes or models here
};

APP.BoxView.prototype.destroy = function() {

    // I don't need to remember anything. Purge all subscriptions
    // to DOM nodes, model objects, or anything else implementing
    // the EventTarget interface in one fell swoop.
    //
    evento.purgeEventListeners(this); // (Bad library function name. Suggestions?)
};

I like the optional instantiation of the model and controller (guessing this is for when the view somehow arrives first on the page). Don't really get why such strong separation of model, view and controller occurs, I didn't find it works that great on the client side.
I could go on, but instead I'd offer this idea. IMO the patterns for client-side development are still in the making. Maybe all authors who would like to contribute should create a similar looking to-do apps and publish the code for scrutiny. Discussion should involve ease of development (so also size of the codebase), memory usage and speed.

I've found that MVC makes large browsers side apps possible without loosing my mind. Small apps not need it.

I believe Addy Osmani has the to-do app repository you are describing. https://github.com/addyosmani/todomvc