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
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.
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
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
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
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
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)
View Containers Which also manage memory
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
Layout A specialized item view which has multiple regions Great for a multi-view “widget”
Application Structure Separating coordination code from computation code
Application An object to hold initialization and bootstrapping logic This is the only place I allow knowledge of the full page to live
Module Like an Application, but specialized for a specific aspect of your code base An Application is made up of many Modules
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.
Application Level Communication
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.
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”)
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
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