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.
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.
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.