Frank Lloyd Wright once said, “You can’t make an architect. But you can open the doors and windows toward the light as you see it.” In this book, I hope to shed some light on how to improve the structure of your web applications, opening doors to what will hopefully be more maintainable, readable applications in your future.
The goal of all architecture is to build something well—in our case, to craft code that is enduring and delights both us and the developers who will maintain our code long after we are gone. We all want our architecture to be simple, yet beautiful.
Without something to help tame the mess, you’re likely to string together a set of independent plug-ins and libraries to make up the functionality or build everything from scratch and have to maintain it yourself. Backbone solves this problem for you, providing a way to cleanly organize code and separating responsibilities into recognizable pieces that are easy to maintain.
Models represent the domain-specific knowledge and data in an application. Think of this as being a type of data you can model—like a user, photo, or todo note. Models can notify observers when their state changes.
Thus, in an MVC application, user input is acted upon by controllers, which update models. Views observe models and update the user interface when changes occur.
For this reason we refer to such frameworks as following the MV* pattern—that is, you’re likely to have a model and a view, but a distinct controller might not be present and other components may come into play.
Developers commonly use libraries like Backbone.js to create single-page applications (SPAs). SPAs are web applications that load into the browser and then react to data changes on the client side without requiring complete page refreshes from the server.
Backbone is mature and popular, sporting both a vibrant developer community and a wealth of available plug-ins and extensions that build upon it. It has been used to create nontrivial applications by companies such as Disqus, Walmart, SoundCloud, and LinkedIn.
And because Backbone is small, there is also less your users have to download on mobile or slower connections. The entire Backbone source can be read and understood in just a few hours.
At the outset, it isn’t terribly difficult to write your own application framework that offers some opinionated way to avoid spaghetti code; however, to say that it is equally as trivial to write something as robust as Backbone would be a grossly incorrect assumption.
There’s a lot more that goes into structuring an application than tying together a DOM manipulation library, templating, and routing. Mature MV* frameworks typically include not only the pieces you would find yourself writing, but also solutions to problems you’ll find yourself running into down the road. This is a time-saver whose value you shouldn’t underestimate.
So, where will you likely need an MV* framework and where won’t you?
These types of applications typically download a single payload containing all the scripts, stylesheets, and markup users need for common tasks and then perform a lot of additional behavior in the background. For instance, it’s trivial to switch between reading an email or document to writing one without sending a new page request to the server.
Maturity in software (framework) development isn’t simply about how long a framework has been around; it’s about how solid the framework is and, more importantly, how well it’s evolved to fill its role. Has it become more effective at solving common problems? Does it continue to improve as developers build larger and more complex applications with it?
The library doesn’t focus on widgets or replacing the way you structure objects—it just supplies you with utilities for manipulating and querying data in your application. It also doesn’t prescribe a specific template engine; while you are free to use the micro-templating offered by Underscore.js (one of its dependencies), views can bind to HTML constructed via your templating solution of choice.
When we look at the large number of applications built with Backbone, it’s clear that it scales well. Backbone also works quite well with other libraries, meaning you can embed Backbone widgets in an application written with AngularJS, use it with TypeScript, or just use an individual class (like models) as a data backer for simpler apps.
There are no performance drawbacks to using Backbone to structure your application. It avoids run loops, two-way binding, and constant polling of your data structures for updates, and it tries to keep things simple where possible. That said, should you wish to go against the grain, you can, of course, implement such things on top of it. Backbone won’t stop you.
With a vibrant community of plug-in and extension authors, it’s likely that if you’re looking to achieve some behavior Backbone is lacking, there’s a complementary project that works well with it. In addition, Backbone offers literate documentation of its source code, allowing anyone an opportunity to easily understand what is going on behind the scenes.
Having been refined over two and a half years of development, Backbone is a mature library that will continue to offer a minimalist solution for building better web applications. I regularly use it and hope that you find it as useful an addition to your toolbelt as I have.
The goal of this book is to create an authoritative and centralized repository of information that can help those developing real-world apps with Backbone. If you come across a section or topic that you think could be improved or expanded, please feel free to submit an issue (or better yet, a pull-request) on the book’s GitHub site. It won’t take long, and you’ll be helping other developers avoid the problems you ran into.
Topics will include MVC theory and how to build applications using Backbone’s models, views, collections, and routers. I’ll also be taking you through advanced topics like modular development with Backbone.js and AMD (via RequireJS), solutions to common problems like nested views, how to solve routing problems with Backbone and jQuery Mobile, and much more.
Here is a peek at what you will be learning in each chapter:
Covers the major features of Backbone.js and the technologies and techniques you will need to know in order to use it effectively.
Takes you step by step through development of a simple client-side todo list application.
Walks you through development of a book library application that persists its model to a server using a REST API.
Describes Backbone.Marionette and Thorax, two extension frameworks that add features to Backbone.js that are useful for developing large-scale applications.
Reviews common issues you may encounter when using Backbone.js and ways to address them.
Looks at how AMD modules and RequireJS can be used to modularize your code.
Takes you through rewriting the app created in Exercise 1 to be more modular, with the help of RequireJS.
Walks through how to use the Backbone.Paginator plug-in to paginate data for your collections.
Introduces powerful tools you can use to bootstrap a new Backbone.js application with boilerplate code.
Addresses the issues that arise when you are using Backbone with jQuery Mobile.
Covers how to unit-test Backbone code using the Jasmine test framework.
Discusses how to use the QUnit for unit testing.
Discusses how to use SinonJS to unit-text your Backbone apps.
Provides references to additional Backbone-related resources.
Wraps up our tour through the world of Backbone.js development.
Returns to our design pattern discussion by contrasting MVC with the Model-View-Presenter (MVP) pattern and examines how Backbone.js relates to both. Also includes a walkthrough of writing a Backbone-like library from scratch and covers other topics.