TaskSpeed results for My Library

[David Mark]

TaskSpeed is another quasi-standard test that has never seen anything
like My Library. It was written by one of the Dojo guys. Yeah, I
know.

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.

Oh, and I heard from Ajaxian (for those that care). They've decided
that since I said their site stinks (it does), they are not going to
report any news about My Library ever (picturing a child stamping
their feet). What a bunch of useless dip-shits. I bet they hang out
with JS library authors.

 

[jdalton]

Hi David,

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.

Your framework fails in multiple modules, multiple browsers, and
multiple versions of browsers.
Your CSS selector engine is incomplete, slow (compared to current
engines) and fails to pass some basic unit tests of other frameworks.
What I find interesting is without complete/comprehensive tests you
claim superiority, but on a quick review one would find that your code
fails to pass the standards by which you judge other developers/
frameworks.

 

[David Mark]

Hi David,

I noticed a few problems with your tests.

Oh good.

1) You are comparing against older versions of some of the frameworks
which don't use querySelectorAll.

And comparing without it as well. See previous discussions. I am all
for testing the "slow lanes" as they are more significant IMO.

2) Your tests don't follow the standards of taskspeed.

What standard is that?

(You are
setting innerHTML properties instead of using the framework API where
available)

I just put them up yesterday (and have been changing them to be more
OO to demonstrate how well those interfaces work). Here are the exact
tests that are up there now;-


"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;
},

3) Your QSA adapter is too simple. QSA is buggy across almost all
browsers and you aren't addressing any of those issues.

Well, it is only a day old. How much do you want to bet I can make it
bypass buggy selectors without resorting to browser sniffing and
without needlessly slowing down the "fast lane?" Who else is better
qualified to do that? And who told those other nimrods to dump QSA
into their core? It's a mistake.

Your framework fails in multiple modules, multiple browsers, and
multiple versions of browsers.

Care to elaborate on any of that? Sounds like the opposite of what
the documented testing has uncovered. And yes, automated unit testing
will follow. The difference is that I won't be surprised by wrong
results and I won't allow such results to shape my design.

Your CSS selector engine is incomplete, slow (compared to current
engines) and fails to pass some basic unit tests of other frameworks.

I never said it covered every selector. It is hardly slow (as the
tests have shown). I am sure it fails to pass unit tests involving
selectors it doesn't support. Read the instructions before testing.
It's faster than virtually everything on virtually everything. And so
what? I never told you to use a CSS selector query engine. It's just
stupid.

What I find interesting is without complete/comprehensive tests you
claim superiority, but on a quick review one would find that your code
fails to pass the standards by which you judge other developers/
frameworks.

No, you just have no idea what you are talking about. For instance,
there's a big difference between eschewing a few selector types (which
are documented) and completely failing to understand how - for example
- IE works (while releasing script after script claiming to solve it
for good!) If it's been ten years and you still read documents
(or measure elements) wrong in IE, you aren't qualified to solve cross-
browser problems for the rest of us.

The whole point is that you do not need an army of code monkeys
rewriting the same script, year after year, adding more bloat and
complexity, requiring re-testing, deprecating "old" browsers, etc.
It's been a complete waste of time as it lead up to a bunch of slow,
buggy "standard" renditions that are virtually unusable on the Web.

 

[David Mark]

Hi David,

Hi, "jdalton". I thought I recognized that moniker. Prototype
hawker, huh? That library should never have been written. It manages
to be the slowest (at virtually anything) while also throwing bizarre
exceptions in anything but the latest browsers (and some of the latest
too). And it isn't for real. It's just a collection of browser
observations made by people with no idea what they were observing. It
won't (doesn't) hold up. That's why a million monkeys keep churning
out new Prototypes. Stop and look at the design (from a neophyte in
2005) and realize it will never be competent.

Now, can you you accuse My Library of that?

 

[jdalton]

Hi David,

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

Well, it is only a day old.

You are promoting it as if its the best thing around (on twitter, your
google group, and clj)

