I've being using this pattern since day one with Backbone.js. If you want to avoid spaghetti code you need to have a central mediator that will take care of the communication between your modules.

It's also easier to debug if all your events business happens in one place.

I also had this exact problem. I posted this question on StackOverflow about it, and the accepted answer led me to the solution I use now, which is identical to the one described in the article:

http://stackoverflow.com/questions/9405148/how-can-i-bubble-...

...I always just do something along the lines of window.MyAppNamespace.EventProxy = _.extend({}, Backbone.Events);

The nice thing about this tactic is that it loosely couples interactions between your views. A coworker who also uses Backbone.js prefers passing references between your views to each other. Although this makes the code easier to read in some cases, since it's more obvious what the flow of control is, it tightly couples the components.

A central event emitter is common practice in client software. It is also known as the event aggregator pattern. A nice description by Martin Fowler[1]

[1] http://martinfowler.com/eaaDev/EventAggregator.html

Check out this post of an event aggregation implementation in Backbone:

http://devlicio.us/blogs/mike_nichols/archive/2011/08/14/bac...

NB: Use with caution

Some pitfalls:

- easy to create zombie objects

- easy to break sub-view re-usability

- gl hf if you have managed to end up with x-references

The Backbone documentation actually mentions this too (last sentence of the introductory paragraph here: http://documentcloud.github.com/backbone/#Events).

That's interesting...I can't believe I never noticed that.

I'm using a statechart library (Stativus[1]) in a similar capacity, but with... states.

[1] https://github.com/etgryphon/stativus