An attempt to provide a higher level understanding of the Backbone JavaScript framework as well as MVC architecture more generally. Exploring how it uses modules (Models, Collections, and Views) to separate out responsibility and how triggers connect it all together.
We recently had an exercise introducing us to the JavaScript framework, Backbone. The goal was to jump into a partially built application and fill in missing functionality ourselves. While the idea behind Backbone is to add structure to the code of an application, navigating through one built using the framework turned out to be extremely challenging. After finally managing to wrap my head around it (I think…), I wanted to share some of the key points of understanding.
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.
Eureka Moment
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.
Triggers
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).
This key point became even clearer for me as we started moving into React, another JavaScript framework. I’m still getting familiar with it, but in React it seems like a lot of the complexity in Backbone (which comes from all the different, interconnected relationships) is abstracted away while the framework takes care of a lot for you in the background. In React, modules are more self-contained, with both states (i.e. triggers/listeners) and the visual representations (i.e. views) maintained within the same Class. Meanwhile, React equips you with helper properties and methods like render and set which take care of the triggering reactions for you. A good way to conceptualize it is that in Backbone the relationships can be thought of as graphs, whereas in React they are hierarchal like a tree. This makes the connections much easier to trace in React than Backbone, and so much simpler to untangle and as well.
Helpful Resources
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.
I found this article really helpful in starting to understand this new MVC way of thinking. In it, the author takes a very simple application, posting a message typed by the user on the page, written in normal JavaScript and step by step converts it into using a Backbone architecture by separating out its functionality into Models, Views, and Collections. In the end, the code went from 16 lines of JavaScript… to more than 40 using 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!
