Backbone.js and jQuery

It is said that Backbone handles all the higher level abstractions, while jQuery or similar libraries work with the DOM, normalize events and so on..

Could someone please help me understand this statement with any simple practical example.

Also one important feature of MVC framework like Backbone, Knockout is that it keeps the model (data) and the view in sync. But this seems to be specific at a page-level and not across the entire application. So can we have the model/data and the view synced across multiple pages..(kind of global)

Solution 1:

Your opening sentence was actually a very good statement of the differences between Backbone.js and jQuery, so let's unpack it a bit.

For one thing, the two libraries are not at all in competition--they are complimentary.

As an example, here are some things I would do with jQuery:

• Animated slideshows
• Form control enhancements, like an iOS-style number "spinner"
• Toggling visibility of elements based on a class name

And some things that I might do in Backbone.js:

• Create a photo album, where the user clicks on a thumbnail and can view a larger version of the photo, along with some data like the camera that was used, the location and the photographer's name
• Build a master/details type of page that presents a grid of data and allows the user to click on individual elements and update them in a form.

jQuery excels at the micro level--selecting page elements, smoothing out the differences in how browsers handle events.

Backbone.js is more big-picture. It helps you manage data and application logic. In the photo album example above, Backbone provides several useful structures: you'd have something to contain all of the data related to photos (a model), a list of all the photos in the album (a collection), and somewhere to put logic that determines what happens when a user clicks on a thumbnail (the view). Those are the main pieces in a Backbone control or application.

Backbone.js benefits from jQuery, though, or something like it, to help render the results of your application's data and logic into the DOM. It's common, for example, to use jQuery to select the element on the page that will serve as the container for your Backbone app. It's also common to use jQuery's $(function () {}); to fire up the pieces of your Backbone control. You'd probably display form field validation error messages with jQuery as well.

You can certainly build big, complex user interfaces in jQuery. We have a few in the app I maintain at work. But they are difficult to work with because jQuery isn't designed to provide structure to an application. In particular, jQuery's API, which is based around selecting groups of items and then passing callback functions that manipulate those items, isn't a good pattern to use in a large, complex control or app. You end up with a lot of nested functions and it's very hard to see what's going on.

I'm currently reworking one of those controls in Backbone.js. As a final example, here's a quick summary of how my thought process differs when working on the same control in both different libraries.

In jQuery, I'm worried about:

• Am I using the right selector to grab the group of li elements I want?
• Do I need to repopulate that list of values when this Ajax call completes?
• How can I put these array values back into the input elements on the page?

In Backbone, I'm more focused on:

• What is the correct logic to validate this set of properties on my model item?
• When the user clicks the Add button, should I add a new item to the collection immediately, or should I wait until they've filled in all the data and it's "valid"?
• How should an item in my collection respond when the item immediately before or after it is deleted?

jQuery handles the nitty-gritty details, and Backbone is more high-level.

In closing, notice I've been using the words "control" and "app" when discussing Backbone.js examples. It's not true that Backbone.js is just for single page apps. It is true, though, that Backbone.js is good for building complex applications that manipulate data and handle a lot of logic. It would be silly to use it for small-scale UI elements--the extra structure it imposes isn't needed.

Update: On the issue of multiple pages, yes, Backbone does provide a powerful mechanism for persisting your data. Each model has a save method that will execute an AJAX call to store the changes on the server. So as long as you save your data as you go, you can have a multi-page app. It's a very flexible model, and it's how we'll probably end up using Backbone at work. While I would love to build a single-page app, we have 10 years of work in our existing multi-page application. We're looking to rebuild some of our more intense UI components in Backbone, then sync the changes to the server before the user moves to a different page.

Solution 2:

Backbone / Knockout is typically used for single page applications. So while jQuery is a toolbox that can be used with any webpage, Backbone is meant for a specific type of application and helps you organize your code for it. At least in my experience one of the biggest challenges in building a single page app is keeping the code clean and modular, and backbone helps a great deal with this.

The characteristics of a typical backbone app are:

• Essentially static html page, with nothing generated on the server
• Server acts as a json REST api, which provides the content for the app
• The dom elements to display the data are created with javascript in backbone views, using jQuery and various templating libraries to help
• Communication with the server as well as between different parts of the app is done through the backbone models

Regarding your question about keeping the data synced across multiple pages, my instinctive answer is that you don't need multiple pages: the user may perceive that the page is changing, the address in the url bar changes thanks to pushState functionality, but technically the entire app is one page.

The biggest advantages of this kind of approach are a smooth user experience (no reloading pages), good caching support as everything except the json data is static content, for mobile targets the possibility to turn the web app into a mobile app with phoneGap (because everything except json is static).