One of the challenges of developing a traditional multipage website is the sharing of HTML assets. On such a site, the HTML is generated using server-side tools, such as Django templates, ERBs, or JavaServer Pages (JSPs) but, of course, the client-side logic also depends heavily on that same HTML. In smaller organizations, this means that programmers frequently have to divide their focus between JavaScript and a server-side language, which can be frustrating due to the frequent context switching.

In large organizations where teams are separate, the HTML assets are usually managed by the server team. This sometimes makes it difficult for the client team to even make the most basic changes to the site's HTML, as they have to work across the aisle. When they fail to do so, often the result is such that they create parallel versions of the server team's work instead, with such duplication inevitably resulting in bugs.

Backbone-powered thick client applications solve these problems by leaving the site's HTML firmly under the control of the client team, either in the form of a template system, raw HTML files, or in DOM-manipulation JavaScript logic. Any interactions between the two teams happen through a carefully negotiated set of APIs, allowing both groups to focus on their core specialties without stepping on each others toes.

As an application scales, it may become difficult to manage the interactions between its various components. One powerful approach to solve this problem is to use event-based control systems, but before Backbone, such systems were rarely found in JavaScript. True, DOM events have long been a part of web development, but without a framework such as Backbone, developers have been limited to just the user-generated events. To truly realize the power of an event-based system, you also need data-driven events, which are an integral part of Backbone.

Another common scaling challenge comes from JavaScript's lack of support for object-oriented programming (OOP). OOP allows programmers to organize large, complicated logic into smaller, more manageable classes and is very useful when growing an application. While JavaScript has a built-in class system, it is fairly unconventional and often discourages developers from employing OOP techniques. Backbone solves this problem by providing a more friendly system that, while still built within the limits of the JavaScript language, looks much closer to what you'd find in a solid OOP language, such as Java.

On the Web, speed is paramount, and one significant factor in a site's speed is the weight of its HTML files. In a multipage application, every time the the user visits a new page, their browser has to send a request and wait for a response from the server. When the response comes back, it doesn't just contain a unique HTML for that page. Instead, the response contains the HTML for everything, including any common site components such as menus or footers. When the user visits the next page, they once again have to download that same common component HTML, even if it hasn't changed.

Moreover, that's not the only redundant HTML downloaded: multiple rows in a table, multiple search results in a list, or any other repeated content also has to have its HTML downloaded multiple times. For instance, consider the following HTML:

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

Only the names, descriptions, and URLs of the two books are unique in the preceding code, but even so all of the nonunique parts of the code have to be downloaded with it. If the site shows 50 books, the user downloads 50 copies of the book row HTML. Even when a site has no common components or repeated elements, there's still a performance cost when the user visits a new page because the browser has to go through an entire request-response cycle and then reload and redraw the page, all of which takes time.

In a single-page application, none of this is an issue. The site's foundation HTML is downloaded only once, and after that, all page transitions happen entirely through JavaScript. Since the client knows how to render both common and repeated components, there's no need to download any HTML for them at all. On a Backbone site, the server sends only the unique data via AJAX, and if there is no unique data to download, the user can progress without making a single new request to the server.