http://www.cinsoft.net/mylib-testspeed.html

It just flat-out murders the rest (even Dojo)  And yes, the test
functions are _very_ concise (even too concise).  And no, they aren't
even close to optimized.  They even use the (optional) OO interface.
So there's really nothing left to argue as My Library is somehow
(much) faster _and_ more concise.  Not to mention compatible with
virtually any agent, past, present or future.  ;)

So, what is it that caused whole armies of developers to write slow,
incompatible, brittle, browser sniffing BS for ten years?  Would be
too slow and/or bloated if they didn't take the "pragmatic" (read
idiotic) approach?  No doubt that everyone who listened to such
babbling got saddled with a lifetime installment plan of bad software
(now just upgrade to jQuery 1.6543 and everything just works again!)
and shelves lined with books describing just how awesome all of that
bad code really is.  Now we have proof that it isn't.  ;)

Nobody ever needed any of it.  In fact, they'd have been much better
off without it.  Any company serious about Ajax development could have
developed something like My Library years ago and saved all of the
time of dealing with constant (and virtually mandatory) jQuery
upgrades, incompatibilies, inefficiency, etc.  Not to mention all of
the time arguing if it was "better" than Prototype (or whatever).  How
stupid (and/or ignorant) would you have to be to waste time and money
training to use one of these ever-changing monstrosities?  Think how
many people need to be laid off now because all they know is jQuery
and Mootools.  ;)

As for companies that were not serious about browser scripting, they
should have left it alone.  The users would never have missed a thing
(many would have preferred their sites without all of the Ajax-y
"goodness").

And where is this ExtCore thing?  Nobody seems to have written a set
of tests for it.  I may have to do it myself as I've seen the code and
am sure it will be slow and incompatible.  Ext is another software
subscription service, except this one costs money AIUI.  There will be
a full review of Ext (and a warning to steer clear of course) on
cinsoft.net soon  Hard to believe people would buy into the idea of
paying a company to constantly fall flat on its face.  I guess they've
convinced whatever customers they have left at this point that they
really are working on Mission Impossible (should just be a few more
years!).  The various free libraries and frameworks have been feeding
the same line for years.

They are all working on some perfect solution to an impossible problem
and must continue working on it every day forever.  Please bear with
them and continually download their code to "keep up" with the
browsers.  Thing is, my scripts never fell behind, so I never knew
what they were going on about.  :)

By the time the collective library authors learn ES and browser
scripting, there won't be any market for their wares.  If that sounds
like an absurd situation, it is; but history has certainly seen
periods defined by absurdity and failure.  Come to think of it, these
things fit right into the first decade of this century.  ;)

I noticed a few problems with your tests.

