Backbone is a Dirty Diaper

Backbone is no longer the hot new thing on the block, but many new and experienced developers alike are still grappling with creating a satisfying mental model for the framework that would (ideally) help us better understand what’s going on, at least from a high-level perspective. The fact that backbone doesn’t follow the typical MVC or even MVVM pattern makes it difficult to place into any logical category.

I wish to propose a solution to this problem by suggesting a simple comparison (allegory, maybe?) to abstract away the details of code and understand Backbone from a mile-high perspective.

Imagine we have a set of Backbone views on a page. As we likely already know, each view is tied to a specific DOM element, though not all DOM elements are represented by views. Assume that each of these views are a way for us to render information that exists on its model by appending it to the DOM. A collection is simply a group of these objects that are built from a single model. Collections can also have a view.

We'll ignore the innards of the views for now (template, render, tagName, etc.). For now, that’s all we need in order to draw a vivid comparison.

Think about a model. It is created with the Backbone.Model.extend({...}) method and probably contains a defaults property that holds some information about it. Now replace that model with an infant human child. No unique or identifying features, just the characteristics common to all babies. Basically the idea of a baby.

The model is just the template for a baby, not any baby in particular. When we actually... ahem... instantiate a baby, it will have unique properties to it (age, DOB, name, etc.) as well as some abilities (cry, eat, whatever else babies do). This translates to a Backbone View that contains all of the methods available to all babies, as well as some HTML, that we can liken to a diaper. A collection of babies is just that. Still with me? Good.

Some event that happens on a view we can liken to a baby soiling it’s diaper. What happens next?

When any baby notices it’s diaper has been soiled, it cries. This is similar to an event being ‘triggered’ on its model. This event is also triggered on the collection. When you have a group of babies, you know when one is crying. Mom, for our purposes, can be thought of as the overarching app model. The app model knows to expect these events, and knows how to deal with them, whether it will be making a change to the view, adding something to a collection, or deleting it entirely. Mom is the same (except she probably isn’t deleting babies). She hears a crying child, changes it’s diaper, and waits for the next event (being a mother does sound glamorous).

So, the comparison goes:
Human infant = model

Individual baby (with name, age, diaper) = view

Mom = app model

Backbone can listen for ‘change’ events on each model and perform an action for you every time that change occurs, then re-render those elements for you. Mom is a good listener and knows how to change dirty diapers into fresh ones. She also knows how to act when a baby is hungry or tired, she just needs the baby to cry to tell her it’s time to change it. Just like our app model needs some sort of event or interaction on the view to tell it how to react.

Granted, this comparison isn’t perfect, but I hope it helps you visualize the control flow of a Backbone application next time you’re drawing a blank.

Shoutout to Melinda Bernardo for inspiration for this post.