Part one: the 30,000 ft view
The following is an extremely simplified and slightly
snarky synopsis of the popular Backbone JavaScript “framework.” I hope to give a high level view of:
- What Backbone.js actually is
- What is in it
- Where to go from here
What is Backbone.js
Backbone is often referred to as a JavaScript "framework" but it is not a framework like the other 3
leading frameworks[1] are in that it will not tell you exactly how to use it. It is officially a library but that might imply it is as vast as one of the libraries it is built on, Jquery. So I contend, it is really a toolkit consisting of a handful of powerful classes that might serve as the brains of your of the monster you want to build while also facilitating a pub-sub system to serve as the joyous nerve center of said monster. In fact, I am pretty sure that is why it was called “backbone.”
That and, if you plan to only use this "framework" and not invent any of your own conventions to properly design your own system, then your evolving beast will likely become a weak and vulnerable beast waiting to be eaten by the evils of long term maintenance.
That and, if you plan to only use this "framework" and not invent any of your own conventions to properly design your own system, then your evolving beast will likely become a weak and vulnerable beast waiting to be eaten by the evils of long term maintenance.
So farcical analogies aside, what exactly is backbone.js?
Backbone is a JavaScript toolkit that facilitates a type of MVC(kinda) . .
& R . . with an A&E .. architecture.
By that, I mean that Backbone provides the base classes you might use to follow the well-known MVC (Model View Controller) architecture . . . except it does not officially have a controller. Much of those official roles are often covered in the View classes. But it does have a Router that serves some of the official Controller functions, thus it is actually an example
of the trendy MV* (a.k.a. M-V-Star) architecture. However,
many who use backbone often feel the need to implement their own Application
level object(s) and we cannot forget the high speed bus of backbone to organize its pub-sub methodologies, the Event class. So Backbone.js a little more than a way
to facilitate MV*.
Therefore, I am dubbing backbone an MV*ea (or M-V-Starry) JavaScript Toolkit.
Therefore, I am dubbing backbone an MV*ea (or M-V-Starry) JavaScript Toolkit.
I realize you are now tremendously impressed with my ability
to create new terminology, but I dare you to unlearn that mnemonic. I dare you!
What is in it
The “Model” of the MV* software architecture pattern within Backbone is made up of model objects and
collection objects. Instances of the model
are largely dumb objects that might manage some of your most basic ajax calls
and they also initiate themselves in a clever manner. But they really just hold data. The collection objects are made up of a list
of the same model objects instantiated from the same class. They are also
just a tad bit shrewder than models and are a more likely location to house code that retrieves
large amounts of data from the server through the “fetch” or “sync” calls. This is also usually the best place to abstract any browser side filtering of said data. As these classes often reflect your data structure on the back-end, they are easily organized and often well contained. However, in contrast, the View classes are usually a complete mess.
The View classes, of course, manage all the logic of
displaying the UI ideally through the use of templates. As Backbone is built on Underscore (which is built on JQuery) there are a couple standard templating systems
easily available. However, the View
objects also must manage the events originating from the user and dynamic updates
to these templates. In plain Backbone (IE: not using a framework like Marionette), some Views often have to manage other sub-Views. This can get very
confusing and lead to a lot of repeated “boiler-plate” code. So to sum up, View classes do a whole lot and
it is quite easy to make a complete mess out of said classes.
Fortunately Routers are quite simple. They map a URL, including any parameters that
might be involved, to one specific function often called an action. These actions often involve creating Models and/or Collections plus initiating the server
communications needed to be sure these pieces of data are valid. These objects are then passed to new View instances. So in most cases, the routers are the masters
of instantiation.
Please note that how you organize
the Routers is really up to you. You could have one massive router for the whole system or you could have one router for every major server
interaction in your system or every step in your workflow. However, it often makes a lot of sense to organize your actions into different routers analogously to how you organize your workflow. Life is just so much simpler when you know where everything
is.
Lastly, Backbone provides a
simple class to handle messaging (or pub-sub) within your system based on the Events class. As long as one corner of the system is “listening”
for the same message that another corner “triggers,” then you can manage responses
to all sorts of actions at any given time. This is
especially useful when managing asynchronous events such as responses from the
server or interactions from the user.
Please note Events are an example of a “use at your own risk”
type of tool. For instance, it is very easy to create
two contradictory responses to the same message or to initiate a response to an
action long after the context is appropriate but we will save that discussion for
some sort of “pitfalls” posting later.
My only suggestion is to have some guidelines set for your application's
use of events or Spaghetti may come to bite you.
Where to Go from Here
So despite the fact that this post is rather short, this really does sum up all the major components of Backbone.js. Obviously there will be many lessons to be
learned from your first major project, which is why I hope to post a list of “pitfalls”
to avoid at some point. I should also admit that much of my time as a Backbone developer has been whilst under the protection
of Derick Bailey’s Marionnette version of Backbone. The
many reasons that this more structured form of Backbone is completely bad ass
will also be saved for another post, but it’s fair to say that those that are using backbone
the old fashioned way will have a different perspective than myself. In fact, I would appreciate any comments on
my ramblings in the interest of knowledge sharing.
But most importantly, if you are not going to use someone else's framework, I strongly suggest you come up with at least some standards for how you are going to solve repeated problems. If you don't know what problems I am referring to, please rethink your decision to not use a backbone framework.
But most importantly, if you are not going to use someone else's framework, I strongly suggest you come up with at least some standards for how you are going to solve repeated problems. If you don't know what problems I am referring to, please rethink your decision to not use a backbone framework.
This author would like to thank his Cousin John Cardoza
(AKA the Nevada Traveler) for teaching him to be snarky whilst writing on
obscure topics. Rewqls.
[1]Conversations in Silicon Valley generally give BackBone, Ember, Knockout and
Angular credit for the top four spots in the charts. If you disagree, pls comment below.
