Backbone.js Essentials

Created in 2010 by Jeremy Ashkenas, Backbone is a part of an entirely new breed of JavaScript libraries. Depending on who you ask, this type of library can be referred to as a rich application framework, a single page library, a thick client library, or just a JavaScript framework. Whatever you choose to call them, Backbone and its related libraries, such as Angular, Ember, and CanJS, provide tools that can be used to build websites that are so powerful that they go beyond being mere sites and become full-fledged web applications.

Backbone is made up of the following five major tools:

While conceptually very simple, together these components allow you to create websites with a level of sophistication and robustness previously unseen on the World Wide Web (WWW).

The question of why you will want to choose Backbone for your project really has two parts. First, there's the question of "Why use a rich application framework at all?," and second, there's the question of "Why choose Backbone over its alternatives?." Let's start with the first question.

To truly appreciate the value of a single-page application (SPA), it's essential to understand what came before. All previous websites can be grouped into three major categories, which I'll call static, server-based, and JavaScript-assisted. Each of these types correlates with a different era in web development history.

In many ways, the history of web development can be seen as a progression from server-based logic to client-based logic. The story begins in 1993, with the introduction of the world's first real web browser: Mosaic. At that time, the Web didn't even have JavaScript (or CSS, for that matter), just HTML. In those early days, most sites were simple static sites, and any site with dynamic elements had to be entirely server based. The very first version of JavaScript would only be introduced two years later at the end of 1995, and it would take several more years before the language was useful for anything other than simple form validation.

Yahoo!'s JavaScript-less website in 1997

Luckily, the Web did evolve, and soon JavaScript developers witnessed the birth of a whole new wave of JavaScript libraries, such as Dojo, MochiKit, YUI, and, of course, jQuery. These libraries allowed developers to easily manipulate the DOM, avoid the rampant cross-browser issues of the time, and take advantage of a newly introduced technology known as AJAX. In other words, they enabled developers to create a new type of site, the JavaScript-assisted but still largely server-based web application.

Even with these advances, the server still maintained control over two critical pieces of a site's infrastructure: navigation and page rendering. This problem wouldn't be solved until years later, with the introduction of the modern generation of JavaScript frameworks, the first and popular one being Backbone. Using Backbone, web developers were finally able to control an entire site using only the client-side technologies of JavaScript, HTML, and CSS, which meant that they could create an entirely new type of web application, the thick client or single page site.

Today, even with the advent of Backbone and related libraries, many developers still continue to create the three previous types of site, which is perfectly reasonable as long as their goals are modest. In other words, if you simply want to show off your wedding photos to friends, then you probably don't need the full power of Backbone. However, if your goal is to build a powerful and robust web application, then the advantages of a Backbone-powered site are clear.

While there are numerous benefits of adopting thick client architecture for a site, they can be grouped into three main categories: asset control, easier data management, and improved performance.

<tr>
    <td>Fake Book</td>
    <td>This is a description of a fake book</td>
    <td><a href=""/buy/book1"">Buy Fake Book</a></td>
</tr>
<tr>
    <td>Another Fake Book</td>
    <td>I hope you like fake book titles because plenty more are coming in future chapters...</td>
    <td><a href=""/buy/book2"">Buy Another Fake Book</a></td>
</tr>

Many of the advantages we've just discussed apply to any single-page application, not just a Backbone one. This means that you can achieve many of those benefits even if you use one of Backbone's competing libraries, such as Ember or Angular. Whether you've considered using these frameworks or not, you're probably at least wondering, "Will Backbone provide me with everything I need to build my site, both now and in the future?"

The first thing to consider when answering this question is whether or not Backbone has an active community and will continue to be actively developed. Backbone users can feel safe in this regard: at the time of writing this book, Backbone's GitHub page had more than 1,500 watchers and more than 21,000 stars, beating its next closest competitor (Ember) by more than 400 watchers and 7,000 stars. Other frameworks such as CanJS and Google's Angular have even less interest on GitHub. While this certainly doesn't make Backbone better than those libraries, it shows the strength of its community and should provide you with the assurance that Backbone will be around for many years to come.

Another reason to feel confident when selecting Backbone is that it only tries to do a specific set of tasks, leaving everything else to external libraries. This means that if you find a better template system, dependency management tool, or any other library in the future, you can easily switch to using it. Other frameworks tightly couple things such as their template systems to their framework, leaving you with less options in the future.

However, perhaps the biggest indicator of Backbone's vitality is the companies that are already using it to accomplish amazing things. Companies as varied as USA Today, Pandora, Hulu, Gawker Media, AirBnB, Khan Academy, Groupon, and even Walmart use Backbone to create powerful web applications. If Backbone is powerful enough to support these major companies, it's almost certain to be powerful enough for your project.

There's one other company that uses Backbone, which is the company that I work for—Syapse. At Syapse, we've built a precision medicine data platform that helps hospitals receive genetic data in a structured format, pull patients' clinical data from a variety of internal health IT systems, and present this data together in an interactive web application. Through this interface, physicians see their patients' genetic and clinical data in context, enabling them to choose the most effective drugs possible tailored to a patient's own genetic profile.

Creating an application like Syapse did isn't easy, and with serious diseases such as cancer on the line, there's little room for error. However, using Backbone, Syapse has managed to grow from just one developer to a six-person client-side team with over 21,000 lines of code (not counting libraries) in just 3 years. Were it not for Backbone's ability to scale, there's simply no way we could have grown that quickly, at least without making major changes to our architecture along the way.

In short, while Backbone itself may be just under half a decade old, the real-world usage of the library has proven both its value and scalability. If your goal is to create a powerful and robust web application that a single developer can easily get off the ground but which can also grow and be supported by a full-sized team, you cannot go wrong with Backbone.

In this chapter, we explored how Backbone represents a new chapter in web development and why it's the best framework for your project if your goal is to make powerful and scalable web applications.

In the next chapter, we'll begin to take a look at the components that make up Backbone, in particular its easy-to-use class system. We'll also look at Backbone's sister library, Underscore, which was also created by Jeremy Ashkenas and is a requirement for Backbone itself.