The Setup

To do some benchmarking I downloaded the “mootools-developed” Slickspeed PHP framework from it’s Google Code hosted location, along with XAMPP to serve up the PHP pages required for the tests.

Hardware

• 2007 Compac nc8430
• Intel Dual-Core T2500 @ 2.00GHz
• 1.00 GB RAM

Software

• MS Windows XP Professional SP 2
• XAMPP 1.6.7
• Slickspeed (svn trunk version)

Browsers

• Safari 3.1.1
• Opera 9.5.2
• Firefox 3.0.1
• Internet Explorer 7.0.5730
• Chrome 0.2.149.27

JavaScript Libraries

• Mootools 1.2
• jQuery 1.2.6
• Prototype 1.6.0.2

I only downloaded 3 JS libraries because I thought that was enough to tell the difference between the browsers; this isn’t meant as an exercise at “who has the fastest JS library”.

To generate the results I installed XAMPP, installed slickspeed and set it up with the 3 JS libraries; then I opened each browser one at a time and ran the local copy of the slickspeed test:

This test runs 40 different CSS selector tests with whatever JS libraries you have configured atainst this W3C document. Each test is run separately in separate IFRAME tags as not to interfere with one another and report false data.

Data Collection

Data was collected by running the above slickspeed setup 10 times for each browser. After each time the test was ran, I recorded the final time for that browser.

** I used the final time in the slickspeed test because I was testing for the overall effectiveness & speed of the browsers. If you want to see how it performs on a per test basis, run it yourself!

The Results

Mootools 1.2 Results

Mootools used to be my favorite JS library. It has some cool features that make it pretty nice (like a stab at code organization using the Class object).

Safari operated the best with the Mootools library. Opera started out as a good candidate; however, the longer you kept open the browser and the more times you ran the test, the worse the response time got. Opera will show the same results for other libraries as well.

IE sucks, Firefox is good, Chrome is pretty darn good.

JQuery 1.2.6 Results

What is up Opera? You leaking stuff? No JS garbage collection? I did “hard” refreshes so the caches would be expunged; I just don’t get it.

Chrome and Safari FTW. IE bad, bad, bad.

Prototype 1.6.0.2 Results

Prototype made IE 7 look like the biggest piece of junk in the world; I have since then see the same results in YUI.  The IE results are an order of magnitude greater than the speeds of any of the other browsers combined. Keep in mind that less is better.

This was an extremely disappointing test; moreover, Opera still showed signs of memory leaks and slowly increasing final result times.

Chrome wins this battle; Safari a close second, and almost every other browser is not far behind. Yuck IE!

Final Results

So now we decided to take the average of all 10 tests and put it onto one chart so you can see the important stuff all summed up.

Final result conclusions…

• Chrome did very well considering it’s a partial mesh of Safari and Firefox components.
• Safari on a local copy of slickspeed did surprisingly very well.
• Opera is okay if you view a web page and then restart the browser. Otherwise, JS applications become slower and slower.
• IE needs a lot of work (but who didn’t know that already)

However, not only are there many ways to solve the same problem, but everyone that tries to solve that same problem produces JavaScript code that is so radically different from any previous attempt at the problem that it makes these problems seem more difficult than they really are.

What do you mean?

After poking around with raw JavaScript enough and looking at other people’s raw JS code, I can see that not many people have any clue what the best-practices and coding styles are.  This means that a huge percentage of the JavaScript code out there is just a bunch of hack.

Hack? Who said anything about hacking?

Not “hacking”, silly…

In modern computer programming, a “hack” can refer to a solution or method which functions correctly but which is “ugly” in its concept, which works outside the accepted structures and norms of the environment, or which is not easily extendable or maintainable (see kludge) — Wikipedia

If you come from a software development background, you know what hack code looks like and how fun it is to try and read it or learn anything of consequence from it. So?  So what? Read on.

The Root of the Problem

Why doesn’t this problem exist as much in languages like Java/C++ and other Object-Oriented languages. Well I think that it’s due to the nature of the JavaScript language; it’s inheritance pattern is prototypal and not object based.

As we said in another article ‘JavaScript Is Not “Truly” Object Oriented‘, the difference between prototypal and object-based inheritance is the same difference between a “HAS-A” relationship versus a “IS-A” relationship.

Anyways, since there are no definitive classes, there is way less enforced structure on coding styles and conventions; there is a reason for this though, keep in mind that JavaScript is a scripting language!

Yeah, we all know that when the JavaScript language was developed they might not have expected it to be used so much; however, in today’s world, JS is used very heavily.  Many applications are written entirely in JS!

Wouldn’t it be nice if a newer version of JS supported classes? It would give programmers a way to funnel their JavaScript coding styles! However, crap-in always equals crap-out.

JavaScript Libraries – A Partial Remedy

