I grabbed the latest of the main libraries: ExtCore (beta1), JQuery 1.3.2, Dojo Core 1.3.0, Prototype 1.6.0.3 and the Sizzle engine by itself. I ran Sizzle by itself because although JQuery uses Sizzle, the version of Sizzle in JQuery 1.3.2 is 0.93 while the current version on the Sizzle website is version 1.0. I used the latest version of Slickspeed and made three runs in IE8, Firefox 3.0.8 and Chrome 1.0.154.3. Yes, I disabled Firebug in Firefox. My dev desktop is a rather beefy Windows Vista 64-bit machine with a quad-core 2.66ghz CPU and 8GB of RAM. I did a complete page refresh between runs to start relatively clean. I was going to relaunch the browser between runs, but it ended up not making much of a difference.

First up was the latest and greatest from Microsoft, Internet Explorer 8.

• Prototype: 440ms
• Dojo: 61ms
• JQuery: 48ms
• ExtCore: 80ms
• Sizzle: 46ms

The image shows the results from the last run. I was actually surprised that IE8 did reasonably well. One thing is clear, friends don’t let friends use Prototype with Internet Explorer.

Firefox was a slightly different story. The selector engine in Prototype still got its clock cleaned, and ExtCore swapped around with JQuery and Sizzle:

• Prototype: 145ms
• Dojo: 64ms
• JQuery: 77ms
• ExtCore: 49ms
• Sizzle: 71ms

It was interesting both Sizzle implementations slow down in Firefox. I would wager that the Sizzle folks made a conscious decision to optimize the core selector engine for the most widely used browser (Internet Explorer). ExtCore leaps ahead with Firefox 3, while Dojo is still pretty consistently finishing in the middle. Oh, and friends don’t let friends use Prototype with Firefox either.

Chrome is an absolutely game-changing stunner of a browser. Based on the selector benchmarks, the developers for all these engines should be offering to have children for the Chrome developers:

• Prototype: 13ms
• Dojo: 7ms
• JQuery: 8ms
• ExtCore: 13ms
• Sizzle: 8ms

Even lowly Prototype with Chrome makes any of the other libraries running in Firefox look like they’re standing still. Chrome is simply ungodly fast with all them. ExtCore could probably still use some tweaking, but we’re talking about a 7ms delta between the fastest and slowest.

So the Ext team’s claims for Sizzle being slower are only partially true. Sizzle appears to be faster in Internet Explorer, while the story flips around in Firefox where ExtCore is faster. All of them, even Prototype, are fast in Chrome. Pray for the day when Chrome takes over the world. Until that time, It looks like all them (Dojo, JQuery/Sizzle, ExtCore) are good in IE and Firefox, with the nod going to JQuery/Sizzle for Internet Explorer, the browser market share leader. And you really, really don’t want to use Prototype until all your clients have moved to a modern browser with native selector engines, or Chrome.

One glaring omission is that I didn’t test with IE7 or IE6. Using either of those browsers is also on my “friends don’t let friends…” list. It would be safe to say that they would both be slower. As I don’t have either installed on any of my computers, I would be happy to add an update for anyone who wants to run the tests themselves.

The Ext team earns some slack in their Internet Explorer performance as they are only a beta compared to the others. I’ll rerun the test again when ExtCore goes GA. And on a final note, here is the config.ini file for Slickspeed in case anyone wants to try the benchmark themselves, or you can grab the whole Slickspeed install with the selector engines configured.

In this post, I want to get in to demonstrating some of the features of Ext Core that are either coded differently from JQuery or that the base JQuery library does not implement. The excellent Ext.Core manual has more detail on all the functions, so I’ll just bring attention to some of cool functionality I like.

Base Class Enhancements

One feature that might be controversial for some developers is that Ext Core augments some of the base JavaScript objects to ensure some features are present across implementations and to add some useful helper methods. The JavaScript Augmentation section of the manual has details on all the enhanced methods. Function, Array and String are the three base objects that get augmented.

For example, the String object is augmented with a static format() method that essentially allows the String to function like a typical printf function:

