Make no assumptions: jQuery and JSONP

The implementation of JSONP in jQuery kinda sucks. Part of the point of jQuery is to abstract away the underlying differences between implementations (mainly browsers) and provide a common interface. You would think this is true across the board but its not quite – well at least when it comes to JSONP.

Support for JSONP is found within the Ajax part of the framework. When using this API, you make basic assumptions about the contact it presents – i.e. that is supports contrcuts like promises for all requests, or being able to have success/error/complete methods run if you provide them. It turns out that because of the abstraction that jQuery provides, this is true for all Ajax requests, except JSONP.

The guys who worked on this code obviously intended that people should be able to treat JSONP requests just like any other AJAX request – providing a nice level of abstraction and providing a common interface. But when it comes to JSONP, about the only contruct it does support is “success” – meaning if there is a 404 with your request or anything else goes wrong, “error” will never run, likewise, “complete” never runs as well. Due to the common API and the fact that these are fairly basic constructs which one could mistake quite easily should run for each type of request. It turns out this is the assumption that I made which had me scratching my head for quite some time.

In the defence of the authors, the documentation ( does state that these constructs/handlers aren’t supported with JSONP, by my argument is that if so much isn’t supported, then it shouldn’t be a part of this interface. But I digress, I didn’t start this just to complain.

Given the fact that I don’t think its acceptable to not know whether your query/request has succeeded or not, I set out to find an alternative. In my search I found Julian Aubourg’s (@jaubourg) solution where he has provided the support for JSONP that should have been included out of the box (i.e. error checking)! –

See it, love it and use it. I don’t know why the guys in jquery have decided that JSONP should have better support out of the box, but at the current time there is no better alternative.


 Add your comment
  1. Hi Anthony,

    Fun thing is I am the author of the jQuery-JSONP plugin AND I also am the maintainer of the ajax module in jQuery.

    Why jQuery doesn’t support what jQuery-JSONP supports is a question of reliability. All the trickeries in jQuery-JSONP rely on browser sniffing (nothing is feature testable, I even have to sniff between different versions of Opera). and they pretty much get smashed into pieces when a new version of a browser gets released: in short, using jQuery-JSONP is bleeding edge at its upmost. I use it in production but only on those sites I know I can hack on very quickly.

    Even if we accepted to lower jQuery’s standard here, we wouldn’t be able to handle errors for cross-domain scripts loaded using script tag injection. See, lots of the error detection logic in jQuery-JSONP is about knowing if the callback has effectively been called. None of that stands for your random script that is not supposed to call a specific pre-existing function to begin with.

    So we decided that it was better to keep jQuery solid (ie: no error handling cross-browser) and have power users use the plugin.

    Hope it makes things a bit clearer 😉

    — Julian

  2. Hey Julian

    Thanks for the feedback. Really good to get some insight into the hows and whys of what is going on here. I would still like to know what the thinking behind why jQuery puts JSONP support into the AJAX API even though it doesn’t support the full api?

    Why not go for something like $.JSONP… are you hoping that eventually the full API can be supported? If its the latter case it would really be nice to see the JSONP?

    Besides that I can see why you have it as separate code base and agree with the decision.

    Only feedback that I would give is to try and make these current limitation more known, as I had to do a lot of searching to find this problem.

    Thanks again for your feedback and hard work!


Leave a Comment

Your email address will not be published.