On JavaScript Inheritance Performance and Libraries Troubles

Update: I have replied to myself and developers in a new post. I would like to say a big Thank You to every developer exposed tests, benchmark, traps, and considerations. Please read my last thoughts about the subject, since I deeply reconsidered my position.
Update: Please do not get me wrong. I have no intention to say that one or any of cited framework, piece of code, library, is not good or fast enough to extend other classes. This post is about maniac optimization based on personal considerations over some deeper analysis to complete in a way the first benchmark.
I am not criticizing libraries, they are great and they offer everything, I am simply showing a specific case, which is particular on purpose, and a specific behavior that, useful or not, could not be respected.

About

Few days ago Ajaxian published a post about JS inherited methods performances via common libraries strategies.
I think the argument is extremely interesting but there's not enough material yet, so here I am with my contribution plus a "best option" proposal.

Why We Need Libraries to Extend Functions

libraries (should) manage properly the prototypal chain

libraries (should) make code more elegant/readable

libraries (should) let us create overrides being able to call parent/super method implicitly if necessary

libraries are often based over a generic extended "class" or hierarchy and users should be familiar with that way to extend or create classes in order to avoid internal conflicts

Why We Do Not Need Libraries to Extend Functions

we are performances or bytes maniacs and we are scared by library obtrusive implementations

we don't trust the library pattern/strategy to extend function - we know a better way to do it simply and quickly

we would like to create hybrids unmanageable via used library

About above points, let me answer to this question:
"Which Common Code/Library is Good and Fast to Extend Properly?" Considering the YUI approach out of the game, NOT A SINGLE ONE!!!

Tested Libraries in Alphabetic Order

base2, dojo, jClass, MooTools, Prototype, WebReflection (blog proposal), and YUI

About the Test

I tried to create a particular inheritance case.
There is a parent class with a toString and a toLocaleString prototype method.
These methods are particular since they are hidden methods (read: native) and browsers like Internet Explorer do not discover hidden methods even if those have been explicitly assigned.
The extended class should be able to understand the inheritance without problems and produce the expected result, showed in the Ad Hoc example.

Ad Hoc concept and troubles

Concept: manual inheritance over usable constructors.

Troubles: requires a bit of skill and parent calls are always explicit.


// manual implementation
// best performances and expected behavior in every browser
function AdHocClass(name){
    this.name = name;
};
AdHocClass.prototype.toString = function(){
    return this.name;
};
AdHocClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function AdHocSub(name, age){
    AdHocClass.call(this, name);
    this.age = age;
};
AdHocSub.prototype = new AdHocClass;
AdHocSub.prototype.constructor = AdHocSub;
AdHocSub.prototype.toString = function(){
    return AdHocClass.prototype.toString.call(this) + ": " + this.age;
};

// This is the expected result We would like to obtain
var me = new AdHocSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

base2

Concept: runtime injected parent (called via base) over explicit initialization via init method

Troubles: every instance calls two functions when initialized: the contructor plus the init method. This slows down performances. At the same time, not every method is inherited properly.