Thank God that someone had an idea a while ago to make a sensible collection of JavaScript code into what we now know as today’s Javascript Libraries and Frameworks!

This helped out somewhat. People started to use these libraries to un-compicate their coding lives by not worrying about browser differences or making ugly calls on the ‘document‘ object to manipulate and query the DOM.

Libraries like GWT, YUI, Mootools, JQuery, Dojo, Prototype, and any of the other tons of JS libraries out there do different things to make your coding lives easier and more readable. Google Web Toolkit (GWT) is a java based HTML/JS generator where you write all of your interface code in Java using AWT and Swing-like coding convention; mootools has a simplified “Class” object that you can “extend”.

Quit Complaining if You Don’t Have a Solution

Ok so my proposed solution is for everyone that’s not using a JS framework or the framework doesn’t support some type of code organization to use the Douglas Crockford’s JavaScript Module Pattern. It gives you a way to organize your code into something that may make a little more sense.

NO… IT’S… NOT!

If anyone else tries to tell you that, you need to slap them! It has object-oriented like features but it is not object-oriented in nature!

Prove it!

Classical definitions for object-oriented programming languages usually talk about two main features that make a language object-oriented:

1) Encapsulation

In computer science, the principle of information hiding [aka encapsulation] is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). — WIkipedia

JavaScript does not support information hiding.  There are neither “true” private nor protected members/methods. Everything is public!

If I create an “Object” in JavaScript, any properties I put in that object can be accessed and modified by anyone who has a handle on that object!

2) Polymorphic Inheritance

More precisely, polymorphism (object-oriented programming theory) is the ability of objectstypes to respond to method calls of the same name, each one according to an appropriate type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, so this behavior can be implemented at run time (this is called belonging to different late binding or dynamic binding). — Wikipedia

Polymorphic inheritance is the main driving reason that gives Java and C++/C# its user base.  It allows for an easy way for code reuse and object generalization. From the sub-class, you can access members and methods of the super-class; JavaScript can’t do this.

The reason for this is explained by the differences between HAS-A and IS-A object relationships

IS-A relationships contain a hierarchy of objects where any sub-class of an object IS also a type of the super-class!

When ObjectB extends another ObjectA, the type of the ObjectB is both ObjectB and ObjectA! That way I can make other objects that pass around ObjectA’s which may or may not be my ObjectB!

Think of the classical Shape example. There are a bunch of shapes out there and they all share some properties, but they do have many different properties that they don’t share. Well why not put the shared properties into a super-class and have shapes sub-class them.

// Shape base Object
public class Shape {
    protected String name = "Shape";
    protected int sides = 0;

    public String toString() {
        return this.name + " (" + this.sides + " sides)";
    }
}

public class Square extends Shape {
    public Square() {
        this.name = "Square";
        this.sides = 4;
    }

    public String toString() {
        return "It's hip to be a " + super.toString();
    }
}

public class Driver {
    public static void main( String [] args ) {
        Shape myShape = new Square();
        System.out.println( myShape );
    }
}

In the above example we can create a Shape object (myShape) and set it to a new Square. Why does this work? IS-A relationships dictate that since Square extends Shape, Square must also be a Shape. Therefore, we can store sub-classes of Shape into a Shape object reference and it will work fine.

Moreover, when the toString() method is called on myShape, dynamic binding helps to correctly call the Square.toString() method instead of Shape.toString()!

HAS-A relationships exists via a form of object composition (where 1 object contains another object and uses it’s methods).

In JavaScript, “extending an object” (doesn’t really exist) means just appending the super-objects members and methods to the sub-object. It’s really not any more difficult than that; you can’t ask or test a JavaScript Object if it is both the super-object and sub-object types.

This is called prototypal inheritance.

// Shape base Object
var Shape = function() {
    this.name = "Shape";
    this.sides = 0;

    this.toString = function() {
        return this.name + " (" + this.sides + " sides)";
    };
};

var Square = function() {
    this.name = "Square";
    this.sides = 4;
};

// Starts the HAS-A relationship
Square.prototype = new Shape();

// Test new Square
alert( new Square() );

If you needed to access anything from the super-object, there is no way of doing that using JavaScript’s object model unless you followed object composition where Square carried around an instance of Shape.

Moreover there is no way create a Shape reference and have it stored as a Square as in the previous Java example because HAS-A relationships dictate that members and methods are only appended to sub-classes.

Why Did You Even Write This Article?

I am tired of people writing stuff in/about JavaScript and calling it Object Oriented without explaining the difference between true object-oriented languages and scripting languages like JavaScript.

OOP Developers trying to learn JavaScript need to understand the fundamental difference between Java and JavaScript (is-a vs. has-a); just because JavaScript has “Java” in the name doesn’t mean it’s anyway related to Java.