This document provides an overview of Marionette.js, a library for Backbone.js applications that helps address common patterns and problems when building larger scale single page applications. It introduces Marionette primitives like views, view containers, and an application structure that separates coordination logic from computation logic. Specific components covered include item views, collection views, composite views, regions, layouts, the application object, modules, controllers, and different patterns for application level communication like events, commands, and request/response.

1. Marionette.js
Make your Backbone applications dance!

2. Who am I
 Senior front end dev at Nulogy (we are hiring!)
 Email - matt@mattbriggs.net
 Tweeter - @googleninja
 Coding – http://github.com/mbriggs
 Slides – http://slideshare.net/matt-briggs
 Infrequently updated blog – http://mattbriggs.net

3. Evaluating Frameworks
Without Bias
 The power of backbone is its flexibility and simplicity
 It is incredibly easy to end up in a bad place
 If simplicity and flexibility are priorities, Backbone
should be considered
 All JS frameworks (like anything else in software)
have both strengths and weaknesses
 They are all great choices for very different reasons
 Choose the right tool for the job

4. Why We Went Backbone
 For Nulogy, we deal with huge amounts of
complicated business logic. Being able to evolve
architecture without framework constraints is of
very high value.

5. Marionette
 Takes the ideas of backbone a few steps further
 Still very simple
 Gives you primitives for building larger scale
applications
 Introduces some conventions to allow the
removal of boilerplate
 Introduces some ideas around building larger
applications

6. Marionette
Primitives

7. Marionette View Magic
 Takes care of rendering!
 Takes care of template management
 Provides UI object
 Provides .close()
 Extensibility points to allow customization of any
piece of this

8. Automatic Render

9. UI Object

10. Marionette.ItemView
 A view which is rendered based on model data
 “model” is your model
 “template” is a way to reference your template
 No render required!
 modelEvents – bind to view methods when
events fire on model

11. Model Events

12. Marionette.CollectionView
 View which renders based on a Collection
 Will automatically rerender on
add/remove/reset/etc
 Provide an itemView, which will get instantiated
automatically, and given a model

13. CollectionViews

14. Marionette.CompositeView
 Combination of an ItemView and a
CollctionView (has both a model and a
collection)
 Great for master/detail
 Useful for when a collection view is not enough
(like when rendering a table)

15. View Containers
Which also manage memory

16. Region
 Specialized view that holds other views
 Takes a view instance, calls render on it, and
adds it to the DOM
 The “bridge” between the DOM and the land of
backbone

17. Layout
 A specialized item view which has multiple
regions
 Great for a multi-view “widget”

18. Application
Structure
Separating coordination code from
computation code

19. Application
 An object to hold initialization and bootstrapping
logic
 This is the only place I allow knowledge of the full
page to live

20. Module
 Like an Application, but specialized for a specific
aspect of your code base
 An Application is made up of many Modules

21. Controller
 Mediate complex interaction between
components
 Useful when you start having a fair amount of
coordination logic building up somewhere –
break it out into a controller!
 Do not think about it in the MVC sense of the
word, more as a Use Case Controller.

22. Application
Level
Communication

23. ZOMG EVENTS!!
 In my experience, this is the most controversial
part of marionette
 Do not go down this road unless you are
reasonably sure it is the right one to go down.
Abuse of eventing will lead to unreadable code.
 Application level events are very close to global
function calls, keep that in mind.
 The different types of events are there to provide
additional semantic meaning to what kind of an
event It actually is.

24. EventAggregator
 Basically the same thing as EventEmitter in node
 You can trigger events
 You can bind to events
 Use these for when you just want to notify the
world of something happening, and multiple
parts of the application may want to respond (ie:
“user:logged-in”)

25. Commands
 A command is something which could be
triggered from multiple parts of the application,
but handled in a single place.
 Example: You can save by
 cmd-s
 Clicking a toolbar button
 Choosing File => Save from the menubar

26. Request/Response
 For when you want to provide some “Application
Level” data (for example, the current state of the
shopping cart)
 Great for “global state” without having to pass
around a mess of objects all over the place
 Easy to abuse – a method call against a
concrete object will always be more clear, and
once something is globally available, it is hard to
predict the impact of it changing

27. Let’s Look at
some code!