As front-end application development matures, more and more people find themselves reaching for a special-purpose library to structure their codebase. The web abounds with choices – look no further than TodoMVC.com for proof of that. While pluralism serves the open source ecosystem well, any given application should only commit to a single framework. During Roost, we build a web application from the ground up. This forced us to make the same (sometimes very personal) decision while designing the content. We chose Backbone.js; in this post, I’d like to discuss why.
It would be easy to dismiss “popularity” as a lazy stand-in for “quality”. While we do think that some consideration ought to be given to the populist selection, we value library prestige primarily because of what it implies about related attributes. The most widely-used libraries will generally have the best developer support structure – more “mindshare” means more example projects, more blog posts, and more people idling in chat rooms. Libraries that have been vetted by a larger audience are also most likely to account for edge cases that inevitably crop up during real-world application development.
This priority tended to disqualify many of the libraries that focus on specific aspects of the Model-View-Controller paradigm. While different members of the team have had success with tools like React, Ractive, router.js, and ampersand-model, none of them provide a complete application structuring solution out-of-the-box. In combining them with other tools, we would inevitably create a permutation that would never rival the popularity of the “stock” options. A lot goes in to gluing these pieces together, and this knowledge doesn’t necessarily generalize to other frameworks. (That said, you should feel free to ask us about any of those; send us a tweet or talk to us during Roost!)
Of course, popularity isn’t everything. The potential for a better solution exists in every project, no matter how obscure. It’s important for each of us (as individuals and as members of an industry) to constantly explore new options and see where novel approaches lead. In the context of a “best practices” course like Roost, though, we’re inclined to play it safe. At the end of the day, we want you to walk away with experience in stable and well-known tooling.
This is why we’re comfortable using “popularity” as an initial criteria for our choice of framework.
We’re all familiar with the concept of popularity (some of us painfully so… thanks for nothing, high school). It’s one thing to recognize a property and quite another to quantify it. If we were going to cite “popularity” as one of our deciding factors, we wanted to be up-front about how we judged it. There’s no canonical source for this, so we cast a wide net with a number of different metrics:
We would have loved to also use download statistics from Bower, but that data is not publicly available.
We retrieved this data for a slew of the projects listed on TodoMVC.com:
And here’s what we found:
This chart is full of interesting detail, but the most salient points for our purposes here are:
Most importantly: Ember.js, AngularJS, and Backbone.js consistently rank highest. This corroborates the anecdotal evidence we’ve gained through running local meetups, attending technical conferences, and providing professional consulting services.
If popularity were our sole criteria, then we would have selected AngularJS and called it a day. But we have to face an unfortunate reality: we only have 2 short days to spend with you.
The catchy marketing tagline for Roost is, “Wake up your workflow.” Beyond just sounding cool, this slogan reflects our intention to demonstrate a holistic approach to web development. Application architecture is definitely one component of this, but it is not the only component. Take a look at the schedule, and you’ll find topics ranging from theory to modularization, testing, and optimization. We knew that no matter how we structured the code, we’d want to do it in a way that people could understand quickly. Speed and quality, however, are often at odds. It would be all too easy to design a rushed experience writing overly-simplistic code that would fall apart in the real world. We felt confident making this a priority because we had already used “popularity” as a filter on our options.
AngularJS and Ember.js are both excellent tools. At Bocoup, we rely on them in consulting projects, and we offer public classes dedicated to each. They share an ambitious goal of addressing a wide array of the many complexities of modern web application development. No matter how flawless the execution, achieving this goal requires a lot of primitives, expansive APIs, and a whole bunch of convention.
Backbone.js, on the other hand, takes a far more conservative approach. It defines a small set of classes that can be understood in isolation. The source code is brief enough to be read in a sitting (don’t worry: we won’t do this during Roost). This makes it a great choice as the infrastructure for a packed course schedule: we can quickly cover a significant portion of the framework and immediately begin building on that knowledge. Because the primitives are relatively small abstractions around model, view, and controller, the concepts learned while building with them are more general and thus more applicable to other frameworks.
To be honest, even Backbone.js is not perfect for Roost. The flip side to its “conservative approach” is that, for many developers, the framework feels incomplete. Routing is not quite as seamless as, say, Ember.js, and view management takes more effort than (for example) AngularJS.
Backbone.js is highly extensible, and during Roost, we will define a couple of simple view extensions to aid with higher-order layout concerns. We wish we could avoid introducing custom abstractions like these, but we also recognize it as an consequence of our criteria on learning curve.
The instructors’ personal experience also helps us augment these shortcomings. Two of the more widely-used open source plugins for view management are Marionette.js and Backbone.LayoutManager. The Roost instructor team includes core contributors to both libraries (James and myself, respectively). We’ll be available before, during, and after Roost to discuss the various concerns that arise in Backbone.js view management. You can also watch this space for a post from James discussing this specific topic in detail!
We knew we could never find the perfect solution for all the Roost attendees – your needs are just too diverse! Instead, we strove to select a framework that would facilitate a realistic development demonstration and that would be approachable in a compressed time frame. Even though these considerations come from our unique perspective as education event organizers, we think they also have a place in traditional development settings. We hope this post has warmed you up to using Backbone.js during Roost and got you thinking about how to choose a framework in your own applications.
ROOST is presented by