var BaseClass = base2.Base.extend({
    constructor:function(name){
        this.name = name
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var BaseSub = BaseClass.extend({
    constructor:function(name, age){
        this.base(name);
        this.age = age;
    },
    toString:function(){
        return this.base() + ": " + this.age;
    }
});
var me = new BaseSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString both IE and Others

dojo

Concept: lazy dependencies resolution via the initializer method

Troubles: the initializer method is not that linear ~~and it is probably the slowest in the list~~. Sometimes we need to call explicitly the method, as first argument, while sometimes we need to modify the arguments object or create an array to call the parent method. ~~I am not sure I used dojo best practices to replicate the scenario but that's what I found googling for a while~~ (Update: thanks to Eugene Lazutkin I could use a better practice which improved consistently performances). Is the rest fine? Not really, Internet Explorer does not inherit some hidden method. Update: apparently dojo offers different possibilities to extend and "play" with parents, so this is just one of them.

dojo.declare("dojoClass", null, {
    constructor:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
dojo.declare("dojoSub", dojoClass, {
    constructor:function(name, age){
        this.age = age;
    },
    toString:function($super){
        return this.inherited("toString", arguments) + ": " + this.age;
    }
});
var me = new dojoSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not in IE
alert(me.toLocaleString()); // ERROR: same as toString in IE

jClass

Concept: basically the same one used by base2

Troubles: even worse than base2 since there are no explicit searches for toString and valueOf (most common hidden methods)


var ResigClass = jClass.extend({
    init:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ResigSub = ResigClass.extend({
    init:function(name, age){
        this._super(name);
        this.age = age;
    },
    toString:function(){
        return this._super() + ": " + this.age;
    }
});
var me = new ResigSub("Andrea", 30);
alert(me);                   // Error: [object Object] in IE
alert(me.toLocaleString());  // Error: [object Object] in IE

MooTools

Concept: runtime injected parent, similar to base2. In my opinion the most clean and elegant way to extend a class.

Troubles: Classes are created via Class constructor so we have same bottleneck spotted in base2. Inheritance problems are basically the same found in base2: some hidden method is not inherited.


var MooToolsClass = new Class({
    initialize: function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var MooToolsSub = new Class({
    Extends:MooToolsClass,
    initialize:function(name, age){
        this.parent(name);
        this.age = age;
    },
    toString:function($super){
        return this.parent() + ": " + this.age;
    }
});
var me = new MooToolsSub("Andrea", 30);
alert(me);                  // Andrea: 30 - not inherited in IE
alert(me.toLocaleString()); // ERROR: locale: Andrea in IE

Prototype

Concept: $super variable as parent sent as first argument, imho the most obtrusive way so far and not elegant/intuitive at all.

Troubles: something works as expected, but only toString and valueOf, as is for base2, are considered hidden methods. The extra argument and the method overload make this library almost slow as dojo inheritance implementation is.


var ProtoClass = Class.create({
    initialize:function(name){
        this.name = name;
    },
    toString:function(){
        return this.name;
    },
    toLocaleString:function(){return "locale: " + this.toString()}
});
var ProtoSub = Class.create(ProtoClass, {
    initialize:function($super, name, age){
        $super(name);
        this.age = age;
    },
    toString:function($super){
        return $super() + ": " + this.age;
    }
});
var me = new ProtoSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // ERROR: same as toString in IE

YUI

Concept: a constructor link to its parent prototype via "this.constructor.superclass". No runtime operations, no injected overloads, just "raw methods" based on explicit calls.

Troubles: not really. The YUI approach is extremely simple and efficient then "of course it works"!. There are just a couple of steps resolved via YAHOO.lang.extend: the correct constructor reassignment after the prototype one, plus the superclass link. I have just a comment about YUI implementation: guys, why do not you avoid that function creation for each extend call?


    // No var F = function(){}, i SUGGESTION
    extend: function(F){
        return function(subc, superc, overrides) {
            if (!superc||!subc) {
                throw new Error("extend failed, please check that " +
                                "all dependencies are included.");
            }
            F.prototype=superc.prototype;
            subc.prototype=new F;
            subc.prototype.constructor=subc;
            subc.superclass=superc.prototype;
            if (superc.prototype.constructor == OP.constructor) {
                superc.prototype.constructor=superc;
            }
        
            if (overrides) {
                for (var i in overrides) {
                    if (L.hasOwnProperty(overrides, i)) {
                        subc.prototype[i]=overrides[i];
                    }
                }

                L._IEEnumFix(subc.prototype, overrides);
            }
            
        }
    }(function(){}),

And here we are with the scenario:


function YUIClass(name){
    this.name = name;
};
YUIClass.prototype.toString = function(){
    return this.name;
};
YUIClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function YUISub(name, age){
    this.constructor.superclass.constructor.call(this, name);
    this.age = age;
};
YAHOO.lang.extend(YUISub, YUIClass); 
YUISub.prototype.toString = function(){
    return this.constructor.superclass.toString.call(this) + ": " + this.age;
};
var me = new YUISub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

WebReflection Proposal

After an analysis like this one, how could I skip my "all the best from others without troubles" proposal?
These are my considerations:

The fastest way to use a parent method is an explicit call

The best way to perform above step is via a link able to remove explicit dependencies (read: MyParentClassName instead of this.constructor.superclass). In this way methods could be easily transported from a prototype to another one without problems (less memory usage and less code to maintain)

The this.parent() solution is the cleanest one and generally speaking more close to our concept of "Object Oriented JavaScript". It is portable, it is meaningful, it is shorter than an explicit call with or without a link but it is not that fast to execute.

Using best practices to cache all we need, create a quick wrapper, resolving hidden methods problems, will not bring us to native or YUI performances, but at least in a good scenario: fast enough to guarantee performances over code elegance and readability

So here we are with my proposal:

Concept: parent in prototype but changed runtime for hierarchy purpose only if necessary (read: only for overrides). This will allows us to call parent directly in the constructor, as example, so we won't have double calls for each instance. At the same time, this implementation lets us call explicitly a parent method from those whose were not inherited.

Troubles: performances are the best but still far from native one.


function WRClass(name){
    this.name = name;
};
WRClass.prototype.toString = function(){
    return this.name;
};
WRClass.prototype.toLocaleString = function(){
    return "locale: " + this.toString();
};
function WRSub(name, age){
    this.parent(name);
    this.age = age;
};
wr.extend(WRSub, WRClass, {
    toString:function(){
        return this.parent() + ": " + this.age;
    }
});
var me = new WRSub("Andrea", 30);
alert(me);                   // Andrea: 30
alert(me.toLocaleString());  // locale: Andrea: 30

// last, but not least
WRSub.prototype.explicitParentToString = function(){
    return this.parent.prototype.toString.call(this);
    // instead of
    return this.constructor.superclass.toString.call(this);
};
alert(me.explicitParentToString()); // Andrea

WebReflection proposed Extend

For future improvements/bugs fixes, please use this link.


var wr = {
    extend:function(parent, extend){
        /**
         * (C) Andrea Giamamrchi
         * Mit Style License
         */
        return function(self, Function, Object){
            var prototype = function(){
                this.prototype[key] = 
                    this.prototype.parent && typeof Object[key] == "function" && typeof this.prototype[key] == "function" ?
                        extend(Function, this.prototype[key], Object[key]) :
                        Object[key]
                ;
            };
            if(Object){
                parent.prototype = Function.prototype;
                self.prototype = new parent;
                self.prototype.constructor = self;
                self.prototype.parent = Function.prototype.parent ?
                    extend(Function, Function.prototype.parent, Function) : Function
            } else
                Object = Function;
            for(var key in Object)
                prototype.call(self);
            for(key in {toString:key})
                return self;
            //* ... for Internet Explorer only ...
            for(var
                split = "hasOwnProperty.isPrototypeOf.propertyIsEnumerable.toLocaleString.toString.valueOf".split(".");
                key = split.shift();
            )
                if(Object.hasOwnProperty(key))
                    prototype.call(self);
            //*/
            return self
        }
    }(
        function(){},
        function(parent, extend, Function){
            return function(){
                this.parent = extend;
                var result = Function.apply(this, arguments);
                this.parent = parent;
                return result
            }
        }
    )
};

The Benchmark

I had to choose Prototype or MooTools, since these frameworks seem to have some problem to coexist. Since Prototype has been tested in the Ajaxian post, I decided to put MooTools in the middle.
Something to consider before you try the benchmark page ... I removed the purposeless direct method call since it is absolutely the same for every basic class, created via library or not.
The order is by performances, where generally speaking are these:

Ad Hoc Manual Explicit Inheritance

YUI lang.extend (close to Ad Hoc)

wr.extend - WebReflection proposal (closer to jClass than YUI)

jClass (truly close to base2)

base2 (truly close to jClass)

dojo

Prototype

MooTools

Try out The Benchmark

And have a nice week end ;-)

modisposition