1) You are comparing against older versions of some of the frameworks
which don't use querySelectorAll.
2) Your tests don't follow the standards of taskspeed. (You are
setting innerHTML properties instead of using the framework API where
available)
3) Your QSA adapter is too simple. QSA is buggy across almost all
browsers and you aren't addressing any of those issues.

        "make" : function(){
                var createAndAppend = API.createAndAppendElementWithAttributes;
                var body = API.getBodyElement();
                for (var i = 0; i < 250; i++) {
                        createAndAppend('ul', {'class':'fromcode', id:'setid' + i}, body,
document).innerHTML = '<li>one</li><li>two</li><li>three</li>';
                }
                return $('ul.fromcode').length;
        },

        "indexof" : function(){
                var target = API.getEBI('setid150'), index = 0;
                Q('ul').forEach(function() { index = this.indexOf(target); });
                return index;
        },

        "bind" : function(){
                return Q('ul > li').on('click', function(){}).length();
        },

        "attr" : function(){
                return Q('ul').map(function(el) { return el.id }).length;
        },

        "bindattr" : function(){
                var subscriber = function() {};
                return Q('ul > li').on('mouseover', subscriber).setAttribute('rel',
'touched').off('mouseover', subscriber).length();
        },

        "table": function(){
                var myTable = E(), myCell = E(), body = API.getBodyElement();
                for (var i = 0; i < 40; i++) {
                        myTable.loadHtml('<table class="madetable"><tbody><tr><td>first</
td></tr></tbody></table>').appendTo(body);
                        myCell.loadNew('td').insertBefore(myTable.descendants('td')[0]);
                }
                return $('tr td').length;
        },

        "addanchor" : function(){
                return Q('.fromcode > li').forEach(function(li){
                        li.innerHTML = '<a href="http://example.com">link</a>';
                }).length();
        },

        "append" : function(){
                var div, createAndAppend = API.createAndAppendElementWithAttributes,
doc = global.document, body = doc.body;
                for (var i = 500; i--;) {
                        createAndAppend('div', { 'rel':'foo2' }, body, doc);
                }
                return $("div[rel^=foo2]").length;
        },

        "addclass-odd" : function(){
                return Q('div').addClass('added').filter(function(el, i) {
                        return (i % 2);
                }).addClass('odd').length();
        },

        "style": function(){
                return Q('.added').setStyles({
                        backgroundColor:'#ededed',
                        color: '#fff'
                }).length();
        },

        "removeclass": function(){
                return Q('.added').removeClass('added').length();
        },

        "sethtml": function(){
                return Q('div').forEach(function(el) {
                        el.innerHTML = "<p>new content</p>";
                }).load('div').length();
        },

        "insertbefore" : function(){
                var myEl = E();
                return Q('.fromcode a').forEach(function(a) {
                        myEl.loadNew('p').setText('A Link').insertBefore(a);
                }).length();
        },

        "insertafter" : function(){
                var myEl = E();
                return Q('.fromcode a').forEach(function(a) {
                        myEl.loadNew('p').setText('A Link').insertAfter(a);
                }).length();
        },

        "destroy": function(){
                return Q('.fromcode').remove().length();
        },

        "finale": function(){
                API.emptyNode(API.getBodyElement());
                return $('body *').length;
        }

I started to redo the last few that actually do touch the innerHTML
property.  Like this:-

        "make" : function(){
                var myEl = E(), body = API.getBodyElement();
                for (var i = 0; i < 250; i++) {
                        myEl.loadNew('ul', {'class':'fromcode', id:'setid' + i}).setHtml
('<li>one</li><li>two</li><li>three</li>').appendTo(body);
                }
                return $('ul.fromcode').length;
        },

...which is slightly slower.  But nothing can bridge the exponential
gap between My Library and the rest.  ;)

There's only two other tests that use any DOM property (e.g.
innerHTML).  Both are near identical:-

        "sethtml": function(){
                return Q('div').forEach(function(el) {
                        el.innerHTML = "<p>new content</p>";
                }).load('div').length();
        },

        "addanchor" : function(){
                return Q('.fromcode > li').forEach(function(li){
                        li.innerHTML = '<a href="http://example.com">link</a>';
                }).length();
        },

Solution is obvious:-

"sethtml": function(){
                return Q('div').setHtml('<p>new content</p>').load('div').length();
        },

Six of one, half a dozen of the other.  Might slow it down a hair, but
then changing to use DOM appends might speed it back up.  Who knows?
It won't make the others any faster, that's for sure.  And yes,
several of them use "cheating" like innerHTML as well:-

        "make" : function(){
                var ul;
                for ( var i = 0; i < 250; i++ ) {
                        ul = document.createElement('ul');
                        YAHOO.util.Dom.addClass(ul, 'fromcode');
                        YAHOO.util.Dom.setAttribute(ul, 'id', 'setid'+i);
                        document.body.appendChild(ul);
                        ul.innerHTML = '<li>one</li><li>two</li><li>three</li>';
                }
                return YAHOO.util.Selector.query('ul.fromcode').length;
        },

:)

