TaskSpeed results for My Library

Discussion in 'Javascript' started by David Mark, Jan 27, 2010.

  1. David Mark

    David Mark Guest

    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. :)
    David Mark, Jan 27, 2010
    #1
    1. Advertising

  2. David Mark

    jdalton Guest

    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.
    jdalton, Jan 27, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    On Jan 27, 12:34 pm, jdalton <> wrote:
    > 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, Jan 27, 2010
    #3
  4. David Mark

    David Mark Guest

    On Jan 27, 12:34 pm, jdalton <> wrote:
    > 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? ;)
    David Mark, Jan 27, 2010
    #4
  5. David Mark

    jdalton Guest

    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.
    jdalton, Jan 27, 2010
    #5
  6. David Mark

    Scott Sauyet Guest

    On Jan 27, 12:09 pm, David Mark <> wrote:
    > 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 |
    +-------------------+--------+--------+--------+--------+--------+
    Scott Sauyet, Jan 27, 2010
    #6
  7. David Mark

    David Mark Guest

    On Jan 27, 2:32 pm, jdalton <> wrote:
    > 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
    >
    > > 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)


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

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

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

    >
    > > I never said it covered every selector.

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

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


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

    >
    > > Prototype hawker, huh?

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


    LOL. Moved on to jQuery?
    David Mark, Jan 27, 2010
    #7
  8. David Mark

    David Mark Guest

    On Jan 27, 2:32 pm, jdalton <> wrote:
    > 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, Jan 27, 2010
    #8
  9. David Mark

    David Mark Guest

    On Jan 27, 3:20 pm, Scott Sauyet <> wrote:
    > On Jan 27, 12:09 pm, David Mark <> wrote:
    >
    > > 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,


    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).
    David Mark, Jan 27, 2010
    #9
  10. David Mark

    Scott Sauyet Guest

    On Jan 27, 12:09 pm, David Mark <> wrote:
    > 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
    Scott Sauyet, Jan 27, 2010
    #10
  11. David Mark

    David Mark Guest

    On Jan 27, 4:02 pm, Scott Sauyet <> wrote:
    > On Jan 27, 12:09 pm, David Mark <> wrote:
    >
    > > 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 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. ;)
    David Mark, Jan 27, 2010
    #11
  12. David Mark

    jdalton Guest

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

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

    > 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.
    jdalton, Jan 27, 2010
    #12
  13. David Mark

    David Mark Guest

    On Jan 27, 4:02 pm, Scott Sauyet <> wrote:
    > On Jan 27, 12:09 pm, David Mark <> wrote:
    >
    > > 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 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).
    David Mark, Jan 27, 2010
    #13
  14. David Mark

    johncoltrane Guest

    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.

    --
    (ôlô)
    johncoltrane, Jan 27, 2010
    #14
  15. David Mark

    David Mark Guest

    On Jan 27, 4:31 pm, jdalton <> wrote:
    > Hi David,
    >
    > > A what request?

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


    Uh, okay. Noted.

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


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

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

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

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


    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.

    >
    > > I've barely said a thing about it since.

    >
    > "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
    >
    > > LOL.  Moved on to jQuery?

    >
    > Nope :D


    Is that ever a load off my mind. :)

    >
    > > Pardon me if I ignore the rest of your reports.  :)

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

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


    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?

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


    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, Jan 27, 2010
    #15
  16. David Mark

    David Mark Guest

    On Jan 27, 5:20 pm, johncoltrane <> wrote:
    > 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, Jan 27, 2010
    #16
  17. David Mark

    David Mark Guest

    On Jan 27, 5:20 pm, johncoltrane <> wrote:
    > 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). ;)
    David Mark, Jan 27, 2010
    #17
  18. David Mark

    RobG Guest

    On Jan 28, 3:09 am, David Mark <> wrote:
    > 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.


    --
    Rob
    RobG, Jan 28, 2010
    #18
  19. David Mark

    Scott Sauyet Guest

    On Jan 27, 9:02 pm, Andrew Poulos <> wrote:
    > 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
    Scott Sauyet, Jan 28, 2010
    #19
  20. David Mark

    jdalton Guest

    Hi David,

    > Uh, okay. Noted.

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

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

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

    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.

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

    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.

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

    >
    > 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.
    jdalton, Jan 28, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Monique Y. Mudama
    Replies:
    1
    Views:
    442
    Monique Y. Mudama
    Jun 28, 2005
  2. lovecreatesbeauty
    Replies:
    8
    Views:
    1,629
    Old Wolf
    Sep 12, 2005
  3. Ken Fine
    Replies:
    3
    Views:
    519
    Steven Cheng [MSFT]
    Jul 23, 2008
  4. David Mark

    My Library TaskSpeed tests updated

    David Mark, Feb 12, 2010, in forum: Javascript
    Replies:
    31
    Views:
    398
    Scott Sauyet
    Feb 23, 2010
  5. David Mark

    My Library _passes_ TaskSpeed in IE < 7

    David Mark, Feb 18, 2010, in forum: Javascript
    Replies:
    88
    Views:
    523
    Jorge
    Mar 7, 2010
Loading...

Share This Page