Let's Make a Framework: Ajax Part 2

2010-05-27 00:00:00 +0100 by Alex R. Young

Welcome to part 14 of Let's Make a Framework, the ongoing series about
building a JavaScript framework. This part continues discussing Ajax.

If you haven't been following along, these articles are tagged with
lmaf. The project we're creating is called Turing and is available on GitHub:

Cross-Domain Requests

Cross-domain requests are useful because they can be used to fetch data
from services like Twitter. This is now a popular technique, despite
feeling clunky to implement. This is another case where lack of browser
features can be patched by JavaScript.

Implementations in the Wild

The Glow framework has
glow.net.xDomainGet and glow.net.loadScript.
These are similar, but place different requirements on the server. What
loadScript does is called JSONP. jQuery also implements
JSONP, and has this to say in the documentation:

The jsonp type appends a query string parameter of callback=? to the URL. The server should prepend the JSON data with the callback name to form a valid JSONP response. We can specify a parameter name other than callback with the jsonp option to \$.ajax().

A JSONP URL looks like this:


The reason a callback is specified in the URL is the cross-domain Ajax
works by loading remote JavaScript by inserting script
tags, and then interpreting the results. The term JSONP comes from JSON
with Padding
, and originated in Remote JSON -

by Bob Ippolito.

The Algorithm

JSONP works like this:

  1. The framework transparently creates a callback for this specific
  2. A script tag is inserted into a document. This is of course
    invisible to the user
  3. The src attribute is set to
  4. The server generates a response
  5. The server wraps its JSON response like this:
    jsonpCallback({ ... })
  6. Once the script has loaded, the callback is called, and the client
    code can process the JSON accordingly
  7. Finally, the callback and script tags are removed

As you can see, servers have to be compliant with this technique -- you
can't use it to fetch arbitrary JSON or XML.

API Design

I've based this on the Glow framework, and the option names are
consistent with the other turing.net code:

turing.net.jsonp('http://feeds.delicious.com/v1/json/alex_young/javascript?callback={callback}', {
  success: function(json) {

The {callback} string must be specified -- it gets replaced
by the framework transparently.


To create a callback, no clever meta-programming is required. It's
sufficient to create a function and assign as a property on

methodName = '__turing_jsonp_' + parseInt(new Date().getTime());
window[methodName] = function() { /* callback */ };

A script tag is created and destroyed as well:

scriptTag = document.createElement('script');
scriptTag.id = methodName;

// Replacing the request URL with our internal callback wrapper
scriptTag.src = url.replace('{callback}', methodName);

// The callback should delete the script tag after the client's callback has completed

That's practically all there is to it. You can see the real
implementation in
turing.net.js by searching for JSONPCallback.


Although JSONP requires server support, a wide variety of interesting
services support it. This simple technique has made cross-domain
requests popular -- how many blogs and sites now feature live Twitter
feeds written with pure JavaScript?