Taskspeed is standardized by Peter Higgins, he ensures that no one lib
is taking shortcuts or misrepresenting their framework.
If you really want your Taskspeed tests considered lagit, fork his,
add it, and send him a pull request.
If you take issue with one or more of the tests you can correct it and
send him a pull request.

Please correct me if I am wrong on this.
When I or others find flaws in your work it's not a knock against you
or your framework in fact you did it, whatever the flaw is, by design.
On the other hand when you find faults in others code/frameworks/
libraries they are labeled incompetent.

As for unit tests (massive fails):

(failing Prototype tests)
http://dl.dropbox.com/u/513327/mylib/test/prototype.html

(failing jQuery tests, commented out the jq custom selector tests)
http://dl.dropbox.com/u/513327/mylib/test/jquery1.html
http://dl.dropbox.com/u/513327/mylib/test/jquery2.html (wont even run
the tests some bug in mylib)

(failing Dojo, Yahoo, Closure, and other tests)
http://dl.dropbox.com/u/513327/mylib/test/slick.html

(simple Slickspeed that works with your limited set of selectors
showing it as one of the slowest)
http://dl.dropbox.com/u/513327/mylib/slickspeed/index.html

While My Library here performs well, it's far from murdering the
competition.

My tests are at:

    http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a/

My results are here:

    http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a/results/

I will duplicate those results as an ASCII table below.

Among the seven libraries tested, my results rank My Library as second
fastest in Chrome, third in Firefox, fourth in IE, second in Opera,
and first in Safari (here beating even the "Pure DOM" solution by over
30%!)  These are good results, no doubt, but not a runaway win.  If
any library can claim to be fastest from my tests, it's definitely
qooxdoo, which was the fastest in four of the five browsers, and
outperformed the "Pure Dom" tests in three of them.

I first tried testing against a version of My Library that I
downloaded January 22.  Many of the tests failed.  Has the API changed
so drastically in the last few days?

  -- Scott

Results (ASCII table, useful mainly with fixed-width font)
==========================================================

Browsers:
---------
Chrome 3.0.195.27
Firefox 3.5.7
IE 8
Opera 9.64
Safari 4.0.3

1. Rushing to put QSA on top of broken, inconsistent DOM traversal is
STUPID.
2. That's what they all did.

Mine is an add-on and it really isn't needed at all (as the original
tests showed).  It helps to sway the deluded though (other than the
irretrievably stupid ones).

And none of it is complicated (*= and |= are as simple as ^= and the
like).  Sorry.  The whole selector engine is like a homework
assignment for a first-year CS student.  If a million monkeys can't
get it right after years of pounding on their keyboards and peering at
unit tests (and nobody really needs it anyway)...  well, you figure it
out.

1. Much faster
2. Compatibility with more than just the lastest browsers  :)
3. Comparitively smaller
4. No dubious plug-ins to download (and download and download...)

5. Last (but hardly least), not full of browser sniffs and other
incompetent nonsense (see jQuery discussions going back for years).

But, lets break the results down.  Chrome is really a photo finish
between Qooxdoo and My Library (7ms difference).  So call that a tie
for first.  On slower machines, phones, etc. My Library kills ooxdoo
(how do you even pronounce that?)  Same in newest FF (looks like a
three-way tie).  On older FF's, My Library is exponentially faster
than all of them.  Looking ahead, there's really not much to recommend
any of the (buggy as hell) others over My Library.  They'd have to
demonstrate massive speed advantages to overcome all of the other
inherent objections.  ;)

 If

The test indexOf is documented like this:

    "indexof" : function(){
        // in a 20-iteration for loop:
        //     find the node with id="setid150"
        //     find all the ul's in the DOM
        //     locate the index of the found node in the list of nodes
        // return that index
    }