How much do you want to bet I can make it bypass buggy selectors ...

Then you will join the rest who have without sniffing. I don't doubt
your ability.
Random thought, have you tried submitting bug reports against the
frameworks you flame ?

I never said it covered every selector.

Others cover more selectors/bugs which can add to complexity and drain
overall performance.

I never told you to use a CSS selector query engine.
It's just stupid.

You are the one showing Slickspeed results and promoting your
framework as faster/better.

Prototype hawker, huh?

I haven't contributed or endorsed Prototype for some time now.

 

[Scott Sauyet]

TaskSpeed is another quasi-standard test that has never seen anything
like My Library. It was written by one of the Dojo guys. Yeah, I
know.

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.

My results don't agree. I've posted another version, which restricts
the comparison to the latest versions of the libraries from your list,
upgrading to the latest version of jQuery and MooTools. (I couldn't
find test files for more recent versions of YUI or qooxdoo; the others
were already at the latest, I believe.) I ran the tests on a modern
Windows XP SP2 machine with dual 3.0GHz CPUs and 3.25 GB of RAM.

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

+--------+--------+--------+--------+--------+
| Chrome | Firefox| IE | Opera | Safari |
+-------------------+--------+--------+--------+--------+--------+
| Pure Dom | 206 | 290 | 906 | 219 | 224 |
+-------------------+--------+--------+--------+--------+--------+
| Dojo 1.4.0 | 225 | 428 | 2018 | 309 | 202 |
+-------------------+--------+--------+--------+--------+--------+
| jQuery 1.4.0 | 458 | 937 | 2922 | 484 | 388 |
+-------------------+--------+--------+--------+--------+--------+
| MooTools 1.2.4 | 304 | 851 | 5686 | 642 | 244 |
+-------------------+--------+--------+--------+--------+--------+
| Prototype 1.6.0.3 | 405 | 1105 | 4529 | 920 | 353 |
+-------------------+--------+--------+--------+--------+--------+
| qooxdoo 0.8.2 | 160 | 406 | 1593 | 217 | 218 |
+-------------------+--------+--------+--------+--------+--------+
| YUI 2.7.0 | 299 | 866 | 2172 | 439 | 317 |
+-------------------+--------+--------+--------+--------+--------+
| My Library (QSA) | 167 | 447 | 2642 | 269 | 155 |
+-------------------+--------+--------+--------+--------+--------+

 

[David Mark]

Hi David,

Taskspeed is standardized by Peter Higgins, he ensures that no one lib
is taking shortcuts or misrepresenting their framework.

Standardized is a strong word, but okay. What happened with - for
example - YUI's tests?

If you really want your Taskspeed tests considered lagit, fork his,

I downloaded his, so it would be lagit (sic).

add it, and send him a pull request.

A what request? Do you mean that thing that sends back results? It
doesn't work as it tries to download Dojo via a SCRIPT element, sets
onreadystatechange, and... oh never mind.

If you take issue with one or more of the tests you can correct it and
send him a pull request.

What does any of this mean? If I have an "issue" with the test, I
rewrite it. I just rewrote three of mine to remove the innerHTML
property access. Whatever. Still kills the rest (as you will see in
a moment).

Please correct me if I am wrong on this.

On what?

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.

You haven't found shit so far as I can see. You babbled a few
generalizations, but didn't really say anything specific about any of
them. See the My Library forum for lessons on how to test and report
(as well as how I react to such "criticism").

On the other hand when you find faults in others code/frameworks/
libraries they are labeled incompetent.

No, you are oversimplifying at best. They _are_ incompetent. I can
tell that from their _code_. I don't need to test any of their
bullshit at all. And when you are tearing up and rewriting browser
sniffs (and other misconceived code) every month to "keep" up with
some imagined opponent, you have to stop and think "I am incompetent",
right? If not, there's another word: insane.

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/myli...box.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


You are promoting it as if its the best thing around (on twitter, your
google group, and clj)

You really aren't paying attention are you.

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).

Then you will join the rest who have without sniffing.

