Composite Event Driven Architecture with backbone.js and Marionette

These are my notes from a presentation by Amy Palamountain "Unsuck Your Backbone"

Model View Controller/Presenter/Arse Bananna
- don't get too hung up, they're all an improvement

Framework - is opinionated and proscriptive, "here's how it should be done"

Library do one or two things really well, structure outside is not its concern

Backbone and Knockout are libraries, Angular, Meteor, Ember are frameworks. Below is each with star count it has on Github, a measure of popularity:
Backbone 15,292

Angular 12,677
Meteor 9,369
Ember 7,708
Knockout 4,050
Marionette, 3,486

Backbone keeps it small, focused and encapsulated. Its a set of building blocks. It does not give you a blueprint on how to organize.
But Backbone.js apps can become large and complicated soup too!

MV* are presentation patterns only. Doesn't tell us how to build a scaleable app.

To scale, build a Composite Event Driven Architecture.
Build smaller apps that are composable.
Round up Views and Models into "Modules". Modules may or may not include presentations.
Modules
- are small
- are decoupled
- "ask, don't take"
- don't pollute global scope
- should be able to be added and removed independently without breaking app
i.e. we can compose a complex app from modules

Use a centralized controller, like an air traffic control, all events and communication are Mediated by one source. e.g. Application object
This Application object is responsible for:
Startup
- bootstrap app
- load confi
- load asynch modules
- start Backbone History
Eventing
-  pub sub
Lifecyle (modules)
- when is it safe for a module to start and stop Placement of views
- where and when removed


Marionette (size 14k, double size backbone) is a set of extensions to Backbone that allows us to build in a composite and event driven way.
1. view helpers
ItemView - renders an item, normally model, could be collection
CollectionView - for each element in collection, use ItemView to render
Layout - manage nested child views, split a template into regions and can apply views to each region
Marionette does memory management in regions for dead views (nice)

2. composite event driven
2.1 Eventing (Pub Sub, Requests, Commands)
implemented as Backbone.wreqr, a module which Marionette depends on
Pub Sub
- add listeners and then trigger events later
- recommends at least a few Event Mediators
Requests
- request something, somethings is returned
Commands
- somebody do something for me, don't tell me about it, just do it

2.2 Application object
Startup, Eventing, Lifecycle, Placement of views
- Startup has certain events triggered so you can bootstrap your app
- Eventing; By default each Marionette Application object gets an event wreqr as part of it i.e. can add listeners and trigger events on the Application object
- Application decides when a  module starts
- Placement; you can define regions in the app e.g. navigation, content, sightSidebar, footer
   - you can tell "display this view in that region"

2.3 Modules
Modules hang off the Application object (which is a special module itself).
Put views and models code into a module (via fn callback)
e.g. ImageCatalog Module which responds to commands to add an Image to the Catalog OR return the catalog