What you seem to be describing here is something I think you later formalized as the Marionette.Controller object. I’m starting to understand the role of controllers as ‘arbiters’, ‘mediators’ or even ‘puppeteers’ (bad pun), but I get confused in how multiple controllers interact and how they interact with layouts. An example is better. Let’s say I have an app with a layout and regions of: header, main, nav and footer that are managed by a controller. I have a router holding that controller to respond to URL navigation, and the controller holds a reference to the layout and handles calling ‘show’ for the various regions. The controller can also respond to events that may be raised and respond to them by calling show, etc. as opposed to navigation via the URL. All is good here and I think this is what you advocate.

Now what happens when my header is also complex and has 3 regions of it’s own? It doesn’t really message via the URL, so a router is inappropriate, but something still needs to call ‘show’ on the header regions right? It’s also inappropriate that the constituent views of the header would hold a reference to the overall layout and call show themselves. I think I need some higher level construct to coordinate the calling of show in that header, but the only controller I have is currently handling the overall app layout, not the header layout. Should that controller handle both? Do I need another controller that responds to events raised by the header views and calls show on the header layout to change them? What am I missing here?

The general idea is that the step definition and navigation has to be separated from the step implementation. It’s everything I talked about here, taken one step further in the abstraction.

http://lostechies.com/derickbailey/2012/05/15/workflow-in-backbone-apps-triggering-view-events-from-dom-events/

For example, I was doing a screen scraping proof of concept and what I *could* have done was do a deeply nested monster that went through about 4 HTTP requests and processed the results, but I didn’t, I created separate handlers for each step of the process and just separated them out so I could reduce redundant code and add error handling in the process. It was a simple proof but just by doing it in Node forced me to restructure how I did it.

And yeah, the asynchronous bit with the callbacks kind of drives me nuts some times. There’s a handful of things that can be done to reduce the nesting of callbacks, but sometimes that ends up reducing the readability and understandability of the code, for the sake of keeping it “clean”. It’s hard to find those balances.