What is a code “Framework”?
The goal of coding frameworks in general is to add structure to a code base in order to improve readability and clarity (so that, for example, someone else, even future you, can more easily jump in and built on top of it). This is done by building out your code into modules, each with a clearly defined division of labor and with each module keeping to the Single Responsibility Principle as much as possible.
In Backbone, this is done using an MV* Architecture, which stands for Model View Architecture (the * is in place for a ‘C’ for “Controller” but these don’t really play a role in Backbone). Models and Views are the two main categories of modules in the framework, with each category responsible for a specific type of task. Models are Classes used to manage data and their state at any given time, whereas Views are the data’s visual representations. There’s also a third type of module in Backbone called a Collection, which are basically groupings of a specific Model type (you can think of them as an array of Model objects).
My goal in writing this was to convey the higher level concepts of Backbone that helped me to understand it better, so I won’t be going into the specifics of the code behind these modules (extra resources for that at the end of the post). To understand how these work, you can think of a To Do list. Imagine you have a Model for tasks. Each new task gets built, using the task model. This task model allows you to store the task’s state (complete/incomplete) since each task generated should have this capability. Your list of tasks would be a Collection of task models, and, finally, you would have a view that displays the tasks to the user, most notably reflecting its state (i.e. checked if complete).
So in this simple example, this structure seems great right? Nice separation of responsibilities, easy to see which block of code performs which operation. The problem that I ran into though is that as you build in more complexities, you have more and more interweaving modules. In the app we had to build functionality into, there ended up being around a dozen different modules of all three types and all interconnected with each other. This was all for a simple app with very simple functionality and just a couple of opportunities for user interaction. Mapping these relationships was extremely tedious. In the end, trying to figure out how everything interacted with everything else was an exercise in putting my brain through a blender.
Diagramming out how each module is connected is definitely a good place to start when trying to wrap your head around this architecture. I’d caution against spending too much time on this though. I went through a good two hours mapping out the code base I was working on and at the bottom of the rabbit hole the only thing I really felt I’d learned was how deep into the hole I’d gone… and that it was still mostly dark down there.
My major epiphany came when I realized that “triggers”, or events, are the main currency of the Backbone framework (hat tip to my classmate Rahim for that phrasing). Basically what this means is that the thing that ties the whole structure together is a network of different event triggers and listeners. When an event on one module (almost always a Model) is triggered, it sets off a chain reaction of events, passing that state change across the different related modules that are listening for the initial trigger to be set off (these listeners could be on Views, Collections, or even other Models). Building on top of this, the best way to think of Models is as a sort of control panel that houses various triggers which themselves manipulate whatever is “wired” to them. So when you’re building up Models for your application or trying to navigate around someone else’s code base, understanding where the triggers are and what other models are listening to them is a very good place to start. Try and centralize these triggers as much as possible (remember, division of labor).
While the official Backbone documentation is very useful and thorough, I wouldn’t rely on it too much while you’re still trying to understand the framework conceptually. Use it as an aid when you’re looking for something specific rather than as a tutorial on how to build with Backbone.
Obviously I’m still trying to wrap my head around all of this myself so there’s a very good chance that I mischaracterized something or was totally off-base altogether. So definitely caveat emptor as you read this. If there’s something I missed, something I got wrong, something you’d like to add to, or something you’d like to ask about, please feel free to share in the comments!