This article is a continuation of Part 2: Backbone.js + Require.js, Further Modularization and Just in Time Dependency Loading. It describes how to use a cache manifest to improve just in time dependency loading performance. It also provides a cache priming alternative in the event that the user’s browser does not support a cache manifest, i.e. IE.


In the previous post we further modularized the code and took a look at using require.js to lazy load dependencies. After reading the last post you might have thought great now my code has to wait on network calls during run time if the block has never been executed. Don’t be such a negative Nancy. It is time you made use of the application cache.

Application Cache

A very bright developer wrote an excellent article on using the application cache. Although, I hear that he has begun to somewhat second guess his thoughts regarding offline usage. At any rate you can read it or choose from plethora of better articles on the web if you are unfamiliar with the application cache.

The first thing to notice in the code is that I added the file manifest.appcache, which is the cache manifest. This file is included via the master index.html by adding an attribute to the opening html tag. If a user’s browser supports the application cache then the files listed in manifest.appcache will automatically be downloaded and stored locally in the browser’s application cache, which is separate from the standard cache. A new file, cache.js, was also added to the bootstrapping process, main.js. cache.js contains a method that adds a load listener to reload the master in the case that cache manifest has changed, so that the updates are picked up without the user having to manually refresh.

Now you Debbie downers might be asking what if a user’s browser does not support the application cache?

Cache Priming

You could stand to learn a thing or two from Pollyanna. In the event that a user’s browser does not support the cache manifest then we can use a simple cache priming trick. Nothing up this sleeve…

The prime method in cache.js automatically handles this for you. It parses manifest.appcache and makes XHR requests for each file listed in the manifest. There is a 5 second delay before this process executes, so that the application is not sluggish when it loads. The interesting thing to note is that we do not process any of the files. We simply make the request, so that the files get cached in the standard browser cache. You don’t really gain much in this example because the majority of the files are used right out of the gate when the application loads, but you can see the benefit in larger applications.

Wrap Up

There you have it. No network delays at run time.  On a related topic, since I started writing these articles I have a adopted a different approach to bootstrapping. Instead of loading commonly used “global” files, such as jQuery, Backbone, and Underscore, one at a time I now combine like files and make a single request. This solves a couple problems.

  1. Removes any required hacks or reliance on AMD forks when loading non AMD compliant libraries such as Backbone and Underscore; this greatly simplifies bootstrapping
  2. It reduces the number of network calls

This may rub AMD purist the wrong way, but to me it is simpler and more efficient. Why not combine jQuery, Backbone, and Underscore into a single file and load it via require.js? Sure reliance on the globals is evil in the strictest sense, but I hate to dogmatically adhere to a design philosophy when I know that the simpler solution will suffice in 99% of the cases.

Up Next

Episode IV: A New Platform (Backbone.js + Require.js)