XML vs JSON: A Second Sober Look 
January 8th, 2007
There has been a recent fleury of discussion about XML vs JSON. What a great topic for the holidays.
Although I have been talking about this topic for some time, some XML bloggers have recently started to discuss the topic (Tim Bray, Don Box, David Megginson, Dare Obsanjo and all the comments). For the most part the discussion is pretty tame and nothing really new.
Tim brings up the good points about extensibility and encoding. He also importantly acknowledges the fact that JSON is applicable in certain cases. To his points I would add the fact that one is able to use XPath with XML making it very powerful for quickly finding data. XPath is one XML technology that many ignore, particularly in the JavaScript sandbox.
The other important points are really in direct response to Dare Obsanjo’s posts from last week: Browser Security Model and Browser Programming Model. First of all, Dare suggests that one reason for JSON being so popular is due to cross-domain JSON (also called JSONP or JSON with Padding). Ignoring the data format, this pattern is applicable to any kind of data, including XML (XML with Padding is equally valid). There is no reason that Yahoo! could not provide a cross-domain XML API along side a cross-domain JSON API. In fact, I urge people to email everyone they know over at Yahoo! to do so for all their properties such as del.icio.us.
There are also a few points I have in response to the second post about the difference between the programming models of JSON and XML. The main thing that I noticed is that the example presents is not a realistic use case. What is most commonly done with data in an Ajax application is that the data is rendered to HTML. The fastest way to render data to HTML is using XML and XSLT. The other thing that he does not look at is cases where the data needs to be sorted or filtered, in which case XML and either XSLT or XPath provide a very nice solution. Of less importance, Dare also states that one should use a JSON parser in case of security concerns, however, the JavaScript based JSON parsers that I have used have had very extremely poor performance - even worse than plain eval().
The other interesting thing was a comment made by Kevin Hackman from TIBCO in the Ajaxian post. Kevin mentioned the fact that TIBCO uses XML to maintain the JavaScript state - i.e. each JavaScript object has a related XML document where the the object properties are stored and accessed using standard JavaScript accessor methods - which helps in terms of application memory usage. This is something that the soon to be released Nitobi Complete UI Framework also does, although for slightly different reasons like the fact that objects can then be easily serialized for use with server frameworks like JSF or ASP.NET.
At any rate, I am happy to see that some others are joining in on the discussion and if nothing else I hope that people start to talk more about using XSLT and XPath in the browser.
Posted in AJAX, XML, XSLT, Declarative Programming, Performance, markup | 7 Comments »
Holy Memory Leak Batman!
September 11th, 2006
Not sure why I am on this Batman kick but I just checked out Flickr for memory leaks in preparation for my talk at AjaxWorld in October and it is just crazy. The image speaks for itself. Just loading and re-loading a picture details page on Flickr seems to have massive memory problems for IE based on the Drip tool. Click the image below to see the enitre story in all its drippy goodness.
Posted in AJAX, Performance, Flickr, Memory | No Comments »
On Classical JavaScript Inheritance
September 7th, 2006
Ok, I have been a little busy lately (well really busy) but this post has been in the works for a few weeks now so I just want to get it out.
First off, of the half dozen or so requirements that Dean Edwards puts on his Base.js implementation I admittedly only agree with two of them - and you should see why at the end of this post. Those two are:
I want to avoid calling a class’ constructor function during the prototyping phase
I want to achieve the above without affecting Object.prototype
Those are by far the most important points - particular number one since when dealing with the DOM / UI we don’t want things to happen pre-maturely.
Anyway, the reason for this post is actually due to a recent post on Ajaxian about JavaScript inheritance that was interesting to say the least. It reviewed a few different techniques of performing classical inheritance in the prototype base language that is JavaScript. It reviewed simple inheritance using the syntax like
SubClass.prototype = new BaseClass();
where super methods can be called using global references to the BaseClass from the SubClass and call or apply such as
BaseClass.prototype.getName.call(this);
The author also looked at the more advanced technique from Douglas Crockford and finally showed his preferred method.
There are a few points that I would like to add to the discussion. First of all, the authour suggests staying away from syntax such as
function BaseClass() {
this.getName = function() {
return "BaseClass";
};
}
due to the fact that it can cause “SEVERE” memory leaks in Internet Explorer. Closures - which is what is used here - are one of the most useful features of JavaScript and should not be avoided but instead embraced. Indeed, if you lose references to DOM elements in your closures without removing them you can get memory leaks. Whether or not the leak is severe depends on how much memory is taken up by your DOM references of course. Just because something is dangerous does not mean it should be avoided - I am not going to stop drinking scotch any time soon 
I also thought that the example he gave to show how the Crockford method is broken was a bit strange. Admittedly, it does seem that the alert from the Crockford method is not correct being (2-1-1), however, I don’t think that the alert from the authors code is correct either. The numbers I would expect to see would be (2-2-1). In fact, with no polymorphism, overrides or other method metadata, who is to really say how it should work?
There were also two very important inheritance techniques that I thought should have certainly been mentioned. One important technique is that developed by Dean Edwards, which _very_ nicely emulates the usage of the super keyword in Java (although he uses base since super is reserved) to provide access to the BaseClass. If you are interested in the Dean Edwards code go check out his blog. The other is the use of global references that refer not to the BaseClass, as the authour showed in his article, but instead to the SubClass; thus, we avoid any problems one may have with making explicit references to the BaseClass within the SubClass code. We can define a global function that extends a SubClass that looks something like this:
/**
* Allows support for inheritance.
* @param subClass {object} The class that will inherit from the base.
* @param baseClass {object} The class that will be inherited from.
*/
nitobi.extend = function(subClass, baseClass)
{
// Create a new class that has an empty constructor
// with the members of the baseClass
function inheritance() {};
inheritance.prototype = baseClass.prototype;
// set prototype to new instance of baseClass
// _without_ the constructor
subClass.prototype = new inheritance();
subClass.prototype.constructor = subClass;
subClass.baseConstructor = baseClass;
// enable multiple inheritance
if (baseClass.base)
{
baseClass.prototype.base = baseClass.base;
}
subClass.base = baseClass.prototype;
}
This is similar to the method over on Kevlindev. Btw, discussion about all of these techniques can be found before the Crockford technique when Googling for “JavaScript inheritance”. I digress. We have also added the prototype chain support for the
base
keyword. This type of inheritance has met all our needs and enables multiple inheritance by providing global references to the BaseClass through the SubClass itself as well as to the base constructor. To use it one would write something such as this:
SubClass = function() {}
nitobi.extend(SubClass, BaseClass);
Methods in the BaseClass are then called like this:
SubClass.base.someMethod.apply(this, arguments);
Not only is this, IMHO, a clearer syntax than something more esoteric like “arguments.callee.$” but it also has the added advantage of being faster - as I will show in a moment - than something more complicated like being able to use the word “base” directly. Furthermore, by using the Prototype library syntax for defining functions where the prototype of an object is set to an inline object itself such as:
var myClass.prototype = Class.extend({
someMethod: function() {},
someProperty: 5
});
it makes it much more difficult to document using tools such as JSDoc. I always find myself missing commas too! Personally, I find the Prototype syntax much more unfriendly, although it is slightly more terse.
As for the performance, just to give an idea of how the different techniques fair I made a simple animal inheritance chain and checked that the inheritance works properly using each method and then measured 1000 class definitions and instantiations with a call to the super / base in the constructors. It was some nonsense like this:
function Animal(name) {
this.name = name;
};
Animal.prototype.name = "";
Animal.prototype.eat = function() {
this.say("Yum!");
};
Animal.prototype.say = function(message) {
alert(this.name + ": " + message);
};
function Cat()
{
Cat.baseConstructor.call(this, 'cat');
}
nitobi.extend(Cat, Animal);
Cat.prototype.eat = function(food) {
if (food instanceof Mouse) Cat.base.eat.call(this);
else this.say("Yuk! I only eat mice - not " + food.name);
};
function Lion()
{
Lion.baseConstructor.call(this, 'lion');
}
nitobi.extend(Lion, Cat);
Here is what I found for performance using various techniques:
Internet Explorer
| Approach |
Time |
Relative |
| Nitobi |
320 |
1 |
| Crockford |
340 |
1.06 |
| ThinWire |
580 |
1.81 |
| Edwards |
1360 |
4.25 |
Firefox
| Approach |
Time (ms) |
Relative |
| Nitobi |
360 |
1 |
| Crockford |
460 |
1.27 |
| ThinWire |
2300 |
6.39 |
| Edwards |
3600 |
10 |
I was pretty surprised at the horrible performance of the Edwards base.js in Firefox! At any rate, something to consider for those that do things because they want JavaScript to be more like Java
technorati tags:ajax, javascript, performance, benchmark, inheritance, oop
Posted in Web, AJAX, JavaScript, Performance, Benchmark, OOP | 10 Comments »
Entries (RSS)
and