Tag Archives: extcore

Looping Out

Yes, I confess, I follow @DHH on Twitter. He can be rather opinionated, but he has an interesting point of view on things. Plus, it is a good way to keep up on the thinking behind Ruby on Rails. Just this evening he put a shot across the bow of JQuery with this tweet:

Since JavaScript library performance is something that interests me, I took a look at the benchmark he linked to. It is a pretty straightforward test of JQuery’s each() method compared to a custom function called quickEach(). On my MBP, the results look like this:

First, kudos to jamespadolsey for coming up with this. The speed difference is pretty shocking. But even more interesting, the test harness is extensible, so I decided to see how the latest Ext-Core stacks up.

First, I had to tweak the setup code a bit. It was creating a JQuery object which wrapped an array:

var a = $('
').append(Array(100).join('')).find('a');

I kept it simple and turned this in to:

var a = $('
').append(Array(100).join('')).find('a'); var b = a.toArray();

This gave me a real JavaScript array to work with. Then, I added a new test case which looked this:

Ext.each(b, function(item) {
    Ext.get(item); // Ext.Element
});

Running the jsPerf test with this snippet gave these results:

My first reaction to this was along the lines of WTF! My faithful Ext-Core was getting its ass handed to it by JQuery. But then I spotted the error in my ways. Using Ext.get() is very expensive for operations where you plan on discarding the Ext.Element afterwards. It adds an id to the DOM element, then puts the wrapped DOM element into a cache to speed up subsequent operations. For cases like this, where we’re going to throw the Ext.Element away, the Ext.fly() method is what should be used.

Here are the results using Ext.fly() instead:

Now we’re talking! Using Ext.fly() gave some pretty good results, although there are probably some ideas to be borrowed from the hand-rolled JQuery quickEach() method.

Not being satisfied with a contrived example which was just discarding the wrapped DOM element, I then tweaked the test. I changed each of the test cases to add a class to the wrapped element inside the loops. For giggles, I added two additional tests. One using JQuery’s addClass() method against the set of elements, and one doing the same thing using Ext.select().

Here are the results:

Suddenly that speed difference in the first test cases starts to look a lot less significant when it actually comes time to do something in the loop. Adding the class to the DOM node wrapped in an Ext.Element using Ext-Core turns the first results upside-down.

Even more interesting was JQuery’s performance using addClass() on the JQuery element and not using the each iterator. It looks like JQuery is soundly implemented for set operations. So the lesson is treat JQuery more like SQL than code — if you’re trying to do each(), you might be thinking about the problem wrong.

I won’t even attempt to address the whole “beauty” angle. I’ve learned from the ExtJS-JQuery flame wars that beauty is definitely in the eye of the beholder. And if you want to dork with this yourselves, my playground is Revision 15.

Slick Speed

One of the big questions that people have had about ExtCore is why didn’t it make use of the Sizzle selector engine. That was one of the questions I wanted to get answered at the Ext Conference last week, and I managed to pin down one of the core developers to get an answer. Their opinion was that Sizzle is too large and too slow. I don’t really care about the size aspect. They all tend to pack down into the 25K range, but I was interested in the speed comment. Like a lot of folks, I was led to believe that Sizzle had a lot of, well, sizzle. So in the interest of getting to the bottom of the story, I did a little unscientific testing of my own using Slickspeed, which tests selector engine performance.

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

ie8

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

ff3

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

chrome

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.

Beyond the Core

In my earlier post, I compared the new Ext Core JavaScript library with JQuery to demonstrate how close they are on core functionality. I explicitly kept the scope narrowed down to areas where the two libraries overlapped, and my conclusion was that both are winners but I prefer Ext Core since I use ExtJS and prefer the coding style.

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(
            '
', '

{title}

', '{description}', '
'); // 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.