Who would that be? If they used feature testing, where do you think
they _got_ those techniques.

I don't doubt
your ability.

That's nice.

Random thought, have you tried submitting bug reports against the
frameworks you flame ?

Random thought, there's no hope for them, regardless of how many times
they are patched. There's an incompetence-imposed ceiling. You do
realize I _rewrote_ Dojo/Dijit/DojoX in its _entirety_ at one point
(as well as gave Resig solutions to various problems that he still
hasn't solved). And I don't "flame" anybody. It's not my fault if
people are deluded, or overconfident or stupid or whatever. I just
bring these issues to light by reviewing their "work".

Others cover more selectors/bugs which can add to complexity and drain
overall performance.

Uh, no. You clearly don't understand how they work. The (4 or 5)
missing selectors are just extra switch cases. They won't add any
time to the other selectors. Nice try though.

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.

You are the one showing Slickspeed results and promoting your
framework as faster/better.

No, you've got this all screwed up. I put that page up there _two
years ago_. I've barely said a thing about it since. Then some other
guy came along (here) and asked about speed tests. I pointed him to
that page and he ran with it (straight into a brick wall I might
add). I certainly find the TaskSpeed results more interesting. But,
the thing is, I knew all along mine was faster at virtually everything
on virtually everything. I've seen the code.

I haven't contributed or endorsed Prototype for some time now.

LOL. Moved on to jQuery?

 

[David Mark]

Hi David,

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/myli...com/u/513327/mylib/test/jquery2.html(wonteven run
the tests some bug in mylib)

My Library won't run jQuery's unit tests and you consider this to be a
bug in My Library? Pardon me if I ignore the rest of your
reports.

(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

Why would you have to reproduce that page? There's already a page on
cinsoft.net that runs the "limited" (40 - 4 or so IIRC) selectors.
Any result that shows it as one of the "slowest" is clearly suspect.
I can tell you that without looking at any of your results (I've seen
all of the code).

 

[David Mark]

My results don't agree. I've posted another version, which restricts
the comparison to the latest versions of the libraries from your list,

My list?! It's the TaskSpeed suite downloaded from Higgins' site.

upgrading to the latest version of jQuery and MooTools. (I couldn't
find test files for more recent versions of YUI or qooxdoo; the others
were already at the latest, I believe.)

Great. I added YUI3 to mine. It's slower than the previous YUI (of
course).

I ran the tests on a modern
Windows XP SP2 machine with dual 3.0GHz CPUs and 3.25 GB of RAM.
Okay.


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

I'll be sure and run them through the gamut... And you have to look
at it as a whole (tested across a wide set of agents):-

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).

My tests are at:

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

I will definitely try them out. I assume you used the version with
the QSA add-on.

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.
Thanks!


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.

Well, they are just one set of results on one machine. We test lots
of machines and look at the aggregate picture, considering slower,
older and limited agents, as well as the current run-of-the-mill
Windows installation.

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

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.

You are putting way too much stock into one test run.

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?

Per user requests, I added some new selectors. I also added some new
syntactic sugar to the (optional) OO interface so that nobody would
cry foul about "cheating" with "pure" DOm methods. That's what you
are seeing. The core API is unmoved (most of it for years).

-- 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

+--------+--------+--------+--------+--------+
| Chrome | Firefox| IE | Opera | Safari |
+-------------------+--------+--------+--------+--------+--------+
| Pure Dom | 206 | 290 | 906 | 219 | 224 |
+-------------------+--------+--------+--------+--------+--------+
| Dojo 1.4.0 | 225 | 428 | 2018 | 309 | 202 |
+-------------------+--------+--------+--------+--------+--------+
| jQuery 1.4.0 | 458 | 937 | 2922 | 484 | 388 |
+-------------------+--------+--------+--------+--------+--------+
| MooTools 1.2.4 | 304 | 851 | 5686 | 642 | 244 |
+-------------------+--------+--------+--------+--------+--------+
| Prototype 1.6.0.3 | 405 | 1105 | 4529 | 920 | 353 |
+-------------------+--------+--------+--------+--------+--------+
| qooxdoo 0.8.2 | 160 | 406 | 1593 | 217 | 218 |
+-------------------+--------+--------+--------+--------+--------+
| YUI 2.7.0 | 299 | 866 | 2172 | 439 | 317 |
+-------------------+--------+--------+--------+--------+--------+
| My Library (QSA) | 167 | 447 | 2642 | 269 | 155 |
+-------------------+--------+--------+--------+--------+--------+

