Why We Still Use Backbone.js


It’s a very exciting time to be a front-end developer. It is the Renaissance age for JavaScript, and every day brings a new round of shiny new toys for developers to play with, each with a new set of paradigms that are good for stretching the mind in exciting new ways. As big fans of the old axiom, “the right tool for the right job,” we are constantly evaluating the newest libraries and tools. There are some very shiny new players on the block that have the JavaScript world super excited, e.g., Angular and React, to name a couple. So why are we not moving to a more modern front-end framework?

Part of the answer to that question is who we are and what we do. Enspire is a custom e-learning development shop focused on cutting-edge instructional design, high-end media development, and immersive simulation development. So right off the bat, we are approaching development differently than a lot of shops. We have no monolithic product that we work on day in and day out forever on end. Instead, we have to use a rip-and-burn style of development. In this day and age where a single person can build a SCORM-compliant e-learning course using only a stand-alone piece of software like Articulate, the pressures on a high-end vendor have multiplied. More for less has always been the soup-du-jour in our industry, and it is challenging to be committed to such a high level of excellence when everyone at the table is clamoring for discount rack prices. So efficacy, speed, and flexibility are really the only ways we get to bring our best ideas to life.

Back in the early days, Enspire was, like most e-learning developers, heavily invested in Flash. It is now the popular opinion that Flash is the scourge of the internet and should only be approached with a large dollop of scorn and mockery. In the early days of the browser wars, before everyone had access to a computer, much less a computer that could be carried in your pocket and more powerful than the moon lander, Flash was a godsend. In the days when JavaScript was but an infant, you couldn’t trust that any user would even have it enabled. Doing something that required what we now call a single-page application was unreliable at best and downright impossible in some cases. With Flash, you could easily add state into the stateless web, as well as soothe over some of the pain of supporting the vast differences in browser implementations of the time. It also empowered designers with no coding knowledge to take on complex layout and animation. I remember reading that one developer from Macromedia (the company that owned Flash before Adobe gobbled it up) said that users were regularly showing the Flash team that it could do way more than was even dreamed of by the developers themselves. We were constantly pushing the bounds of what we could squeeze out of Flash to make new and immersive experiences. Those were the good ol’ days, when we were so ahead of the curve that we had problems like, “We need more shelves for our awards, should we go ahead and buy two”? 

Around this time, we were starting to see the buzz about HTML5 and were talking about a refresh on a multiplayer simulation game that we had been running for years. It seemed like a pretty good HTML5 candidate, so we started researching which libraries and frameworks were available. There were the giants of the day: YUI, Prototype, and MooTools. We had used YUI and Prototype before, but we weren’t sold on them. A new thing, jQuery, was starting to make some waves, so we wanted to take a look at that. About that same time, I stumbled upon an article about a brand new library call Backbone.js. It was currently at version 0.3.0. It mirrored some of the design patterns of our current AS2 Flash framework around generics for models and separation of MVC concerns. After looking at some code examples and reading about Backbone’s philosophy, we knew this framework was what we had been looking for to redevelop our multiplayer simulation. So, we rolled the dice. We’re happy to say that the decision paid off, and the application is still being used in production today, although we did update it to Backbone 0.5 at some point.

As time went on, it became clear to us that Flash was going to be on the ropes sooner than later. Luckily for us, we’re a shop full of developers who are hungry for new things, so we were mostly ready for the rug to pulled out from under us. I say this mostly because the accelerated death of Flash and the rise of HTML5 did not happen organically. Apple, still mad about Adobe’s decision to focus more on PC performance a decade earlier, announced the birth of the iPhone, which also served to knock a few more props out from under the old-school e-learning development toolkit. To make matters worse, even though we were looking at incredible “experiments” in HTML5 every day, they were a long way from the large-scale single-page media-heavy tour de force that we were used to producing. We took a look around, and so many of the problems that we had solved in Flash over the years were now back on the drawing board. Things like how to keep audio and animation in sync with pause/play and rewind/fast forward functionality – a problem that there is still not a good answer for in some situations.

At least we weren’t caught as flat-footed as a lot of shops in the e-learning industry when our old, tattered security blanket was ripped away. We already had a good toe-hold on the cliffs of HTML5 development. It was then time to retool and get back to the business of blowing minds and pushing the bounds of the way people learn.

Something I read about Backbone in the early days was that it was not a framework, but instead, it was a library for building frameworks around. This is really what a shop that works on short timelines and often says, “If we can dream it, we can build it,” was needing – a way to respond to the never-ending stream of projects that could be radically different than everything that came before it. So we chose to build our framework Blaze around the core of Backbone. We looked at a couple of the other frameworks now popping up in the Backbone ecosystem, like Marionette and Layout Manager, but most of them did not really do much for our needs, and instead focused on handling complex nested views and aimed mainly at building traditional websites. What we needed was solutions around assessment, interactivity, simulation, complex branching narratives, internal legacy data formats, gamification, user tracking, and analytics. Another serious requirement was a lot of e-learning packages must run serverless and are not only expected to integrate seamlessly into a myriad different environments, but must also communicate through specifications that date back to the 1980s.

So we set about the porting of our Flash framework to JavaScript. We added Mustache for templating with a thin layer wrapping it, providing template loading and global helper functionality. We used Cocktail.js for mixins since we favor composition over inheritance. Of course we get Underscore.js since it is Backbone’s one hard dependency. It’s like a Bat Belt of functionality that I would be sad to have to give up. We made heavy use of Promises through Q.js to handle async operation and sequencing. Then we built the stuff needed for our business domain, like adaptors for LMS communication, Interactive and Assessment controllers and trackers, and our Conversation Engine, which is used for extremely complex soft skill simulations. In some places, like animation, we made the framework agnostic. This allows us to choose the best animation engine for the project’s requirements. Need one that supports IE7 or one that will be screaming fast in Chrome on a Windows 8 kiosk mode set-up for a game in your mobile learning trailer? No problem.

We would not advocate everyone should drop [insert fad of the week framework here] and build their own (although building a framework is great learning experience). Nor has our search for new technologies stopped (for instance, we have a couple of Meteor.js/react apps under way right now). However, if you develop in a niche like e-learning and look in your toolbox only to notice that your hammer is suspiciously shaped like a burrito that spews beans everywhere anytime you hit a nail with it, you might consider using Backbone as a tried and true place to start a framework that is more suited to your needs.