var dest = 'World';
var greeting = 'Hello';
var msg = String.format('{0}, {1}!',greeting, dest);
// msg contains "Hello, World!"

The Array object is augmented with indexOf() and remove() methods, and the Function object itself picks up several OO-centric functions.

The reasoning behind the augmentations are in the manual. I have mixed feelings on augmenting the language’s base objects, but the features are appreciated.

Namespaces

Using a namespace mechanism so that all your variables don’t pollute the global namespace is something every JavaScript coder should be doing. There are plenty of code snippets out there to demonstrate how this is done, but Ext Core makes it easy for you by including namespace support as a part of the library. All this is handled through the Ext.namespace() static method.

Take a look at the sample below. The comments indicate the filenames:

// first.js
Ext.namespace('First');
First.name = 'Tim';
 
// second.js
Ext.namespace('Second');
Second.sayHello = function(name) {
    alert( String.format('Hello, {0}',name) );
};
 
// main.js
Ext.onReady(function() {
	Second.sayHello( First.name );
});

The three JavaScript files don’t even need to be imported in this order. Everything happens through the namespace references declared at the tops of the files and managed by Ext Core. In this case, objects called First and Second were created under window, and the sayHello method and ‘name’ variable were placed under them. This means our code only added two variables to the global space. This didn’t make a difference with only two variable declarations, but can have a huge impact with a typical application.

Namespaces can be hierarchical, so you can limit the global pollution to a single entry. For example, you can define a namespace like this:

Ext.namespace('Application.Init');

Ext Core will create all the intermediate namespaces, so you could places variables under both Application.Init and Application with this single declaration. This provides a similar naming hierarchy to what you would find in Java packages or C# namespaces.

Encode and Decode

Ext Core provides helper methods to encode and decode both JSON and URL-encoded data. The Ext.encode and Ext.decode will encode or decode JSON objects to and from Strings. This is useful for the AJAX methods, as I demonstrated in my other post. In the current beta, the encode and decode methods aren’t implemented yet, but they are in the documentation, so I’m expecting to see them before the final release.

The Ext.urlEncode and Ext.urlDecode methods will encode or decode JSON objects to URL-encoded strings. One typical example is to decode query string parameters. For example, if the page URL was this: http://mycoolapp.com?name=Tim&lang=Java, you could easily decode the query string into a JSON object using this snippet:

var params = Ext.decode( document.location.search.substr(1) );
alert( String.format('Hello, {0}', params.name) );

Yes, this is a bit of a hack. I didn’t do error checking to ensure there was a value for search before using substr(). The substr() is necessary when working with a query string because the search value will start with a question mark (?), which the Ext.urlDecode method won’t strip off.

Templates

Ext Core thankfully includes Templates, a feature generously carried down from ExtJS. Templates simplify the repetitive generation of HTML fragments, which is something that typically happens in AJAX intensive web application. The Ext.Template class allows you to define an HTML fragment as a template, using tokens which will be replaced with the values from a JSON object. For example, here is a code sample of a Template used to format an RSS feed from Slashdot that I turned into a JSON object:

// Feed.data is an array of JSON objects that look like this:
// {title: 'title', link: 'link', description: 'description'}
 
var template = new Ext.Template(
            '<div class="story">',
            '<h3><a href="{link}">{title}</a></h3>',
            '{description}',
            '</div>');
 
// stories is the id of the empty div on the page
var stories = Ext.get('stories');
 
Ext.each(Feed.data, function(item) {
    template.append(stories, item);
});

This snippet also demonstrates the Ext.each() helper method for iterating over the contents of an array. You can download the full snippet here to play with.

As Ext Core is still in beta, there is a disconnect between the API documentation and the actual implementation. If the Ext.Template class is updated to correspond to the documentation, there are also some neat formatting effects that can be applied. For example, instead of the placeholder {description}, you could use {description:ellipsis(20)} which will truncate any string longer than 20 characters and place ellipsis at the end of the string.

I’ve covered a few of the cool features to make your JavaScript code easier and more maintainable. Ext Core also has some neat OO functionality that I’ll cover in another post.