YUI 2.7? I thought you were using the latest stuff? See mine. I
just added YUI3 (waste of time though).

 

[Scott Sauyet]

TaskSpeed is another quasi-standard test that has never seen anything
like My Library.  

I think one of your tests is incomplete.

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.

-- Scott

 

[David Mark]

I think one of your tests is incomplete.

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 listof 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;
    },

Ah, I may have screwed that up. It's been a whirl-wind last 24 hours
or so. I had no idea how much faith (and spin) people put into these
silly tests.

Thanks for noticing that.

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.

No question. If it is wrong, it must be fixed. Will do shortly...

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.

Write once, do nothing, run anywhere, forever! Contrast with: write
forever, run for a while maybe, do get fired. jQuery junkies should
take particular note. This is your methadone.

 

[jdalton]

Hi David,

A what request? http://github.com/guides/pull-requests
http://github.com/phiggins42/taskspeed

You babbled a few generalizations, but didn't really say anything specific

It shows that while you call others incompetent they cover more bugs/
spec than your own work.

I don't need to test any of their bullshit at all.

You should, it helps point out the holes in your library.

Uh, no. You clearly don't understand how they work.

It's more than a switch statement and a few lines of code.
Browsers have issues/bugs that also need to be addressed.
You are oversimplifying.

I've barely said a thing about it since.

"The fastest, most concise, compatible and future-proof framework" 6
hours ago
"Write Once, Do Nothing, Run Anywhere, Forever." Jan 18th
"RIP jQuery, et al. Disco is Dead http://www.cinsoft.net/queries.html"
Jan 3rd

LOL. Moved on to jQuery?

Nope

Pardon me if I ignore the rest of your reports.

Ignoring your bugs/failings won't make them go away.
David, you have missed_the_mark more than a few times.
2 quick examples:
API.setAttribute erases element event observers when name/type
attributes are set in IE.
API.addScript called in the HEAD element throws an `Operation
Aborted` error in IE6 when a page has a BASE element

Any result that shows it as one of the "slowest" is clearly suspect.

As mentioned earlier you have been testing old versions of frameworks
and
have delayed in updating to the most recent which is clearly
suspect

I can tell you that without looking at any of your results (I've seen
all of the code).

Again, pretending your code is above reproach won't get you anywhere.

 

[David Mark]

I think one of your tests is incomplete.

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 listof 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.

I added it back in. Certainly not trying to cheat! As mentioned,
it didn't make a major difference (though that one test changed a
bit).

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.

In fact, I took it off the selectors test page for that very reason
(God knows someone will cry foul on that too, but test it yourself if
you are curious). In short, it's a non-starter on the Web (and always
has been).

 

[johncoltrane]

For what it's worth, here are my results with a G5 Mac from 2004 :

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.

 

[David Mark]

Hi David,


http://github.com/guides/pull-requestshttp://github.com/phiggins42/taskspeed

Uh, okay. Noted.

It shows that while you call others incompetent they cover more bugs/
spec than your own work.

No, nothing you said indicated anything of the sort. You said some
bullshit about failing jQuery's unit tests. (!) Is that meant to be a
joke? I don't need any unit tests to spot massive gaps in jQuery's
"logic", so their unit tests are hardly of interest to me (are you
saying _they_ passed them?)

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.

You should, it helps point out the holes in your library.

You are deluded. I'll bet dollars to donuts the "failures" you
"documented" are simply the same old (4 or 5) unsupported selectors
(and related cascades if those are anything like the interdependent
TaskSpeed tests).

