TrafficCop: A jQuery Plugin To Limit AJAX Requests For A Resource

A while back, I wrote about asynchronous template loading for Backbone applications. At the bottom of that post, I showed some code that I wrote which would limit the number of AJAX calls that are made to the server, to one per resource. That way we wouldn’t end up with multiple calls to the same template, wasting precious network time.

  var promises = {};

  var loadTemplateAsync = function(tmpId){
    var promise = promises[tmpId] || $.get("/templates/" + tmpId + ".html");
    promises[tmpId] = promise;
    return promise;

  Backbone.Marionette.TemplateCache.loadTemplate = function(templateId, callback){
    var tmpId = templateId.replace("#", "");
    var promise = loadTemplateAsync(tmpId);
    promise.done(function(template){, $(template));

Well it turns out I was on the right track, but Jim Cowart has a much better implementation of this as a jQuery plugin called TrafficCop. Using this plugin, I was able to reduce my code from the above to this:

Backbone.Marionette.TemplateCache.loadTemplate = function(templateId, callback){
  var tmpId = templateId.replace("#", "");
  var url = "/templates/" + tmpId + ".html";
  var promise = $.trafficCop(url);
  promise.done(function(template){, $(template));

My BBCloneMail app has been updated to use TrafficCop and this is the actual code from the “bbclonemail.views.js” file. Be sure to read Jim’s blog post that introduces TrafficCop, why it’s needed, etc. And checkout the source on Github.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Async, Javascript, JQuery. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Derick – it’s always exciting to see other people find your projects useful!  I initially had TrafficCop as an internal dependency in another project and a dev friend of mine strongly suggested I make it a separate project.  ”Really?  You think people would use it?” was probably my response. :-)  Anyways – exciting to now see it being used in BBCloneMail – keep cranking out such great BB examples!

  • Torkel Odegaard

    what is your view of requirejs, when googleing for ways to structure backbone apps, requirejs seems to not to be an uncommon option (I am not sure how common it is).  Have you tried it? It supports loading of tempalate files also (through the text plugin). 

    It looks a litle verbose for my taste, but it has some nice things (every file gets very small and is only one thing). But I have yet to find a really good example of a requirejs backbone app that has a good router approach and only loads views/models when they are needed/used. 


    And there are multiple stackoverflow questions regarding backbone and requirejs. 

    I am in the planing/poc phase of a backbone app and can’t decide if require js approach is the right one, or go with an approach similar to your bbclonemail / marionette approach. 

    • I have mixed feelings about RequireJS. 

      It solves a very real set of problems, and once you get past the initial learning curve and modifications to libraries that don’t support it, it can help you keep your code organized.

      On the other hand, I can’t stand the giant mess that it makes and the need to rewrite a significant number of libraries, just to add the cruft of the module definition and export… it’s all too much for me. 

      Yes, the problems that it solves are real problems. No, RequireJS is not the only answer to those problems. We’ve been building JavaScript applications for many years before RequireJS was around, and there are plenty of solutions that can be put together with a combination of smaller, focused libraries.

      How’s that for a non-answer? :)

  • Thanks for sharing the information.

    I found this whole blog very very informative.