2. Problems.
• Managing UI interactions gets complex very
quickly
• UI interactions have a way of coupling
everything together
• Having a page not reload means significant
parts of it can change many times, and
everything else still needs to work.
3. Solution (sound architecture).
• "The key is to acknowledge from the start that you have no idea
how this will grow. When you accept that you don't know
everything, you begin to design the system defensively. You
identify the key areas that may change, which often is very easy
when you put a little bit of time into it. For instance, you should
expect that any part of the app that communicates with another
system will likely change, so you need to abstract that away."
-Nicholas Zakas, author 'High-performance JavaScript websites'
• "The more tied components are to each other, the less reusable
they will be, and the more difficult it becomes to make changes
to one without accidentally affecting another"
- Rebecca Murphey, author of jQuery Fundamentals.
4. "The secret to building large apps is
never build large apps. Break your
applications into small pieces. Then,
assemble those testable, bite-sized
pieces into your big application"
- Justin Meyer, author JavaScriptMVC
5. Marionette.Application
• Application objects are all about managing
environment by providing ways to start, stop,
and provide functionality
• Keeping applications isolated is key
• An application can have many sub applications
• There is no distinction between an
“application” and an object
6. Mediator Pattern
• As soon as one class calls methods on another
class, you introduce coupling. This is (usually)
fine at the class level.
• Modules are a higher level then classes, this
type of coupling has higher cost for them.
• Instead of direct interaction, a mediator
provides a single thing everyone knows about,
and its responsibility is to manage the messages
between them
8. The three communication
mechanisms in Marionette
• Commands Provide functionality to the
application
• Request/Response Ask for some type of
value
• Event Let the application know that
something happened
9. Commands
• Useful when you want to provide functionality
that will be handled at a single point, but could
be triggered anywhere.
10. Request / Response
• Useful when you want to request some kind of
information from another part of the
application
11. Events
• Useful when you want to broadcast that
something happened, and it could be
something that many other modules are
interested in.
13. The Application
• Primary responsibility is to start and stop sub
applications.
• Mediates cross sub-application communication
(if necessary)
• Often responsible for managing views that
trigger major shifts in what sub applications in
play.
• Often provides a super high level layout
manager
14. Sub Application
• Often correlates to a “screen”
• Responsible for doing what is required for
screen changes
• Mediates module communication
• Responsible for managing layout, and pushes
regions down to modules for them to use for
their views
15. Module
• Provide a high level piece of functionality (like
“The Sidebar”)
• Usually visual, but doesn’t have to be
• “End of the road”, this is what manages the
objects that actually provide functionality
16. Good Ideas
• Don’t bind modules commands/responses
directly to their implementations, have a
controller in between them
• The previous breakdown is not set in stone,
the hierarchy should change based on the
requirements of the system
• Since modules are composable, a good
approach is to start with one, and split it apart
as more functionality are requirements develop
17. Things to keep in mind
• Eventing provides a high level of decoupling,
with a cost of making code harder to follow.
• Decoupling at a low level will usually result in
as bad a mess as too much coupling at a high
level
• OO is all about messages passing between
networks of objects. All we are doing is
adapting what we do in the small to make it
appropriate for large scale design.
18. Further Reading
• Enterprise Integration Patterns - the “bible” of
large scale design http://www.eaipatterns.com/
• Patterns for Large Scale Javascript Application
Archetecture by Addy Osmani - http://
addyosmani.com/largescalejavascript/
• BBCloneMail - Marionette sample application
https://github.com/derickbailey/bbclonemail
