Ajaj: Ajax2.0


Is Ajaj the new Ajax?

Ajax: Asynchronous Javascript and XML. I wonder though how many people actually use XML in web2.0 applications. After all, an XMLHttpRequest can return both responseXML and responseText. My bet is that text, including *J*SON, is used far more frequently than XML.

If one can do all the data processing server-side, send it back as HTML text to the browser, and the browser needs only to set some innerHTML, why bother with XML? Well, you respond, “what if I have structured data and different pieces of data need to go to different parts of the page: a title here, an image URL over there, some content here. Then, innerHTML won’t work. You need to send over data plus descriptive metadata so that the browser code knows what it is.” While, true, I am still not convinced that XML is used that much. First, one can send different chunks of data in simple responseText. For instance, one might send back a comma- or pipe-delimited string. The javascript does a split on that character and so long as the correct ordering of those data pieces is preserved, the data can be separated and sent where it needs to go in the page. For more complex data, or for a more robust data transfer one can use JSON in the responseText.

I’ve been developing an API for the labs recently and each method can produce JSON and XML. It was really striking to me just how easy JSON is to consume in the browser. One gets all the benefits of metadata markup, but it is both very compact and extraordinarily simple to reference those data items in Javascript. For instance, I send

{ name : “Joe Doe”, title : “VP, Engineering”, phone : “13-456-7890”}

[Update : as the comment below points out, it should have read: { “name” : “Joe Doe”, “title” : “VP, Engineering”, “phone” : “13-456-7890”}]

in my responseText. In Javascript I need only do the following:

var obj = eval( ‘(‘ + XMHttpRequest.responseText + ‘)’ );

and now I reference those individual data items as obj.name, obj.title and obj.phone. Could it be any simpler?

Well, I thought that until I really started playing around with JSON and found that it has frustrating limits, ones that JSON.org does not highlight (dare I say lie?) in their documentation.

Take the following code:

var j1 = “{ data: “ab”}”;
var obj1 = eval( “(” + j1 + “)” );

what is alerted? “ab”. Correct.

How about this:

var j1 = “{ data: “anb”}”;
var obj1 = eval( “(” + j1 + “)” );

What is alerted? “anb”. Correct? Wrong. It bails.

JSON, or rather the Javascript parser, cannot handle n.

That’s strange I swear that n is shown on JSON’s wonderfully easy to understand documentation. Let’s take a look:

Yes, that’s clear. JSON.org says that ‘n’ is allowed in JSON. I was not the only one to find this n limitation:

“As for the second, regarding newline characters, http://www.json.org/ says they are valid JSON notation”

Sort of, but it also states that “It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999”, which clearly forbids them (par. 7.3)

So it is a lie then. JSON does not support n.

Not only is this annoying but, in my mind, it does limit JSON usage. I cannot use it to transport arbitrary chunks of text.

UPDATE: so at here Ajaxworld in NYC, I just asked Douglas Crockford, inventor of JSON, about this. So, it turns out that n needs to be escaped properly. Thus, the newline character should have been n
That is,

var j1 = “{ data: “anb”}”;
var obj1 = eval( “(” + j1 + “)” );

does work. JSON can handle arbitrary chunks of text so long as unicode characters are properly escaped. Whoops sorry about that. Off to eat some humble pie…