It's more than a switch statement and a few lines of code.
Browsers have issues/bugs that also need to be addressed.
You are oversimplifying.

No, you are referring to one thing and I to another. I was talking
about the different selectors. Those _are_ switch statements and they
are very simple. You are (apparently) talking about veering QSA
around quirks, which is just the sort of stupid-ass mistake that
causes jQuery/Prototype/etc. to lag perpetually behind the competence
curve. Do you see how they gleefully leaped into QSA before they even
understood how and why their "slow lanes" were broken. Now they've
got a new layer of quirky bullshit to wade through. They are stupid.
Really. I couldn't have invented all of this. It's a matter of
public record.

"The fastest, most concise, compatible and future-proof framework" 6
hours ago

The Slickspeed test page, dumb-ass. I really _hate_ wasting time with
disingenuous little dip-shits. Your slovenly snipping is clearly on
purpose. Stop trying to confuse the issues.

"Write Once, Do Nothing, Run Anywhere, Forever." Jan 18th

Does that sound like it is about the SlickSpeed test page?

"RIP jQuery, et al. Disco is Dead http://www.cinsoft.net/queries.html"

That's not about either. Maybe you are just stupid (as opposed to
disingenuous).

Jan 3rd


Nope

Is that ever a load off my mind.

Ignoring your bugs/failings won't make them go away.

Visit my forum, stupid.

David, you have missed_the_mark more than a few times.

I'm sure. Do you even read my posts? How many times have I mentioned
that the code is not perfect. The ideas

2 quick examples:
  API.setAttribute erases element event observers when name/type
attributes are set in IE.

If it does, then there is a bug. If you've looked in the code, you
know there is a workaround in there for that. I suspect you are not
following the instructions, but I'll check anyway.

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.

  API.addScript called in the HEAD element throws an `Operation
Aborted` error in IE6 when a page has a BASE element

Whatever. Thanks for the report. You can bet I'll look into it. But
do you really think that the number of such observations means
anything? There are bugs and then there's outrageously incompetent
designs and implementations. These sure sound like bugs to me (and
the "Operation Aborted" sounds like it is unrelated to My Library).

As mentioned earlier you have been testing old versions of frameworks
and
have delayed in updating to the most recent which is clearly
suspect

No. You need to go back a few days (here) and read the discussions
related to that. You were looking at a two-year-old test page. Get
it?

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?

Again, pretending your code is above reproach won't get you anywhere.

I am not pretending that at all. I never said that. Again, your
quoting really sucks.

My main point is that the other libraries are so piss-poor (and have
been for so long) as to be excluded from consideration. Would you bet
on the Washington Generals?

 

[David Mark]

For what it's worth, here are my results with a G5 Mac from 2004 :

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

Very nice. Thanks John!

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.

Looking under the hood, you will find that Dojo and Qooxdoo are
cheating with browser sniffing. If you go back to older versions, you
will find they fall flat on their face when confronted with IE8.
That's not cross-browser scripting (just a fleeting illusion). Near
as I can tell, they still don't get it (to this day!) You sure can't
trust the UA string in IE8 (as if you could ever trust it anywhere).
They have just run straight into a ten-year-old truth and are still
reeling from the impact.

jQuery and Prototype are the slowest on this machine.

They always were. Looking under the hood shows why.

(off topic)
I never liked Firefox on Mac. Now, I think I know why.

It's always been a lesser FF (a bit buggy too). Who would use FF when
they have Safari built-in?

 

[David Mark]

For what it's worth, here are my results with a G5 Mac from 2004 :

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

Oh, forgot to mention that none of these other things even claims to
work with Opera (at least Opera < 10). Running the tests on Opera 7-9
shows why. They aren't reliable in any version of IE either
(especially not IE8!) So speed isn't everything.

And the other thing is that these "progressive enhancement" enablers
do nothing to enable progressive enhancement. They either work or
blow up (nothing in-between). Their line for years was that feature
testing would result in slow and bloated scripts. My line for years
has been that they are all full of shit (and wasting everyone's time
with their constant mistakes and rewrites).

 