but your implementation (as of a few minutes ago, at least, skips the
20-iteration loop:

    "indexof" : function(){
        var target = API.getEBI('setid150'), index = 0;
        Q('ul').forEach(function() { index = this.indexOf(target); });
        return index;
    },

I can't imagine it make too much of a difference in the overall
results, but it's probably worth fixing sooner rather than later.

Thanks for noticing that.

JFTR, these are the tests as of thirty seconds ago:-

        "make" : function(){
                var myEl = E(), body = API.getBodyElement();
                for (var i = 0; i < 250; i++) {
                        myEl.loadNew('ul', {'class':'fromcode', id:'setid' + i}).setHtml
('<li>one</li><li>two</li><li>three</li>').appendTo(body);
                }
                return $('ul.fromcode').length;
        },

        "indexof" : function(){
                var target = API.getEBI('setid150'), index = 0;
                Q('ul').forEach(function() { index = this.indexOf(target); });
                return index;
        },

        "bind" : function(){
                return Q('ul > li').on('click', function(){}).length();
        },

        "attr" : function(){
                return Q('ul').map(function(el) { return el.id; }).length;
        },

        "bindattr" : function(){
                var subscriber = function() {};
                return Q('ul > li').on('mouseover', subscriber).setAttribute('rel',
'touched').off('mouseover', subscriber).length();
        },

        "table": function(){
                var myTable = E(), myCell = E(), body = API.getBodyElement();
                for (var i = 0; i < 40; i++) {
                        myTable.loadHtml('<table class="madetable"><tbody><tr><td>first</
td></tr></tbody></table>').appendTo(body);
                        myCell.loadNew('td').insertBefore(myTable.descendants('td')[0]);
                }
                return $('tr td').length;
        },

        "addanchor" : function(){
                var myEl = E();
                return Q('.fromcode > li').forEach(function(li){
                        myEl.loadNew('a', { href:"http://example.com" }).appendTo(li);
                }).length();
        },

        "append" : function(){
                var myEl = E(), body = document.body;
                for (var i = 500; i--;) {
                        myEl.loadNew('div', { 'rel':'foo2' }).appendTo(body);
                }
                return $("div[rel^=foo2]").length;
        },

        "addclass-odd" : function(){
                return Q('div').addClass('added').filter(function(el, i) {
                        return (i % 2);
                }).addClass('odd').length();
        },

        "style": function(){
                return Q('.added').setStyles({
                        backgroundColor:'#ededed',
                        color: '#fff'
                }).length();
        },

        "removeclass": function(){
                return Q('.added').removeClass('added').length();
        },

        "sethtml": function(){
                var myEl = E();
                return Q('div').setText('').forEach(function(el) {
                        myEl.loadNew('p').setText('New content').appendTo(el);
                }).load('div').length();
        },

        "insertbefore" : function(){
                var myEl = E();
                return Q('.fromcode a').forEach(function(a) {
                        myEl.loadNew('p').setText('A Link').insertBefore(a);
                }).length();
        },

        "insertafter" : function(){
                var myEl = E();
                return Q('.fromcode a').forEach(function(a) {
                        myEl.loadNew('p').setText('A Link').insertAfter(a);
                }).length();
        },

        "destroy": function(){
                return Q('.fromcode').remove().length();
        },

        "finale": function(){
                return E(API.getBodyElement()).empty().descendants().length;
        }

They are slowing down a bit as I condense the last few bits, but still
nowhere near a horse race in anything I've tested so far.  Nothing has
changed radically from the results I posted to the forum yesterday.

BTW, these tests are all apples and oranges.   Qooxdoo and YUI (and
probably others) use native DOM methods.  My original tests used a lot
of them too, but I weeded them out as I knew people would consider
that "cheating".

And Qooxdoo is nothing but a dated browser sniffing repository (who is
going to go back and rewrite all of that crap?) and crashes older
browsers to boot (e.g. Opera 7, FF1).  Realize that browser sniffing
can give the illusion of efficiency, but as time passes, it crumbles
away without constant maintenance.  It's completely baseless and
inaccurate too, but that's another story.

Specs : Mac OS X 10.5.8 / 1.8 GHz ppc G5 / 3 Gb RAM

TaskSpeed @ http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a
---------------------+--------------+-------------+--------------
                      | Safari 4.0.4 | Opera 10.10 | Firefox 3.5.6
---------------------+--------------+-------------+--------------
PureDom*             |         1143 |        3153 | 1        1628
Dojo 1.4.0           | 3        761 | 3      2277 |          2654
jQuery 1.4.0         |         1934 |        5847 |          2793
MooTools 1.2.4       |          835 |        5809 |          4580
Prototype 1.6.0.3    |         1192 |        9485 |          5247
qooxdoo 0.8.2        | 2        666 | 2      1666 | 3        2190
YUI 2.7.0            |         1341 |        5322 |          3888
My Library (QSA Min) | 1        650 | 1      1435 | 2        2146

TaskSpeed @ http://www.cinsoft.net/taskspeed.html
---------------------+--------------+-------------+--------------
                      | Safari 4.0.4 | Opera 10.10 | Firefox 3.5.6
---------------------+--------------+-------------+--------------
PureDom*             |         1257 |        3918 | 1        3012
jQuery 1.2.6         |         5672 |       22390 |         17130
jQuery 1.3.2         |         3655 |       12422 |         14107
Prototype 1.6.0.3    |         1237 |       10553 |         10287
MooTools 1.2.2       |         1268 |        4792 |          7636
qooxdoo 0.8.2        | 3       1009 | 1      1941 | 2        3556
Dojo 1.3.2           |         1090 | 2      2358 |          4629
Dojo 1.4.0           | 2        962 | 3      2445 |          5354
YUI 2.7.0            |         1196 |        7962 |          6835
YUI 3.0              |         1215 |        2749 |          4465
My Library 1.0       | 1        581 |        5062 | 3        4315

What I see here :
(on topic)
My Library, Dojo and Qooxdoo are the fastest libs on this machine.
jQuery and Prototype are the slowest on this machine.
(off topic)
I never liked Firefox on Mac. Now, I think I know why.

If you haven't guessed, there are lots more rows on the way for the
selectors tests that will demonstrate how ridiculously broken all of
these "major" frameworks are.  They've been selling everybody on
"browser scripting too hard" for too long.  It's bullshit.  They are
incompetent to do the task(s) they set out to do.  Cross-browser
scripting does not mean rewriting the same bullshit every month.  ;)

As I've mentioned repeatedly (here) the IE attribute workarounds are
ugly in places (and that's one of them).  And if you use the higher-
level wrappers (e.g. createElementWithAttributes), you avoid those
questions as type and name are automatically set first and second
respectively.

There's nothing suspect about any of it.  In fact, it is more relevant
to test the "slow lanes" as everything is about the same with QSA.
Get that?

Library             Fx      IE 6
PureDom*            794    3,031
jQuery 1.2.6      5,830   36,326
jQuery 1.3.2      3,763   11,826
Prototype 1.6.0.3 2,879   37,185
MooTools 1.2.2    2,306   20,358
qooxdoo 0.8.2     1,051    4,062
Dojo 1.3.2        1,218    9,110
Dojo 1.4.0        1,198    5,125
YUI 2.7.0         2,300    7,063
YUI 3.0           1,062    3,954
My Library 1.0    1,371    5,625

In Firefox My Library is beaten by YUI 3.0 and Dojo versions 1.4 and
1.3.2. In IE 6, it is beaten by YUI 3.0, Dojo 1.4 and qooxdoo.
Prototype failed the insertAfter test in both Firefox and IE 6,

The test code itself is not as concise as that for jQuery, and not
much more concise than most of the others. Prototype and MooTools are
perhaps the least concise, the total code for the "pure DOM" is 10KB.

But the test code is tiny in comparison to the library itself, so not
really a huge concern.

Library          Fx 3.6     IE 8  Op 10.10  Safari 4.04

PureDom             282    1,211       190          246
jQuery 1.2.6      1,692    6,269     1,904        1,188
jQuery 1.3.2      1,401    3,219       956          708
Prototype 1.6.0.3   889    3,790       830          385
MooTools 1.2.2      733    5,711       451          276
qooxdoo 0.8.2       405    1,383       180          208
Dojo 1.3.2          435    2,104       217          271
Dojo 1.4.0          448    1,771       266          245
YUI 2.7.0           788    2,370       517          286
YUI 3.0             440    1,531       252          255
My Library 1.0      448    1,757       222          168

I'm not sure how myLib can be faster than pure dom???

| The 'PureDom' tests are written as a minimal abstract utility
| API to accomplish these tasks, and are included as a baseline
| measurement of the compared libraries. It currently is not  a
| library available for download or use.

That does not mean that you can't see it.  It's simply meant to be an
efficient, library-agnostic bit of code.  It is included with the
tests, but it's not available as a stand-alone library in the manner
that Dojo, jQuery, MooTools, My Library, Prototype, qooxdoo, and YUI
are.

The test code is available at

    http://dante.dojotoolkit.org/taskspeed/tests/pure-tests.js

and the minimal library used is at

    http://dante.dojotoolkit.org/taskspeed/frameworks/webreflection.js

The test code looks like you would expect, with pure DOM code like
this:

    (node = a[j]).parentNode.insertBefore(
        p.cloneNode(true).appendChild(text.cloneNode(true))
        .parentNode, node.nextSibling
    );

The library contains a utility object consisting of four functions:
attachEvent, detachEvent, (Array) indexOf, and a small replacement for
or wrapper around querySelectorAll.  Actually, that last looks a
little strange to me:

    getSimple:document.createElement("p").querySelectorAll&&false?
        function(selector){
            return this.querySelectorAll(selector);
        }:
        function(selector){
            // lightweight implementation here
        }

Am I crazy or does that "&& false" mean that the first branch will
never be chosen?  Perhaps that's the culprit?

The same slow logic is used in the make function (my wrapping):

    "make": function(){
        for(var
            d   = document, body = d.body,
            ul  = d.createElement("ul"),
            one  = d.createElement("li")
                                .appendChild(d.createTextNode("one"))
                                        .parentNode,
            two  = d.createElement("li")
                                .appendChild(d.createTextNode("two"))
                                        .parentNode,
            three= d.createElement("li")
                                .appendChild(d.createTextNode("three"))
                                        .parentNode,
            i   = 0,
            fromcode;
            i < 250; ++i
        ){
            fromcode    = ul.cloneNode(true);
            fromcode.id = "setid" + i;
            fromcode.className = "fromcode";
            fromcode.appendChild(one.cloneNode(true));
            fromcode.appendChild(two.cloneNode(true));
            fromcode.appendChild(three.cloneNode(true));
            body.appendChild(fromcode);
        };
        return  utility.getSimple
                        .call(body, "ul.fromcode").length;
    },

Note the repetitious clone/append/step-up where a single clone would
have done the job - compare it to the jQuery code used:

  $("<ul class='fromcode'><li>one</li><li>two</li><li>three</li></
ul>")

Here all elements are created in one go, so the two are hardly
comparible. The DOM code is doing 4 times the work (but still runs in
half the time of jQuery 1.4). Optimising out the extra work and it
runs about 15% faster in Firefox, and twice as fast in IE 6.

Note also that a selector is used to count the nodes added to the
document at the end and that the speed of this count is included in
the test. Why is selector speed allowed to influence tests of element
creation speed?

  1. ul.fromcode
  2. div.added

A simple switch statement would have done the trick. The "pure DOM"
code doesn't leverage the browser-native getElementsByClassName method
if available, a for loop and RegExp is used always. Nor does it
leverage the fact that DOM collections are live, it gets the
collection every time. This is critical as a selector query is
included in nearly all the tests, so its performance affects tests
where it is not the feature being tested.

There are a number of optimisations that could quite easily be added
to "pure DOM", and the tests themselves do not accurately target the
features they are trying to test in some (many?) cases.