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
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
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
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
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)
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”
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.
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
Backbone was the first framework designed to help structure large scale javascriptOther frameworks have come since which are MUCH more sophisticated and specializedBy giving no guidance, it is easy to do backbone “wrong”. Because of that, many see it as obsolete.Every project out there has strengths and weaknesses, and should be evaluated objectively and with as little bias as possible.The strength of backbone is in its simplicity and flexibility. Despite what is said, nothing else covers those two points quite as well
you can dig into any part of marionette and understand it in a few minutes (this is not to be underestimated!)