[RobG]

TaskSpeed is another quasi-standard test that has never seen anything
like My Library. It was written by one of the Dojo guys. Yeah, I
know.

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

It just flat-out murders the rest (even Dojo)

Not on my machine - Windows XP, 3.3GHz P4. Here's the results for
Firefox 3.5 and IE 6:

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,

And yes, the test
functions are _very_ concise (even too concise).

If "concise" means less code, then the library itself is 145KB, which
is twice the size of YUI 3, though smaller than the monstorous
qooxdoo. Perhaps the size can be optimised so that each libarary only
contains the components required for the particular tests.

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.

 

[Scott Sauyet]

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

In my testing, several libraries are at least sometimes faster than
the "Pure DOM" methods, which makes me wonder about the quality of the
implementation of Pure DOM.

-- Scott

 

[jdalton]

Hi David,

Uh, okay. Noted.

Who says you can't teach an old dog new tricks

You said some bullshit about failing jQuery's unit tests. (!)

Don't get hung up on jQuery, you also fail many tests in Dojo,
Prototype, YUI, Google Closure, and general Slick tests.

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.

Great! I can't wait, I hope you follow up with bug reports as you
expect others to report bugs in your lib.

You are deluded. I'll bet dollars to donuts the "failures" you
"documented" are simply the same old (4 or 5) unsupported selectors
(and related cascades if those are anything like the interdependent
TaskSpeed tests).

Some maybe. Others are related to how you resolve elements with ID's,
multiple class names, attributes with unicode values and so on. You
won't know until you actually review the hundreds and hundreds of
failing tests.

No, you are referring to one thing and I to another. I was talking
about the different selectors. Those _are_ switch statements and they
are very simple.

Fair enough. You can certainly add support for additional selectors
via a switch statement, others have.

around quirks, which is just the sort of stupid-ass mistake that
causes jQuery/Prototype/etc. to lag perpetually behind the competence
curve. Do you see how they gleefully leaped into QSA before they even
understood how and why their "slow lanes" were broken.

What is your point ? You now have the opposite problem as other
frameworks have addressed bugs in QSA and you have not.

The Slickspeed test page, dumb-ass. I really _hate_ wasting time with
disingenuous little dip-shits.

The quotes show an assertion, on your part, of speed and
compatibility. On one hand you claim superiority on the other you hide
behind the excuse that your tests are old and irrelevant. If you don't
think they should be promoted then remove them from your site.

Visit my forum, stupid.

Why should I? If you don't bother reporting bugs for other libs why
should I bother reporting them to you?

I'm sure. Do you even read my posts? How many times have I mentioned
that the code is not perfect.

Exactly. Your code is not perfect. Yet you insult others whose code is
not perfect either.

If it does, then there is a bug.

Sure is.

If you've looked in the code, you
know there is a workaround in there for that.

A workaround doesn't matter. You have exposed API that can clearly
cause critical issues.

Whatever. Thanks for the report. You can bet I'll look into it.

Good to know.

But
do you really think that the number of such observations means
anything? There are bugs and then there's outrageously incompetent
designs and implementations.

Some would say attempting to support (and failing in more than one
area I might add) dead browsers would certainly lend to an incompetent
design/implementation.

No. You need to go back a few days (here) and read the discussions
related to that. You were looking at a two-year-old test page. Get
it?

Sure, it is still being promoted on your site though. It only takes a
few minutes to manually update the frameworks in Slickspeed/Taskspeed.

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?

Not true. Depending on your code implementation and how you address
various bugs speed can differ by a wide margin.

I am not pretending that at all. I never said that. Again, your
quoting really sucks.

My main point is that the other libraries are so piss-poor (and have
been for so long) as to be excluded from consideration.

Your reluctance to run the tests speaks louder than any words. Those
so called "piss-poor" libraries still fix bugs and address issues that
you are either ignorant of or fail to address properly.