Thursday, August 20th, 2009

jXHR: XHR API, JSON-P backend conduit

Category: Ajax

The Mullet: Business up front, party in the rear

Kyle has take the XHR API that we all know and…. wrap…. and married it with a JSON-P transport to make jXHR.

He tells us more:

I’ve put out a very simple little project called jXHR which does cross-domain Ajax via JSON-P calls (meaning, totally javascript based), but does so with an emulation of the native XHR API (“onreadystatechange”, “open”, “send”, etc). It also provides some basic error handling capabilities, which is something most JSON-P solutions don’t currently offer, at least not without complicated timers, etc.

The goal was to provide a simpler interface for making cross-domain Ajax calls with JSON-P, but in nearly the same way you make same-domain calls, by using the standard XHR API. Also, I wanted the solution to be framework independent for those who don’t or can’t use jQuery, Dojo, etc

Frameworks such as Dojo allow you to choose an transport independent of their API (e.g. iframe transport versus XHR).

Posted by Dion Almaer at 6:55 am

4.8 rating from 70 votes


Comments feed TrackBack URI

For the record, that is NOT a picture of me. :) But funny picture nonetheless, Dion. :)

Comment by shadedecho — August 20, 2009

The main point of jXHR, besides putting the familiar and well-known XHR API wrapper on top of dynamic-script-tag JSON-P calls, was to provide the “onerror” error detection handler functionality.

If you set “onerror” handler, and your JSON-P call fails for some reason, then you’ll be immediately notified, rather than needing to do your own timer detection, etc.

Also, jXHR is less than 700 bytes when minified and gzip’d, so it’s really small and easy to use just about anywhere, including bookmarklets, cross-domain widgets, etc.

Comment by shadedecho — August 20, 2009

lol funny pic

Comment by marlonbtx — August 20, 2009

so you are not using an iframe! you use script tag

Comment by marlonbtx — August 20, 2009

BTW, in honor of Dion’s awesome picture to visualize my API, this project can now be located at:

Comment by shadedecho — August 20, 2009

hehe awesome

Comment by Jadet — August 20, 2009

I love mullet !

BTW, it seems that “internal_callback” variable is global…

Comment by checkca — August 20, 2009

good catch, thank you @checkca. Will fix ASAP.

Comment by shadedecho — August 20, 2009

I think this API would be interesting if its intent was to be a fallback API rather than a “similar syntax”. So if a browser supports the new standard, it uses that, but if it doesn’t, it uses JSONP, either way no manual toggling involved for the developer.

Comment by stimpy77 — August 29, 2009

@stimpy77 — i think you’ve actually hit on exactly why I think that standardizing on the same API is important… so that it’s easy to swap in optional implementations depending on technical environment but without having to code more complex code that makes calls differently. When it’s the same (or nearly the same) API, it greatly simplifies that kind of usage. And that’s my goal, to provide more options for cross-domain Ajax, but without fragmenting the API into an unmanageable mess.

Comment by shadedecho — September 16, 2009

one problem for dynamic script loading is that you do not get XHR response.status from the server, so no way to check for 404 or 500. if you have an invalid url, you never get the publicAPI.onerror handler.

distinct from publicAPI.onerror, with HTML5 ( ; see item #14), you can define scriptElem.onerror for any type of error loading the script.

i added this mod to your script to handle invalid url errors:

after handleScriptLoad

// MOD: added handleScriptFail()
function handleScriptFail() {
if (!script_loaded) {
ThrowError(“Script failed to load [“+script_url+”], most probably due to an invalid URL or server error.”)

inside send:

// P4 MOD: added onerror
scriptElem.onerror = function() {;

Comment by Merl — July 7, 2011

Leave a comment

You must be logged in to post a comment.