TaskSpeed results for My Library
David Mark
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
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, "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
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/mylib/test/jquery1.htmlhttp://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)
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
>
> 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 jQuery tests, commented out the jq custom selector tests)http://dl.dropbox.com/u/513327/mylib/test/jquery1.htmlhttp://dl.dropbox.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
> On Jan 27, 12:09 pm, David Mark <dmark.cins...@gmail.com> 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).
YUI 2.7? I thought you were using the latest stuff? See mine. I
just added YUI3 (waste of time though).
Scott Sauyet
> 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
> On Jan 27, 12:09 pm, David Mark <dmark.cins...@gmail.com> 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;
> },
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
> 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.
David Mark
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
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�
David Mark
> 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
> 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
>
> Specs : Mac OS X 10.5.8 / 1.8 GHz ppc G5 / 3 Gb RAM
>
> ---------------------+--------------+-------------+--------------
> | 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
>
> ---------------------+--------------+-------------+--------------
> | 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.
--
Rob
Andrew Poulos
> On Jan 28, 3:09 am, David Mark <dmark.cins...@gmail.com> 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
My testing on MS Vista:
Library Fx 3.6 IE 8 Op 10.10 Safari 4.04
PureDom 282 1,211 190 246
jQuery 1.2.6 1,692 6,269 1,904 1,188
jQuery 1.3.2 1,401 3,219 956 708
Prototype 1.6.0.3 889 3,790 830 385
MooTools 1.2.2 733 5,711 451 276
qooxdoo 0.8.2 405 1,383 180 208
Dojo 1.3.2 435 2,104 217 271
Dojo 1.4.0 448 1,771 266 245
YUI 2.7.0 788 2,370 517 286
YUI 3.0 440 1,531 252 255
My Library 1.0 448 1,757 222 168
I'm not sure how myLib can be faster than pure dom???
Andrew Poulos
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
Andrew Poulos
Or maybe its the quality of the coding of "pure DOM" methods? Its
interesting that the author specifically states that the source for
their "pure DOM" methods is unavailable.
Andrew Poulos
jdalton
> 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.
Scott Sauyet
> On 28/01/2010 3:23 PM, Scott Sauyet wrote:
>
>> On Jan 27, 9:02 pm, Andrew Poulos <ap_p...@hotmail.com> 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.
>
> Or maybe its the quality of the coding of "pure DOM" methods?
That's precisely what I meant by the implementation.
> Its interesting that the author specifically states that the
> source for their "pure DOM" methods is unavailable.
I think you misunderstood this quote from the taskspeed page:
| The 'PureDom' tests are written as a minimal abstract utility
| API to accomplish these tasks, and are included as a baseline
| measurement of the compared libraries. It currently is not a
| library available for download or use.
That does not mean that you can't see it. It's simply meant to be an
efficient, library-agnostic bit of code. It is included with the
tests, but it's not available as a stand-alone library in the manner
that Dojo, jQuery, MooTools, My Library, Prototype, qooxdoo, and YUI
are.
The test code is available at
http://dante.dojotoolkit.org/taskspeed/tests/pure-tests.js
and the minimal library used is at
http://dante.dojotoolkit.org/taskspeed/frameworks/webreflection.js
The test code looks like you would expect, with pure DOM code like
this:
(node = a[j]).parentNode.insertBefore(
p.cloneNode(true).appendChild(text.cloneNode(true))
.parentNode, node.nextSibling
);
The library contains a utility object consisting of four functions:
attachEvent, detachEvent, (Array) indexOf, and a small replacement for
or wrapper around querySelectorAll. Actually, that last looks a
little strange to me:
getSimple:document.createElement("p").querySelectorAll&&false?
function(selector){
return this.querySelectorAll(selector);
}:
function(selector){
// lightweight implementation here
}
Am I crazy or does that "&& false" mean that the first branch will
never be chosen? Perhaps that's the culprit?
-- Scott
S.T.
> 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.
He's made it clear in previous posts that he doesn't believe in unit
testing... it's "an expensive process".
The library's mantra is apparently "it should work, therefore it will".
Doesn't strike me as a comforting approach for any would-be adopters.
RobG
> On Jan 28, 12:14 am, Andrew Poulos <ap_p...@hotmail.com> wrote:
>
> > On 28/01/2010 3:23 PM, Scott Sauyet wrote:
>
> >> On Jan 27, 9:02 pm, Andrew Poulos <ap_p...@hotmail.com> 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.
> The test code is available at
>
> http://dante.dojotoolkit.org/taskspeed/tests/pure-tests.js
>
> and the minimal library used is at
>
> http://dante.dojotoolkit.org/taskspeed/frameworks/webreflection.js
>
> The test code looks like you would expect, with pure DOM code like
> this:
>
> (node = a[j]).parentNode.insertBefore(
> p.cloneNode(true).appendChild(text.cloneNode(true))
> .parentNode, node.nextSibling
> );
Not exactly what I'd expect. The text node should be appended to the p
earlier so there's no repeated clone, append, step-up-the-DOM.
Optimising as suggested gives a 25% speed boost in Fx and 10% in IE
6.
The same slow logic is used in the make function (my wrapping):
"make": function(){
for(var
d = document, body = d.body,
ul = d.createElement("ul"),
one = d.createElement("li")
.appendChild(d.createTextNode("one"))
.parentNode,
two = d.createElement("li")
.appendChild(d.createTextNode("two"))
.parentNode,
three= d.createElement("li")
.appendChild(d.createTextNode("three"))
.parentNode,
i = 0,
fromcode;
i < 250; ++i
){
fromcode = ul.cloneNode(true);
fromcode.id = "setid" + i;
fromcode.className = "fromcode";
fromcode.appendChild(one.cloneNode(true));
fromcode.appendChild(two.cloneNode(true));
fromcode.appendChild(three.cloneNode(true));
body.appendChild(fromcode);
};
return utility.getSimple
.call(body, "ul.fromcode").length;
},
Note the repetitious clone/append/step-up where a single clone would
have done the job - compare it to the jQuery code used:
$("<ul class='fromcode'><li>one</li><li>two</li><li>three</li></
ul>")
Here all elements are created in one go, so the two are hardly
comparible. The DOM code is doing 4 times the work (but still runs in
half the time of jQuery 1.4). Optimising out the extra work and it
runs about 15% faster in Firefox, and twice as fast in IE 6.
Note also that a selector is used to count the nodes added to the
document at the end and that the speed of this count is included in
the test. Why is selector speed allowed to influence tests of element
creation speed?
> The library contains a utility object consisting of four functions:
> attachEvent, detachEvent, (Array) indexOf, and a small replacement for
> or wrapper around querySelectorAll. Actually, that last looks a
> little strange to me:
>
> getSimple:document.createElement("p").querySelectorAll&&false?
> function(selector){
> return this.querySelectorAll(selector);
> }:
> function(selector){
> // lightweight implementation here
> }
>
> Am I crazy or does that "&& false" mean that the first branch will
> never be chosen?
Good find.
>Perhaps that's the culprit?
Regardless, it doesn't seem sensible to use a lightweight selector
engine when the intention is to compare selector engines to "pure
DOM" (which should mean ad hoc functions). There only selectors in the
test are:
1. ul.fromcode
2. div.added
A simple switch statement would have done the trick. The "pure DOM"
code doesn't leverage the browser-native getElementsByClassName method
if available, a for loop and RegExp is used always. Nor does it
leverage the fact that DOM collections are live, it gets the
collection every time. This is critical as a selector query is
included in nearly all the tests, so its performance affects tests
where it is not the feature being tested.
There are a number of optimisations that could quite easily be added
to "pure DOM", and the tests themselves do not accurately target the
features they are trying to test in some (many?) cases.
--
Rob
Andrea Giammarchi
to PureDOM ... I used native everything at the beginning and people
complained about the fact "obviously libraries have better selector
engines" ...
I have nullified querySelectorAll on purpose (which does NOT produce a
live object in any case, so all latest considerations about cached
live objects are superfluous adn nothing new, I have posted about this
stuff ages ago in WebReflection) and people keep thinking I am an
idiot, rather than simply remove that &&false which is clearly a
statement "nullifier" (as ||true is a statement "forcer").
That was the easiest way to test both getSimplle and native method ...
but you guys are too clever here to get this, isn't it?
About tricky code to speed up some appendChild and the BORING
challenge VS innerHTML (e.g. $("<ul class='fromcode'><li>one</
li><li>two</li><li>three</li></ul>") )
I don't think after a year of libraries still behind there's much more
to say about these topics.
If you want to trick PureDOM convinced you can speed it up, well, you
have discovered HOT WATER!!! Good Stuff, Hu?
The meaning of PureDOM is simple: to provide a comparative basic
manual approach and 'till now it demonstrated that no framework is
able to perform daily tasks faster than native DOM, or at least those
considered in TaskSpeed.
If you read tasks carefully, you will realize that if a task says: ...
and for each node, insert this text: "whatever" ...
the PureDOM code simply creates EACH NODE, and it inserts FOR EACH
NODE the text "whatever" ... bt let's cheat and feel cool, that's the
point, right?
Everybody else got it but this ML is still talking about PureDOM and
how badly it is etc etc ... well, use your best practices when
performances matter, and please stop wasting your time talking about
PureDOM or at least be decent enough to understand what is it and why
it's like that.
Finally, the day a library will be faster, I'll remove the fake
selector engine, I will implement proprietary IE way to append nodes
(insertAdjacentNode faster in many cases) and I bet PureDOM will still
outperform ... and that day somebody will talk about joined arrays for
faster strings via innerHTML ... I am sure about it!!!
Now, after all this, what have we learned today about JS? Me, nothing
for sure, yet another boring pointless discussion over PureDOM, I
receive a "warning" weekly basis about how people would have better
cheated in PureDOM ... uh, and don't forget the last test with
document.body.innerHTML = "" which is faster, right?
Best Regards, and thanks for asking before blaming
Garrett Smith
> I love people keep thinking about how many cheats i could have added
> to PureDOM ...
Who thought that?
I used native everything at the beginning and people
> complained about the fact "obviously libraries have better selector
> engines" ...
>
> I have nullified querySelectorAll on purpose (which does NOT produce a
Where?
> live object in any case, so all latest considerations about cached
> live objects are superfluous adn nothing new, I have posted about this
> stuff ages ago in WebReflection) and people keep thinking I am an
> idiot, rather than simply remove that &&false which is clearly a
> statement "nullifier" (as ||true is a statement "forcer").
>
You love confusing people with code that appears broken?
I'm trying to follow your response in response to RobG's post, which had
some of good feedback. Your posting style breaks the discussion, so it's
a struggle here, as a reader. It would have been much better if you had
instead replied inline.
> That was the easiest way to test both getSimplle and native method ...
> but you guys are too clever here to get this, isn't it?
>
> About tricky code to speed up some appendChild and the BORING
> challenge VS innerHTML (e.g. $("<ul class='fromcode'><li>one</
> li><li>two</li><li>three</li></ul>") )
> I don't think after a year of libraries still behind there's much more
> to say about these topics.
>
> If you want to trick PureDOM convinced you can speed it up, well, you
> have discovered HOT WATER!!! Good Stuff, Hu?
>
What?
[...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Scott Sauyet
wrote:
> I love people keep thinking about how many cheats i could have added
> to PureDOM ... I used native everything at the beginning and people
> complained about the fact "obviously libraries have better selector
> engines" ...
Whoa, hold on here a second! I don't think the criticism here is that
harsh!
I personally know nothing of the history of TaskSpeed, and nothing
about WebReflections.js.
There is an understandable concern when the libraries start to beat
the pure DOM solutions, as it's assumed that since everything is built
on top of the DOM tools, nothing should be any faster.
> I have nullified querySelectorAll on purpose (which does NOT produce a
> live object in any case, so all latest considerations about cached
> live objects are superfluous adn nothing new, I have posted about this
> stuff ages ago in WebReflection) and people keep thinking I am an
> idiot, rather than simply remove that &&false which is clearly a
> statement "nullifier" (as ||true is a statement "forcer").
>
> That was the easiest way to test both getSimplle and native method ...
> but you guys are too clever here to get this, isn't it?
Well, a comment would have been nice...
> About tricky code to speed up some appendChild and the BORING
> challenge VS innerHTML (e.g. $("<ul class='fromcode'><li>one</
> li><li>two</li><li>three</li></ul>") )
> I don't think after a year of libraries still behind there's much more
> to say about these topics.
>
> If you want to trick PureDOM convinced you can speed it up, well, you
> have discovered HOT WATER!!! Good Stuff, Hu?
I would have removed the &&false to test, but I don't want to be using
a different version of PureDOM for any published tests. That would
just muddy the waters.
> [ ... ] Everybody else got it but this ML is still talking about PureDOM and
> how badly it is etc etc ... well, use your best practices when
> performances matter, and please stop wasting your time talking about
> PureDOM or at least be decent enough to understand what is it and why
> it's like that.
Again, I think you're taking this too personally. First of all, in
this thread there were only a handful of posts questioning the speed
of PureDOM, and I haven't seen any other criticism of it in the few
months I've been around. But secondly, when one of the libraries
outperforms PureDOM, it does raise some awkward questions.
> Best Regards, and thanks for asking before blaming
Well, now I know who to ask, anyway. I've seen no URLs or email
addresses in the TaskSpeed tests to use when asking questions.
I'm very impressed with TaskSpeed. It's not ideal, but it's a decent
framework for discussing speeds of things that actually matter to web
developers. I'm glad it has a PureDOM implementation included, and
I'm not overly bothered by those places where it's slower than some of
the other libraries. But I am curious about why it might be slower.
Cheers,
-- Scott
Andrea Giammarchi
If there is an author, you ask to the author, you don't write
sentences possibly wrong or pointless, no?
If I don't understand something, or I think there is a typo, I don't
necessary start the campaign against that developer and how many
errors he wrote ... we are programmer, aren't we?
if(1&&1&&1&&1&&1&&1&&1&&1&&1&&1&&1&&false) is always false, ABC
if(0||0||0||0||0||0||0||0||0||0||0||true) is always true, ABC
If there is a &&false at the end and this is confusing ... well, I
guess we should consider to use jQuery, right?
Let's move over ... if I create li nodes for each created ul it is
because I am respecting the task, I AM NOT CHEATING
If you write in a row, internally via innerHTML and jQuery, of course
it's faster, isn't it? But that is the jQuery way, not the PureDOM
one, which aim is to PERFORM TASK SPEED TASKS without cheating at all.
Create 3 nodes and for each node append a text, that's what I have
done.
Create a node, append something, and clone it other two times ... that
is NOT the task.
Got my point?
My little cousin could speed up PureDOM test, to obtain WHAT?
We should understand why PureDOM is there and why it is like that ...
there is a Dojo man behind TaskSpeed, and me talking with him and
actually even fixing different things in every other framwork test
implementation (I have spotted inconsistency about one test and
proposed a fix for all).
Why after a year or more people still don't get PureDOM is a mystery
to me, this is why I get bored after the first line of comment.
Is there a way to respect the task and perform better without cheating
or use everything native where supported? I am ready to listen, but
not the classic "here innerHTML would have been better, here
cloneEverything would have speed up".
Got my point? I hope so
Regards
Andrea Giammarchi
> Cheers,
>
> -- Scott
and whcih library outperform PureDOM? Aren't we talking about that
post with my massive comment inside removed/filtered?
Andrea Giammarchi
> There is an understandable concern when the libraries start to beat
> the pure DOM solutions, as it's assumed that since everything is built
> on top of the DOM tools, nothing should be any faster.
and how can be this possible, since PureDOM choice is to do not use
innerHTML to add or remove nodes?
innerHTML is standard since HTML5, PureDOM would like to avoid it and
use W3 way to generate content.
I can reduce to "zero" TaskSpeed PureDOM results, and again, to
demonstrate what?
This is why I keep saying after a year people still do not get what
PureDOM is!!!
BASELINE
just to give you an idea:
http://webreflection.blogspot.com/2009/12/taskspeed-real-cheat.html
http://debuggable.com/posts/rightjs-1-5-6-8-times-faster-than-jquery:4b1fc009-1940-4d26-bdc6-0af2cbdd56cb
but if you want the fastest version ever, I can create it m then it
will be completely useless for its purpose.
Regards
Andrea Giammarchi
http://debuggable.com/posts/rightjs-1-5-6-8-times-faster-than-jquery:4b1fc009-1940-4d26-bdc6-0af2cbdd56cb#comment-4b2034e7-2b54-4037-8bed-289ccbdd56cb
With explanation about PureDOM, a proper cheat via innerHTML (did not
spend too much to create it tho) and the reason this thread is
pointless, imho.
Scott Sauyet
wrote:
> If there is an author, you ask to the author, you don't write
> sentences possibly wrong or pointless, no?
Only if you know who the author is and how to contact him or her. I
know your name and have seen you around various groups over the years,
but until today did not know you were responsible for the PureDOM
implementation in TaskSpeed. The TaskSpeed page says about the
PureDOM methods that, "It currently is not a library available for
download or use," and the implementation of the tests and
webreflection.js gave no pointers to their author.
> If I don't understand something, or I think there is a typo, I don't
> necessary start the campaign against that developer and how many
> errors he wrote ... we are programmer, aren't we?
Obviously you're seeing something very different in this thread than I
am. I have certainly seen no campaign against you, and I certainly
have not participated in one.
> if(1&&1&&1&&1&&1&&1&&1&&1&&1&&1&&1&&false) is always false, ABC
> if(0||0||0||0||0||0||0||0||0||0||0||true) is always true, ABC
>
> If there is a &&false at the end and this is confusing ... well, I
> guess we should consider to use jQuery, right?
I have no idea what you mean by this.
I did assume that the &&false had been once used to comment out the
branch for some quick testing. Without a comment in the code, though,
I assumed it's continued existence was a mistake.
> Let's move over ... if I create li nodes for each created ul it is
> because I am respecting the task, I AM NOT CHEATING
>
> If you write in a row, internally via innerHTML and jQuery, of course
> it's faster, isn't it? But that is the jQuery way, not the PureDOM
> one, which aim is to PERFORM TASK SPEED TASKS without cheating at all.
That's a somewhat different perspective than I had considered. I
really thought about PureDOM as the baseline, the thing nothing could
beat in terms of speed because everything else would (along their own
tortured paths) eventually be calling the same methods that PureDOM
called. Your explanation makes sense, though. It's not a performance
baseline but a standards-based baseline. You're calling only those
methods that the spec require DOM implementations to have, is that
right?
> Why after a year or more people still don't get PureDOM is a mystery
> to me, this is why I get bored after the first line of comment.
Do you understand where my mistaken impression came from, then? On
the Taskspeed page, we have this: "The 'PureDom' tests are written as
a minimal abstract utility API to accomplish these tasks, and are
included as a baseline measurement of the compared libraries." Since
the only measurements involved are the speeds, it seems a natural
conclusion that it's providing a speed baseline, and at least a good
guess that it should by its nature be the fastest possible.
> Got my point? I hope so
I think so. But it would have been much easier to hear without the
extreme defensiveness.
-- Scott
Scott Sauyet
wrote:
> and whcih library outperform PureDOM?
I posted my results earlier in the thread:
http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a/results/
Dojo outperformed it in Safari, qooxdoo did in Chrome, Opera, and
Safari, and My Library did in Chrome and Safari. None of the speed
differences were huge.
> Aren't we talking about that
> post with my massive comment inside removed/filtered?
I don't know what you're talking about here.
-- Scott
Andrew Poulos
>
>> Cheers,
>>
>> -- Scott
>
> and which library outperform PureDOM? Aren't we talking about that
> post with my massive comment inside removed/filtered?
Under TaskSpeed, on Vista SP 2 with Safari 4.04 "My Library" was faster
than PureDom - 168 versus 246.
Andrew Poulos
Richard Cornford
> On Jan 29, 1:24 am, Scott Sauyet wrote:
>> On Jan 28, 12:14 am, Andrew Poulos wrote:
>>> On 28/01/2010 3:23 PM, Scott Sauyet wrote:
Why the superfluous EmptyStatement after the Block of the - for - loop?
> return utility.getSimple
> .call(body, "ul.fromcode").length;
> },
>
> Note the repetitious clone/append/step-up where a single clone would
> have done the job - compare it to the jQuery code used:
>
> $("<ul class='fromcode'><li>one</li><li>two</li><li>three</li></
> ul>")
>
> Here all elements are created in one go, so the two are hardly
> comparible. The DOM code is doing 4 times the work (but still runs
> in half the time of jQuery 1.4). Optimising out the extra work and
> it runs about 15% faster in Firefox, and twice as fast in IE 6.
The criticism of extra work here is perhaps a little unjust. The JQuery
version is itself inside a loop and will perform its operation 250
times, presumably because doing it once would be so quick that no
meaningful timing could be made.
The JQuery version of "make" is:-
|"make": function(){
| for(var i = 0; i<250; i++){
| $(
| "<ul class='fromcode'><li>one</li><li>two</li><li>three</li></ul>"
| ).attr("id", "setid" + i).appendTo("body");
| }
| return $("ul.fromcode").length;
|}
So the task being measured is the creation of the UL and its three LI
children (implying their being appended to the UL, and similar for their
text node children), the setting of the ID attribute and appending the
structure to the BODY of the document. While the pure DOM version
carries the overhead of initially creating a set of nodes for cloning
that are themselves never actually used, building the structure inside
the loop seems reasonable.
On the other hand, Your criticism does justly apply to other tests, for
example the "insertbefore" test. Here the JQuery version is:-
| "insertbefore" : function(){
| return $(".fromcode a").before("<p>A Link</p>").length;
| }
- so the operation being timed here is inserting a pre-defined DOM
branch before A element descendent of each element with the CLASS
'fromcode'. There is no looping to exaggerate the timing, and so the DOM
version could reasonably be optimised in order to reproduce the entire
process that is being asked of the other libraries. That is, the common
P element structure could be created once and then deep-cloned for each
insertion, rather than having javascript code repeated the assembling of
the structure on each iteration of the loop.
> Note also that a selector is used to count the nodes added to the
> document at the end and that the speed of this count is included in
> the test. Why is selector speed allowed to influence tests of
> element creation speed?
Yes that is bad. It probably follows from listing the test code from a
selector speed test framework, where knowing how many elements were
found using the selector is pretty important.
It makes some sense to verify that the various test operations have done
the thing that is being asked of them, as if some test fails to achieve
what is expected of it then it doesn't really matter how long it took to
do that. But any verification process should not be included in the
tests themselves, except under the possible condition that _precisely_
the same verification code is used for each version of each test. Better
though to have any verification applied after the timings, else they
would confuse the question of what it is that is being timed.
>> The library contains a utility object consisting of four functions:
>> attachEvent, detachEvent, (Array) indexOf, and a small replacement
>> for or wrapper around querySelectorAll. Actually, that last
>> looks a little strange to me:
>
>> getSimple:document.createElement("p").querySelectorAll&&false?
>> function(selector){
>> return this.querySelectorAll(selector);
>> }:
>> function(selector){
>> // lightweight implementation here
>> }
>
>> Am I crazy or does that "&& false" mean that the first branch will
>> never be chosen?
>
> Good find.
Yes, it means that in environment that support - querySelectorAll -,.
and with libraries that employ it where available, the DOM code is going
to be suffering by comparison.
>> Perhaps that's the culprit?
>
> Regardless, it doesn't seem sensible to use a lightweight selector
> engine when the intention is to compare selector engines to "pure
> DOM" (which should mean ad hoc functions). There only selectors in
> the test are:
>
> 1. ul.fromcode
> 2. div.added
>
> A simple switch statement would have done the trick. The "pure
> DOM" code doesn't leverage the browser-native
> getElementsByClassName method
getElementsByClassName is relatively recent so if used it would need
an emulation for older environments.
> if available, a for loop and RegExp is used always. Nor does it
> leverage the fact that DOM collections are live,
The live nature of collections proved to be the cause of an interesting
characteristic of the tests; that on IE (and very particularly IE 6) the
pure DOM "sethtml" is massively worse than any of the alternatives. The
code is:-
| "sethtml": function(){
| var div = document.body.getElementsByTagName("div"), i = 0, node;
| while(node = div[i++])
| node.innerHTML = "<p>new content</p>"
| ;
| return div.length;
| }
- and it is difficult to see how any alternative could be doing less
that that code is (with the presumption that code that does more should
take longer to do it). But it turns out that it is the 'live' node list
that is returned from - getElementsByTagName -, combined with the fact
that some of the DIVs are nested and so assigning to - innerHTML -
effectively deletes nodes and so forces updating of the 'live' list,
that seriously slows this test down in IE.
Adding:-
| getArrayByTagName:function(node, tag){
| var obj = node.getElementsByTagName(tag);
| var c, ar = [];
| if((c = obj.length)){
| do{
| ar[--c] = obj[c];
| }while(c);
| }
| return ar;
| }
- to the - utility - object in webreflection, and replacing the
"sethtml" code with:-
"sethtml": function(){
var div = utility.getArrayByTagName(document.body, "div");
var i, node;
var res = 0;
if((i = div.length)){
do{
if((node = div[--i]).parentNode.tagName != 'DIV'){
++res;
node.innerHTML = "<p>new content</p>";
}
}while(i);
}
return res;
}
- managed to get IE performance up to that of the other libraries. The
main difference being that the an ordinarily Array is being used in
place of the 'live' node list (plus the DIVs that are nested inside
other DIVs do not get their - innerHTML - set, as that is pointless).
> it gets the
> collection every time. This is critical as a selector query is
> included in nearly all the tests, so its performance affects
> tests where it is not the feature being tested.
Yes, this is a recurrent problem with the tests code. It seems to be
trying to compare versions of a particular approach to browser scripting
without questioning whether that whole approach is necessary.
However, a few things about the 'plain DOM' selector function;
An example reads:-
utility.getSimple.call(body, "ul.fromcode")
- and what this function does is, given an element (body in the above
case), find all of its decedents that are UL elements and have/include
the class 'fromcode'.
Why the use of - call -? What is the reason for not passing the
reference to the element as an argument and replacing its two uses of -
this - with the name of that parameter.
Why use the 'selector' "ul.fromcode" when an argument pattern for such a
function could go - getDecedentsByTagNameWithClass(body, 'ul',
'fromcode') - ? This seems a much better fit with what is needed from
the function, and saves a - split - and a - call - call for every
invocation (while not removing the option of branching to use -
querySelectorAll -, by combining the string arguments into an
appropriate selector).
> There are a number of optimisations that could quite easily be
> added to "pure DOM", and the tests themselves do not accurately
> target the features they are trying to test in some (many?)
> cases.
Unfortunately there is no clear statement of what features they are
trying to test. An example of a test that is amenable to optimisation is
the "finale" method, for which the pure-tests.js code is:-
| "finale": function(){
| var body = document.body, node;
| while(node = body.firstChild)
| body.removeChild(node)
| ;
| return body.getElementsByTagName("*").length;
| }
An "optimised" version might go:-
"finale": function(){
var body = document.body;
body.parentNode.replaceChild(body.cloneNode(false), body);
return document.body.childNodes.length;
}
- and give a better than 50% performance increase in many environments.
Here the removal of the children of the body is substituted by replacing
the body element with a shallow clone of itself (as that will have no
children). It would also be feasible to replace the body element with a
new body element (as that also will have no children). Creating a new
body element has issues in the general case, if the existing body has
(non-default) attributes the new replacement will not have those
attributes, and so the body of the document would effectively change as
a side effect removing its children. Similarly - cloneNode - has issues,
mostly relating to event listeners, and whether they get
transferred/copied to the cloned node. Thus, again in the general case,
replacing a body with a shallow clone of itself in order to get the side
effect of clearing the body's children risks modifying the body element
itself.
However, the issues that exist in the general case are issues for
general code, and may or may not apply in specific cases (the general
purpose library must consider them, but they are not inherent in browser
scripting). Here the test document's body element has no attributes, and
it has no event listeners, so we are fine. We can optimise the process
of clearing the body element in this document by replacing it with
either a new body element or a shallow clone of itself.
Richard.
RobG
wrote:
> I love people keep thinking about how many cheats i could have added
> to PureDOM ... I used native everything at the beginning and people
> complained about the fact "obviously libraries have better selector
> engines" ...
It would help greatly if there was a clear statement about the purpose
of the tests. Finding a description of what each test is supposed to
do is not easy, eventually I discovered that it is in on GitHub in
sample-tests.js. It would be better if that was made more easily
available and called something more obvious, such as "test
description" or "test specification".
> I have nullified querySelectorAll on purpose
Then a comment in the source would have been helpful. The way it was
nullified gave the impression that it was not intentional.
> (which does NOT produce a
> live object in any case, so all latest considerations about cached
> live objects are superfluous adn nothing new,
I know QSA doesn't return live collections, but other DOM methods
using getElementsBy... do. Richard's comment in regard to IEs
performance and live collections is interesting.
> I have posted about this
> stuff ages ago in WebReflection) and people keep thinking I am an
> idiot, rather than simply remove that &&false which is clearly a
> statement "nullifier" (as ||true is a statement "forcer").
I had never heard of WebReflection until I came across TaskSpeed, I
see now it is your blog. If there is important information or
discussion there relating to TaskSpeed, why not put a link to it on
the TaskSpeed page?
And I don't think you're an idiot based on looking at the code (I
suppose you wrote it), but I do think there was a lack of attention to
detail. That can be excused if you didn't expect it to be as popular
as it is and gain the attention it has, but given that it has been up
for some time now, it would have been helpful if those issues had been
addressed.
> That was the easiest way to test both getSimplle and native method ...
> but you guys are too clever here to get this, isn't it?
If you don't want to use QSA, don't include a branch for it, then no
one is confused.
> About tricky code to speed up some appendChild and the BORING
> challenge VS innerHTML (e.g. $("<ul class='fromcode'><li>one</
> li><li>two</li><li>three</li></ul>") )
> I don't think after a year of libraries still behind there's much more
> to say about these topics.
My point was that the code itself is not performing equivalent
operations - the pureDOM version does many more create/append
operations.
> If you want to trick PureDOM convinced you can speed it up, well, you
> have discovered HOT WATER!!! Good Stuff, Hu?
It's not a "trick", just obvious that the operations that each test
performs should be equivalent. It is the operations that are being
tested, not the trickiness of the programmer.
> The meaning of PureDOM is simple: to provide a comparative basic
> manual approach
Thank you for explaining that, but it's differnt to what you say
below.
> and 'till now it demonstrated that no framework is
> able to perform daily tasks faster than native DOM, or at least those
> considered in TaskSpeed.
>
> If you read tasks carefully, you will realize that if a task says: ...
> and for each node, insert this text: "whatever" ...
> the PureDOM code simply creates EACH NODE, and it inserts FOR EACH
> NODE the text "whatever" ... bt let's cheat and feel cool, that's the
> point, right?
Then that is what all the tests should do. The library's version of
create should be called once for each node and the text appended
separately, then each node appended to its parent. If jQuery (for
example) is allowed to use a string of HTML to create a document
fragment of all the nodes n times, then the pureDOM method should be
able to create the same structure once and clone it n times. Otherwise
you are not testing the same thing.
> Everybody else got it
Where?
> but this ML is still talking about PureDOM and
> how badly it is etc etc ...
This group is about javascript, so you will likely only get comments
about pureDOM here. If you posted links to other discussion threads
and included some clarifying documentation (or at least links to it)
on the TaskSpeed page then we might have "got it" too.
> well, use your best practices when
> performances matter, and please stop wasting your time talking about
> PureDOM or at least be decent enough to understand what is it and why
> it's like that.
If you make that information accessible, I won't need to guess your
intentions.
>
> Finally, the day a library will be faster, I'll remove the fake
> selector engine, I will implement proprietary IE way to append nodes
> (insertAdjacentNode faster in many cases) and I bet PureDOM will still
> outperform ... and that day somebody will talk about joined arrays for
> faster strings via innerHTML ... I am sure about it!!!
I don't see an issue with pureDOM using innerHTML if fits the criteria
for a test.
> Now, after all this, what have we learned today about JS? Me, nothing
> for sure, yet another boring pointless discussion over PureDOM, I
> receive a "warning" weekly basis about how people would have better
> cheated in PureDOM ... uh, and don't forget the last test with
> document.body.innerHTML = "" which is faster, right?
I don't think anything that is done in pureDOM is a cheat since I have
no criteria on which to base that opinion. If the point of pureDOM is
to use *only* W3C specified DOM interfaces, then fine, eschew
innerHTML. But that is not stated anywhere and above you said that the
point of pureDOM was to "provide a comparative basic manual approach".
So which is it?
One of the main claims about libraries is that they smooth over
browser quirks. It might be interesting to develop a suite of
"QuirksSpeed" tests of known differences between browsers to determine
how well each library manages to overcome them. The overall speed is
likely not that important, quirks accommodated and correctly dealt
with likely are.
--
Rob
Andrea Giammarchi
time.
To me could make sense to write a PureCheat library to put beside
PureDOM, not a replacement, since in any case, innerHTML could be a
problem.
As example, the first test via innerHTML will potentially destroy
every attached event handler to existent content.
I have that fast version, I hope to have time to create a full
PureCheat version as well.
Regards
P.S. same webreflection that blogs sometimes in Ajaxian, that is kinda
still me ;-)
David Mark
> On 1/27/2010 10:56 PM, jdalton wrote:
>
> > 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.
Just catching the tail end of this thread. Sounds like this is
addressed to me, but piss-poor quoting makes it hard to tell. Make no
mistake that the "major" libraries are full of ridiculous holes (e.g.
attribute handling), not to mention browser sniffing. Each instance
of the latter is an admission by the author(s) that they could not
make their design work cross-browser. Need a new design, new authors
or both.
>
> He's made it clear in previous posts that he doesn't believe in unit
> testing... it's "an expensive process".
Who said that? My Library certainly has unit tests. Some of them are
even online. Not expensive, just click the button. ;)
What I don't care for is software design that is _shaped_ by unit
testing. Testing is supposed to confirm the correctness of a
solution, not serve as a crystal ball.
>
> The library's mantra is apparently "it should work, therefore it will".
No it isn't and it has been demonstrated to work in virtually any
DOM. Most of the others can't make IE8 work, even with browser
sniffing.
> Doesn't strike me as a comforting approach for any would-be adopters.
You don't strike me as very intelligent (or able to read for
comprehension). ;)
David Mark
> Hi David,
>
> > Uh, okay. Noted.
>
> Who says you can't teach an old dog new tricks :D
You? And your quoting is as incompetent as usual (I doubt I noted
your salutation).
>
> > 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.
Other libraries unit tests are inconsequential at this stage. And
SlickSpeed is on my site and My Library is the only one that makes it
through unscathed in all browsers tested. Most of the others start to
sputter outside the confines of browsers the authors have heard of
(and sniffed for).
>
> > 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.
Don't be stupid. I've submitted lots of bug reports to the other
libraries. They are hesitant to change anything as they don't seem to
understand anything they have done (usually a bunch of browser sniffs
stacked on top of each other). It's hard to say what is a bug in a
collection of non-solutions.
>
> > 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,
That's not a bug. There's no crutch for the IE name/ID issue. That
was decided long ago (and documented here). You get back null if your
markup is screwy (that way you know it is screwy).
> multiple class names,
You must be testing an old version. The builder/test page script has
not been updated with the latest changes. As I have never specified
exactly what the library supports (not good, of course), it is hard to
call those bugs either. Certainly the scripts on the Downloads page
support multiple class names (and I added a test for this to the
SlickSpeed page, which oddly omitted that case).
> attributes with unicode values and so on.
Attributes? You must be joking. I'm not saying there isn't an issue
with mine, but the others aren't even in the ballpark (particularly in
IE).
> You
> won't know until you actually review the hundreds and hundreds of
> failing tests.
I will review them when I feel it is appropriate. Thanks.
>
> > 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.
I already added support for all but one of the original test page's
selection, as well as some others that it omitted. And I still
contend the whole thing with the selector engine is a fool's errand.
How do you spend years trying to make that work, fail, and then add a
QSA branch, which is clearly incompatible with the previous failings?
It's pure madness.
>
> > 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.
No, I don't have the problem at all. The QSA add-on is not needed as
the library is certainly fast enough without it.
>
> > 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.
Now what are you talking about? None of these are my tests. And you
can't get much more superior than the results I've observed across a
wide range of browsers, both new and old (particularly TaskSpeed,
where my optimized-for-conciseness tests beat the "baseline" PureDom
handily).
> If you don't
> think they should be promoted then remove them from your site.
Remove what from my site? You really need to work on your quoting. I
don't know what you are talking about half of the time.
>
> > 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 don't want you to report bugs to me, nor have I asked you to. I
don't need your help. Is that clear enough? And I have reported
plenty of bugs to the other libraries. Where have you been the last
couple of years?
>
> > 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.
I don't think you understand at all. The others claim that they have
armies of vigilant "hackers" turning out cost-saving cross-browser
"solutions" and most are so completely incompetent that they don't
even _try_ to solve anything, preferring to constantly twiddle with UA
sniffs, "degrading" (on paper) anything but the very latest of the
major desktop browsers. That's the complete opposite of My Library,
which was originally posted as an example for others and is now being
polished into something that should displace all of these other non-
solutions for good.
>
> > > 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.
Great. I'll look at it. There is a function in there to transfer the
listeners on replacement. Perhaps you mean listeners set by other
libraries? And, of course, the whole idea of using the setAttribute
wrapper to change the type (or name) of an INPUT is a novelty anyway.
>
> > 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.
The workaround I refer to is behind-the-scenes and is supposed to
transfer the listeners to the new node. Again, this is just a
novelty.
>
> > > 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.
Have you read _anything_ I've written? Do you understand that whether
the browsers are "dead" or alive is irrelevant? The idea is to test
in as many limited DOM's as possible. You have no idea what is out
there in phones and other devices (in some cases, old Opera
versions). ;)
And failing? The degradation is working swimmingly almost entirely
across the board, even back to NN4. Perhaps you prefer scripts that
just blunder into exceptions, leaving the document in an unknown
state? That's what all of the others do as they have no way to tell
the calling app what will work (the library doesn't know itself).
They can only be _expected_ to work in environments where they have
been demonstrated to work and typically that includes only the default
configurations of the very latest versions of major desktop browsers
(excluding IE where they all fail miserably in one crucial way or
another).
>
> > > 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.
They've long since been updated. And what business is it of yours? I
still contend the old speed tests are far more telling than comparing
QSA results. ;)
>
> > 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.
Not really. 90% of the SlickSpeed tests take 0ms in the environments
I've tested. The others "thunk" back to the slow lane, which is
another story. I suppose if a library is so completely tangled up in
its own syntactic sugar, it could manage to make QSA-based queries
slow. The variations will be nowhere near those in the "slow lane"
though.
>
> > 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.
No reluctance at all. I don't need to worry about unit tests written
by others at the time. I am busy working on my own. Thanks for your
concern.
And, as noted in another post (and discussed endlessly here for
years), the other piss-poor "major" libraries are typically non-
solutions involving browser sniffing. In other words, they couldn't
make their designs work, even multi-browser (let alone cross-browser),
so gave up and branched on the baseless UA string. That's pure
incompetence and a full decade behind reality. And I mean the users'
reality, not the deluded imaginings of the developers.
David Mark
"Pure DOM" was written by a human being, just like the rest.
Obviously they made some mistakes as it is nowhere near optimal
(particularly in Webkit-based browsers).
And realize that the tests for each framework are different. I
purposely optimized for conciseness, not speed. Most of the others
are using built-in DOM methods for at least some of the test
functions. My point is that I have the best of both worlds. If you
want pure speed, use the more verbose API. If you like jQuery-like
gibberish, chain the object methods together like I did in the test
functions. It's flexible that way. ;)
David Mark
> On Jan 28, 3:09 am, David Mark <dmark.cins...@gmail.com> 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.
Which My Library? The one with QSA or not? It makes a small
difference in TaskSpeed (and a huge one in SlickSpeed).
> 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,
None of the others comes close to supporting IE6 properly (e.g. they
just call getAttribute without regard to the broken implementation).
Of course, that's more of a concern for SlickSpeed.
>
> > 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,
That's with _every_ module included (e.g. Flash, audio, scrolling
effects, etc). Most of them are not needed by these tests.
> 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.
That's what the builder is for. ;)
>
> The test code itself is not as concise as that for jQuery, and not
> much more concise than most of the others.
I looked at some of them and more than one was using native DOM
methods, so it seems they are apples and oranges. I remember that
YUI's weren't particularly concise.
> Prototype and MooTools are
> perhaps the least concise, the total code for the "pure DOM" is 10KB.
Sure. It's just enough to run these tests. ;)
>
> But the test code is tiny in comparison to the library itself, so not
> really a huge concern.
My point is that it supports the "concise" coding style that is so
popular among major library enthusiasts (and is very fast doing it).
It also supports more traditional methods (even faster).
And I have found after extensive testing that the margin of victory is
wider on older machines, older browsers, phones and Webkit-based
browsers. Faster PC's running IE and FF have closer results.
And ultimately, if a library that is supposed to make cross-browser
scripting easier fails to handle attributes properly in IE or resorts
to non-solutions like browser sniffing, it should be disallowed (which
rules out all of the others). I plan to demonstrate that on the test
pages in the near future. It should come as no great revelation to
regular readers of this group though. ;)
David Mark
>
> > 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.
>
> He's made it clear in previous posts that he doesn't believe in unit
> testing... it's "an expensive process".
>
I knew I didn't say that. :) You misread. QA testing is an
expensive process, which is why these script of the month clubs are
folly. If you have to re-download and re-test a monstrously large and
complex blob of JS every time a new wave of browsers hits, you are
throwing money out the window for no reason. Eventually, you cut your
losses.
David Mark
wrote:
Mine kicks the shit out of it in WebKit (also Opera and FF on some
older machines).
And, of course, some of the other libraries cheat (e.g. YUI attaching
a single listener to the body, in lieu of one for each DIV created),
so these numbers cannot be taken at face value.
David Mark
wrote:
> And Finally:http://debuggable.com/posts/rightjs-1-5-6-8-times-faster-than-jquery:...
>
> With explanation about PureDOM, a proper cheat via innerHTML (did not
> spend too much to create it tho) and the reason this thread is
> pointless, imho.
I'd say your contributions have been pointless so far. Yes, you
should make the "baseline" as fast as possible without sacrificing
cross-browser compatibility.
David Mark
> On Feb 4, 11:45 am, Andrea Giammarchi <andrea.giammar...@gmail.com>
> wrote:
>
> > and whcih library outperform PureDOM?
>
> I posted my results earlier in the thread:
>
> http://scott.sauyet.com/Javascript/Test/taskspeed/2010-01-27a/results/
>
> Dojo outperformed it in Safari, qooxdoo did in Chrome, Opera, and
> Safari, and My Library did in Chrome and Safari. None of the speed
> differences were huge.
They are on older PC's (and mobile devices). 60% faster in Chrome/
Safari on an older (but not ancient) XP box. Lots of "normal people"
have such equipment, of course.
David Mark
Should be noted that multiple tests must be run and the results
averaged to get a fair representation. I see a lot of posts that
appear to be one-off runs, which may or may not be good indications.
No question that My Library is faster than the "pure" tests in Webkit
though (by a long stretch), even with the unnecessary overhead of the
OO interface.
David Mark
[...]
>
> One of the main claims about libraries is that they smooth over
> browser quirks. It might be interesting to develop a suite of
> "QuirksSpeed" tests of known differences between browsers to determine
> how well each library manages to overcome them. The overall speed is
> likely not that important, quirks accommodated and correctly dealt
> with likely are.
>
I agree 100%. That is where most of them fail miserably (e.g. jQuery
"punts" on IE quirks mode, none of them handle attributes properly,
etc.) And sniffing the UA string must result in a disqualification.
I'm working on something like that, but I can't find too many that
eschew the UA string. They give up much too easily in the name of
"getting things done" (which translates to "not getting anything done"
in reality).
jdalton
> Other libraries unit tests are inconsequential at this stage.
They still cover bugs and browser issues that your library fails to
cover.
> Don't be stupid.
> I've submitted lots of bug reports to the other
> libraries. They are hesitant to change anything as
> they don't seem to understand anything they have done
Reporting bugs is good. They (Dojo) will fix them on their timeline
not yours. Twitter spamming them won't help.
> That's not a bug. There's no crutch for the IE
Again, the tests show you have bugs in lots of areas.
> No, I don't have the problem at all. The QSA add-on is not needed as
> the library is certainly fast enough without it.
Other's Up-to-date CSS engines beat yours, in speed and compatibility,
with or without QSA.
> I don't want you to report bugs to me, nor have I asked you to. I
> don't need your help. Is that clear enough?
Good.
> (particularly TaskSpeed,
> where my optimized-for-conciseness tests beat the "baseline" PureDom
> handily).
If your tests are beating PureDom you A) have done your tests
incorrectly or B) there is a problem with PureDom.
> Have you read _anything_ I've written?
Unfortunately I have. Your writings are mostly long multi-post/page
rants where you reply to yourself or aliases. Repeat the same tired
arguments over and over again, sprinkle in some name calling/insults,
and you have a classic David Mark post.
> And failing?
Yes, your library has bugs in many browsers and versions of browsers.
So many, in fact, visitors to your g-group, who seem to be relatively
new to JS, point them out over and over again.
> They've long since been updated. And what business is it of yours?
> I still contend the old speed tests are far more telling than comparing
> QSA results. ;)
...
> Not really. 90% of the SlickSpeed tests take 0ms in the environments
You should try a modified form of SlickSpeed that test max executions
per ms, instead of 3 or so calls per test. This gives a more accurate
indication of performance. You will find that your library is actually
one of the slowest. Example: http://davidmissedthemark.com/slickspeed/
> No reluctance at all. I don't need to worry about unit tests written
> by others at the time.
Again, you are missing several basic bug fixes/browser issues because
you refuse to look at others tests.
David Mark
> Hi David,
>
> > Other libraries unit tests are inconsequential at this stage.
>
> They still cover bugs and browser issues that your library fails to
> cover.
You have a very child-like view of this. If I decide (as I did) to
_not_ allow bizarre markup (e.g. names and ID's that are the same for
different elements), that is my design choice. I want the developer
to know they are screwing up in that case. Other libraries took a
different tack. That's why it makes little sense to test my design
against their unit tests. Certainly you can't take the results at
face value. What is reported as an "error" may well be intended by
the designer. Get it?
>
> > Don't be stupid.
> > I've submitted lots of bug reports to the other
> > libraries. They are hesitant to change anything as
> > they don't seem to understand anything they have done
>
> Reporting bugs is good. They (Dojo) will fix them on their timeline
> not yours. Twitter spamming them won't help.
You aren't following (and are clearly out of that loop). They tried
to fix them and could never get past the understanding stage. I asked
them to define what attr does and they said "it does what it does in
FF". There's no hope with that sort of thinking. The _owners_ of
Dojo are who asked me to step in and pound these points home, so mind
your own business. ;)
>
> > That's not a bug. There's no crutch for the IE
>
> Again, the tests show you have bugs in lots of areas.
See above. What you see as a bug may not be a bug at all. I will
tell you when I have a chance to look at whatever it is you are
looking at. I'm quite familiar with, for example, Dojo's unit tests
and some of them sniff the UA string, so don't look at them as magical
indicators. They are just code and in many cases may not be suitable
for my design, which varies wildly from theirs.
>
> > No, I don't have the problem at all. The QSA add-on is not needed as
> > the library is certainly fast enough without it.
>
> Other's Up-to-date CSS engines beat yours, in speed and compatibility,
> with or without QSA.
That's a completely worthless statement. And you know it is patently
untrue if you know the first thing about the DOM (and have read any of
their DOM-level code). They can't even get _IE_ right after ten years
of relative quiet on that front. And IE8 is out of the question
(that's when things predictably went from bad to impossible).
http://www.cinsoft.net/attributes.html
>
> > I don't want you to report bugs to me, nor have I asked you to. I
> > don't need your help. Is that clear enough?
>
> Good.
>
> > (particularly TaskSpeed,
> > where my optimized-for-conciseness tests beat the "baseline" PureDom
> > handily).
>
> If your tests are beating PureDom you A) have done your tests
> incorrectly or B) there is a problem with PureDom.
B. PureDom is just a script and it is clearly not optimal. Not only
that, but the various test functions for each library are apples and
oranges. So don't look at those tests as magic either.
>
> > Have you read _anything_ I've written?
>
> Unfortunately I have. Your writings are mostly long multi-post/page
> rants where you reply to yourself or aliases.
That's complete fiction. I've got almost 4000 posts here and maybe
two come from a (well-advertised) alias, due to Google's idiotic
posting limits. Please try to pay attention.
> Repeat the same tired
> arguments over and over again, sprinkle in some name calling/insults,
The same tired scripts are out there fumbling and bumbling, year after
year. Perhaps we should all just ignore their seemingly endless
failings? I, for one, am tired of sites that fall apart for no
reason, other than the developers wanted to be "hip" and use a
"cool" (read: dubious) JS library.
> and you have a classic David Mark post.
You talk about nothing but David Mark, with a few generalizations
about CSS selector engines thrown in. That's worthless noise by any
standard in a technical discussion group.
>
> > And failing?
>
> Yes, your library has bugs in many browsers and versions of browsers.
Another worthless generalization. All things relative, it's far more
solid than anything out there. It's not even comparable to the
"majors" as they all use the same stupid design that short-circuits
the ability to do progressive enhancement.
> So many, in fact, visitors to your g-group, who seem to be relatively
> new to JS, point them out over and over again.
You really are a disingenuous idiot. Are you referring to the users
who are testing ancient browsers (per my request?) No kidding they
found some gaps in the degradation paths and I fixed them all
virtually instantaneously. Compare that to the "majors" that still
can't get the latest version of IE anywhere near straight and take
forever to move on anything, preferring to argue and whine that they
are being embarassed by all of the "complaints".
>
> > They've long since been updated. And what business is it of yours?
> > I still contend the old speed tests are far more telling than comparing
> > QSA results. ;)
> ...
> > Not really. 90% of the SlickSpeed tests take 0ms in the environments
>
> You should try a modified form of SlickSpeed that test max executions
> per ms,
I should try a modified version of SlickSpeed? Why?
> instead of 3 or so calls per test. This gives a more accurate
> indication of performance.
In what sense?
> You will find that your library is actually
> one of the slowest. > > Example:http://davidmissedthemark.com/slickspeed/
According to whatever nonsensical theory you have come up with about
CSS selector engines (which are a stupid idea to begin with).
I haven't tried your link. Is that a joke, or did you really create a
tribute page? You've clearly got too much time on your hands (and a
fixation on me for some reason). Good luck with it!
>
> > No reluctance at all. I don't need to worry about unit tests written
> > by others at the time.
>
> Again, you are missing several basic bug fixes/browser issues because
> you refuse to look at others tests.
Again, see above.
David Mark
[...]
> You should try a modified form of SlickSpeed that test max executions
> per ms, instead of 3 or so calls per test. This gives a more accurate
> indication of performance. You will find that your library is actually
> one of the slowest. Example:http://davidmissedthemark.com/slickspeed/
>
As I expected, you have no idea what you are talking about.
From your twitter account:-
"mylib-domready.js will fail if inline script/html comment has text `</
body>` or if the output buffer is flushed"
Nonsense. If you knew anything, you would know that the test for "</
body>" is superfluous. It doesn't do anything and will be removed
whenever I feel like it. And I've advised anyone who has asked (here)
not to use that add-on as I don't believe it is a good idea (in any
form).
"mylib.js returns wrong for`Array.prototype.x=(a=[]).x=1;
isOwnProperty(a,'x')` and `isOwnProperty(a,'nonexistant')"
That's been answered too (somebody brought it up in my forum). It's
not _wrong_ as the function is not designed to deal with such ill-
advised prototype augumentations. About the worst thing you could say
is my documentation isn't specific enough about such things (as I've
admitted many times here).
"mylib.js API.every, API.filter, API.map, API.push, & API.some don't
follow spec causing cross-browser inconsistencies"
API.push doesn't use the native Array.prototype.push, so throw that
one out. And, yeah, I really should document (the previously
mentioned) cases where the deviations occur with the others (I am well
aware of them). Or maybe I will go ahead and put the extra code in to
handle cases that are basically academic (e.g. undefined values are
skipped due to my purposeful avoidance of the - in - operator).
"A is for Awkward. mylib.js API.setAttribute erases element event
observers when name/type attributes are set in IE."
As mentioned, and discussed here dating back two years, changing the
type and/or name is a novelty (came up on discussing INPUT elements
and the IE bug related to DOM collections). And it's laughable that
you would bring up attributes in IE. The others are completely off
the map when it comes to those. Have a look at what jQuery, YUI,
Dojo, etc. do. Now those are issues that will actually come up (and
for a lot more than two attributes). ;)
And I contend that it does not erase "observers" that were set with My
Library. I am quite sure I will remove that novelty altogether when I
have a chance, which will make this a moot point.
"mylib.js API.getElementSizeStyle may resize elements to 0,0 for
browsers that don't compute style of hidden elements"
Complete and utter nonsense. It's the only solution out there that
deals with variations in box models (e.g. IE quirks mode) and it
certainly does not resize elements to 0,0 as you suggest. Also, I am
sure you meant elements with display style of "none", not "hidden"
elements. Get your terms straight. ;)
"mylib.js attempts to support IE4 (~13yrs old) but fails to support
Safari 2 (~5yrs old) in API.getDocumentWindow"
I've never "attempted" to support IE4, or mentioned virtually anything
about it (other than I can't get it to run in XP). Where do you get
this stuff?
And if getDocumentWindow is unfeasible in the current environment
(whatever it may be), it is "pruned" from the API, along with anything
that relies on it. The others just present the same static API and
allow the calling app to blunder into an exception. Get it?
"mylib.js API.addScript called in the HEAD elem throw an `Operation
Aborted` error in IE6 when a page has a BASE"
You really like the novelties, huh? That's also a purely academic
exercise (and based on Randy Webb's tireless work on the subject). If
IE6 throws an exception when a BASE element is present, it is a bug in
IE6 that should be documented (by both MS and myself). Thanks!
'Hahaha davidmissedthemark.com"
Hey, you've got a friend! But just look at him. :(
"mylib.js css selector engine, getEBCS(), fails a massive amount of
Prototype unit tests"
We've been over that. Using another script's tests agsinst my design
is ludicrous. Taking the results of such a tests at face value is
completely disingenuous. I will evaluate the results when I have
time. Thanks for your concern (but not your ill-gotten conclusions).
"mylib.js API.getComputedStyle converts pt & em units to px but fails
to do so for inch & cm units in IE"
Another novelty! That whole hack is just begging to be removed.
Realize I wrote most of this stuff over two years ago (and, as
mentioned repeatedly, I was laboring under some misconceptions at the
time).
"mylib.js getEBCS() fails tons of jQuery tests on one & bombs the
second."
There you go again. See above.
"mylib.js API.getEBCS fails ~650 Dojo, YUI, Google Closure & Slick
unit tests"
Parse error. :)
Nice try, but beetle-browed babbling from an obviously ignorant nitwit
isn't helping anything. Thanks for the one or two (possibly)
legitimate bugs you have reported so far. :)
jdalton
http://en.wikipedia.org/wiki/Denial
"Denial is a defense mechanism postulated by Sigmund Freud, in which a
person is faced with a fact that is too uncomfortable to accept and
rejects it instead, insisting that it is not true despite what may be
overwhelming evidence."
> You have a very child-like view of this. If I decide (as I did) to
> _not_ allow bizarre markup (e.g. names and ID's that are the same for
> different elements), that is my design choice.
Denial (bugs were not related to multiple identical IDs)
> You aren't following (and are clearly out of that loop).
Denial
> See above. What you see as a bug may not be a bug at all.
True, I have stated some may not be bugs, but a lot are valid bugs in
your code.
> That's a completely worthless statement.
Denial
> And you know it is patently
> untrue if you know the first thing about the DOM (and have read any of
> their DOM-level code).
Denial
> That's complete fiction. I've got almost 4000 posts here and maybe
> two come from a (well-advertised) alias, due to Google's idiotic
> posting limits. Please try to pay attention.
Denial, majority of your posts are rants and you reply to yourself
regularly in your g-group (alias optional).
> You talk about nothing but David Mark, with a few generalizations
> about CSS selector engines thrown in. That's worthless noise by any
> standard in a technical discussion group.
Classic David Mark
> Another worthless generalization. All things relative, it's far more
> solid than anything out there.
Denial
> You really are a disingenuous idiot.
Classic David Mark
> I should try a modified version of SlickSpeed? Why?
Because 0ms results are almost worthless. It's better to see how many
executions can happen in a given time period.
> According to whatever nonsensical theory you have come up with about
> CSS selector engines (which are a stupid idea to begin with).
Your approach is slow, so of course, the entire idea it's based on has
to be stupid. Classic David Mark.
> I haven't tried your link. Is that a joke, or did you really create a
> tribute page? You've clearly got too much time on your hands
Pot calling kettle. Your spamming, ranting, and harassment has reached
new levels since you were relieved from SitePen.
David Mark
[...]
>
> You should try a modified form of SlickSpeed that test max executions
> per ms, instead of 3 or so calls per test. This gives a more accurate
> indication of performance. You will find that your library is actually
> one of the slowest. Example:http://davidmissedthemark.com/slickspeed/
>
Hell, why not?
FF1:-
12 14 9 11* 33 17 9
*Mine
Chrome:-
90 155 48 28* 646 252 160
*Mine
Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your
language?
And, of course, these tests must be run multiple times in a variety of
environments to indicate anything of substance. Still, it sure
doesn't look like "one of the slowest" from the early returns. ;)
jdalton
Heh,
You have it backwards (larger number is better),
smaller is worse, that means your methods executed slower than anyone
else.
Congratulations.
David Mark
> Hi David,
>
> http://en.wikipedia.org/wiki/Denial
> "Denial is a defense mechanism postulated by Sigmund Freud, in which a
> person is faced with a fact that is too uncomfortable to accept and
> rejects it instead, insisting that it is not true despite what may be
> overwhelming evidence."
Uh, thanks for that.
>
> > You have a very child-like view of this. If I decide (as I did) to
> > _not_ allow bizarre markup (e.g. names and ID's that are the same for
> > different elements), that is my design choice.
>
> Denial (bugs were not related to multiple identical IDs)
I addressed all of your reported "bugs" in another post in this thread.
Anything else?
>
> > You aren't following (and are clearly out of that loop).
>
> Denial
Repeating it doesn't make it true.
>
> > See above. What you see as a bug may not be a bug at all.
>
> True, I have stated some may not be bugs, but a lot are valid bugs in
> your code.
Could be. All things relative, it is not a termite farm like the
others. ;)
>
> > That's a completely worthless statement.
>
> Denial
See above.
>
> > And you know it is patently
> > untrue if you know the first thing about the DOM (and have read any of
> > their DOM-level code).
>
> Denial
Sheesh.
>
> > That's complete fiction. I've got almost 4000 posts here and maybe
> > two come from a (well-advertised) alias, due to Google's idiotic
> > posting limits. Please try to pay attention.
>
> Denial, majority of your posts are rants and you reply to yourself
> regularly in your g-group (alias optional).
I certainly do not. I slipped up and posted with my
anti-Google-posting-limit alias once or twice. So what?
>
> > You talk about nothing but David Mark, with a few generalizations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > about CSS selector engines thrown in. That's worthless noise by any
> > standard in a technical discussion group.
>
> Classic David Mark
See what I mean?
>
> > Another worthless generalization. All things relative, it's far more
> > solid than anything out there.
>
> Denial
A broken record.
>
> > You really are a disingenuous idiot.
>
> Classic David Mark
See above. You really are my #1 fan, aren't you?
>
> > I should try a modified version of SlickSpeed? Why?
>
> Because 0ms results are almost worthless. It's better to see how many
> executions can happen in a given time period.
And I tried your tests and the results were predictable (mine is not
even close to "one of the slowest.") What were you testing?
>
> > According to whatever nonsensical theory you have come up with about
> > CSS selector engines (which are a stupid idea to begin with).
>
> Your approach is slow, so of course, the entire idea it's based on has
> to be stupid. Classic David Mark.
My approach is _not_ slow. In contrast, it is blazing fast compared to
the "majors" in some environements and comparable in others. You just
make this stuff up as you go along? Saying "it's slow" over and over in
the face of overwhelming evidence to the contrary is silly.
>
> > I haven't tried your link. Is that a joke, or did you really create a
> > tribute page? You've clearly got too much time on your hands
>
> Pot calling kettle. Your spamming, ranting, and harassment has reached
> new levels since you were relieved from SitePen.
You are just full of misconceptions.
And don't expect a "jdalton" tribute page any time soon. ;)
David Mark
> Hi David,
This is a newsgroup. And what are you replying to?
>
> Heh,
> You have it backwards (larger number is better),
According to you. I have reason to doubt the veracity of your tests,
especially if QSA is involved. All of the other incarnations of
SlickSpeed are BS, but yours is gold? I doubt it. :)
> smaller is worse, that means your methods executed slower than anyone
> else.
But, assuming your tests make sense, that isn't what the data indicated
at all, is it? I would highlight that if you had bothered to quote me. :(
S.T.
> Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your
> language?
It's testing ops/ms, so... yeah... bigger numbers are better. The "final
ops/ms (more is better)" label in the final results is a big giveaway.
> And, of course, these tests must be run multiple times in a variety of
> environments to indicate anything of substance. Still, it sure
> doesn't look like "one of the slowest" from the early returns. ;)
OK. Here's my results.
On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but
ahead of the others. Pretty close top-to-bottom here.
58 99 42 78* 126 114 47
On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools
and Dojo, with the others well ahead.
517 1298 246 162* 2926 1780 1357
On Wn/FF3.6 dead last again, not far behind Mootools at least.
374 435 279 141* 1386 526 458
On IE8 you beat Mootools handily, behind to well-behind the rest.
209 435 64 143* 811 533 476
David Mark
> On 2/9/2010 12:36 PM, David Mark wrote:
>> Oh, what a shock, mine is _fastest_. Does that mean _slowest_ in your
>> language?
>
> It's testing ops/ms, so... yeah... bigger numbers are better. The "final
> ops/ms (more is better)" label in the final results is a big giveaway.
If I had bothered to pay attention to his folly, I would have seen that.
So what?
And who knows what it is testing? Have you looked at the code? Do you
really think there is such a measurable difference between QSA calls? I
don't.
>
>> And, of course, these tests must be run multiple times in a variety of
>> environments to indicate anything of substance. Still, it sure
>> doesn't look like "one of the slowest" from the early returns. ;)
>
> OK. Here's my results.
>
> On IE6 yours fairs alright. Behind JQuery/Sizzle and NWMatcher, but
> ahead of the others. Pretty close top-to-bottom here.
> 58 99 42 78* 126 114 47
On that run. See above.
>
> On Win/Chrome 4.0.249.78 yours is dead last, a little behind Mootools
> and Dojo, with the others well ahead.
> 517 1298 246 162* 2926 1780 1357
Whatever that means. See above.
>
> On Wn/FF3.6 dead last again, not far behind Mootools at least.
> 374 435 279 141* 1386 526 458
>
> On IE8 you beat Mootools handily, behind to well-behind the rest.
> 209 435 64 143* 811 533 476
Again. What makes you think these numbers have any meaning at all?
because "jdalton" said they did?
gf3
WebKit Nightly Version 4.0.4 (6531.21.10, r54448)
834 1317 361 189* 2694 1934 1495
Jussayin'
David Mark
Great! Now if someone can explain why these numbers have any meaning at
all... Otherwise, they are just numbers. ;)
My QSA wrapper is so thin that it makes me think these tests are bogus
or he used my QSA-less version. I don't have the interest to
investigate, but perhaps somebody else will.
AlexSexton
MyLibrary in my tests:
latest Chrome (5.0.317.2)/Vista-x64
592 1290 296 202* 3276 1796 1403
Firefox 3.6
321 395 269 149* 1260 458 419
IE8:
193 383 58 128* 708 479 404
Hell, I'll set up a jdalton tribute site if it makes David Mark wrong
(again)...
David Mark
This is it:-
// QSA add-on uses built-in queries
var global = this;
if (this.API && this.API.getEBCS && this.API.isHostMethod(this.document,
'querySelectorAll')) {
(function() {
var oldGetEBCS = this.API.getEBCS;
var toArray;
try {
(Array.prototype.slice.call(global.document.querySelectorAll('html'),
0));
toArray = function(a) {
return Array.prototype.slice.call(a, 0);
};
} catch(e) {
toArray = API.toArray;
}
this.API.getEBCS = function(s, d) {
try {
return toArray((d || global.document).querySelectorAll(s));
} catch(e) {
return oldGetEBCS(s, d);
}
};
if (typeof $ == 'function') {
$ = this.API.getEBCS;
}
})();
}
Other than the try-catch, I don't see anything between the script and
the browser's built-in queries. The toArray function will be like
lightning in the tested browsers (excluding IE) as well. So what can
these numbers possibly indicate (aside from the fact that "jdalton"
considers them more "accurate" than the original SlickSpeed tests). I
predict it is all a waste of time. ;)
Meanwhile, jQuery still can't read (documents) and "jdalton" is making a
fool of himself on Twitter. There's progress. :)
David Mark
That's what all of this comes down to? Proving me "wrong?" LOL.
Amazing how the losers come out of the woodwork when they think they've
found an in. What do these numbers mean to you, other than they somehow
prove that I am "wrong?" :)
jdalton
> The QSA add-on is not needed as
> the library is certainly fast enough without it.
You said yourself your QSA add-on isn't needed you also don't have it
as an option in your build system (or I couldn't find it)
> Other than the try-catch, I don't see anything between the script and
> the browser's built-in queries.
That's a problem because QSA is buggy across all browsers and you
don't attempt to fix anything. Also many of these selector engines
bypass QSA, for simple queries, altogether.
Here are test results not effected by QSA
IE 7.0.5730.11
32 51 21 39* 73 59 26
IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236
30 50 20 38* 75 59 26
IE 8.0.6001.18702 (Compatibility View)
56 91 33 72* 216 108 62
Opera 9.50 (build 10063)
160 150 55 *68 339 170 128
David Mark
Make sure you mention he's a squirrelly, obsessed cheater. :)
1. As I suspected, he is comparing their QSA with my stock library
(without the QSA add-on). Duh, of course that will make a difference in
these tests. Don't see how that proves me "wrong" about anything
though. Proves him disingenuous (and foolhardy) for sure. ;)
2. He's got an (obviously unneeded) extra dot operation in each call to
mine. Sabotage or stupidity, it really doesn't matter.
This guy has all the credibility of... hell, I can't think of anyone
less credible. VK? Why would anyone go to this much trouble to look
like an idiot?
I wonder how many more losers will show up to celebrate this great
"victory" for incompetence over understanding?
Also, the build he used is 32K _before_ minification, so that supports
the conciseness angle. I suppose I should use such a build on my site
to eliminate confusion about file sizes.
In any event, this is hardly science. ;)
David Mark
> Hi David,
>
>> The QSA add-on is not needed as
>> the library is certainly fast enough without it.
> You said yourself your QSA add-on isn't needed you also don't have it
> as an option in your build system (or I couldn't find it)
I know what I said and I stand by it. It isn't needed at all. The
"standard" TaskSpeed tests bear this out as they are closer to
approximating what an application will do. Your version of SlickSpeed
is obviously going to be affected, but who cares?
>
>> Other than the try-catch, I don't see anything between the script and
>> the browser's built-in queries.
> That's a problem because QSA is buggy across all browsers and you
> don't attempt to fix anything.
So? Of course, it still passes all of these tests. I'll deal with
feature testing QSA when I get around to it. As I've mentioned, QSA
isn't needed. And adding one-off feature tests won't affect any of the
speed tests cited so far as they already _pass_ (so there will be no
bypass).
And are you really congratulating the "majors" for stacking one
patchwork on top of another? Does that make any sense at all? I know
it makes sense to them as they think they have to "keep up" with each
other. The reality is that each layer is full of bugs, particularly the
ones they've been working on non-stop for years (DOM traversal and
XPath). Now they are off on another tangent. How does that help
anything but their egos? Users don't really care (or know) about speed
tests.
> Also many of these selector engines
> bypass QSA, for simple queries, altogether.
Yes, they call gEBI, gEBTN, etc., just as I do in the "slow lane".
What's your point?
>
> Here are test results not effected by QSA
>
> IE 7.0.5730.11
> 32 51 21 39* 73 59 26
>
> IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236
> 30 50 20 38* 75 59 26
>
> IE 8.0.6001.18702 (Compatibility View)
> 56 91 33 72* 216 108 62
Interesting you went with an (almost) all-IE line-up this time. More
chicanery? And don't talk to me about IE compatibility view. None of
the others came close to working in IE8's various modes and they spent
months working with the Beta versions, twiddling their browser sniffing,
etc. In contrast, I did _nothing_ and was pleasantly surprised when
_everything_ still worked on first load in IE8. ;)
>
> Opera 9.50 (build 10063)
> 160 150 55 *68 339 170 128
Looks pretty inconclusive (not to mention spotty) now. So much for your
"more accurate" tests. ;)
Where's Webkit?
gf3
Well, at least you're humble.
David Mark
[...]
>> In any event, this is hardly science. ;)
>
> Well, at least you're humble.
You seemed to have missed something as that response makes no sense in
context. And get a real name. Who is going to listen to initials?
S.T.
> And get a real name. Who is going to listen to initials?
I will!
David Mark
But then who will listen to you? :(
David Mark
[...]
>
> "mylib.js API.getElementSizeStyle may resize elements to 0,0 for
> browsers that don't compute style of hidden elements"
>
> Complete and utter nonsense. It's the only solution out there that
> deals with variations in box models (e.g. IE quirks mode) and it
> certainly does not resize elements to 0,0 as you suggest. Also, I am
> sure you meant elements with display style of "none", not "hidden"
> elements. Get your terms straight. ;)
>
And furthermore, if he bothered to pay attention here, he would know
that I frequently ridicule the "majors" for jumping through hoops to
"normalize" the height/width of elements that are not part of the
layout. Hint: elements that are not part of the layout have no
height/width (or can be considered 0,0). So once again, "jdalton" has
identified a non-bug. He's showing his roots as most of these are the
sorts of things Prototype wasted time on over the years, rather than
trying to fix the problems that matter.
I will address this in the documentation (where it belongs). Trust me
in that you do not want such "normalization" as it hides mistakes in the
calling app (e.g. you shouldn't be trying to measure elements that have
no actual dimensions). ;)
JQuery is even more ludicrous in that it "normalizes" CSS height/width
to fit the one box model they've heard of. So there is really nothing
practical you can do with the measurement (e.g. adjust it). :)
Credit to MooTools for not going down this particular road to nowhere.
It's the one thing they did right. :)
David Mark
> Hi David,
>
>> The QSA add-on is not needed as
>> the library is certainly fast enough without it.
> You said yourself your QSA add-on isn't needed you also don't have it
> as an option in your build system (or I couldn't find it)
>
Not sure if you are aware of it, but you've got the wrong end of the
stick (at the moment) with the builder. Some of your carps are about
issues that have been fixed in the scripts on the Downloads page. Yes,
those are minified. Tough shit. If you really want to know, you can
get around that.
As mentioned several times in my forum, I haven't updated the builder's
source in a couple of weeks as there have been a lot of additions (as
well as a few bug fixes). It's been a hell of a first month for this
thing. The original code that has sat around for two years is
irrelevant now (except perhaps to those who are grasping for any excuse
to denigrate).
And good luck with the whole insanity thing. We're done here.
Andrew Dupont
> I agree 100%. That is where most of them fail miserably (e.g. jQuery
> "punts" on IE quirks mode, none of them handle attributes properly,
> etc.)
This is the most hilarious thing you've ever said, David. There needs
to be a word for someone who behaves exactly like a troll, but is
completely sincere. I feel like I'm a shaman who just met my first
albino.
It's a miserable failure for jQuery to "punt" on quirks mode? Was it a
_different_ person named David Mark who said:
> That's been answered too (somebody brought it up in my forum). It's
> not _wrong_ as the function is not designed to deal with such ill-
> advised prototype augumentations.
And also:
> You have a very child-like view of this. If I decide (as I did) to
> _not_ allow bizarre markup (e.g. names and ID's that are the same for
> different elements), that is my design choice. I want the developer
> to know they are screwing up in that case. Other libraries took a
> different tack.
In other words, what you call a "design choice" when referring to your
library is a "punt" when referring to jQuery. I can see only one
surface difference: jQuery's punts are documented, whereas your design
choices are only publicized after a lengthy Usenet discussion.
No doubt you have some sort of rationalization for this. You'll likely
argue that jQuery is not "designed" but rather the weekend project of
some number of monkeys and typewriters.
When users run afoul of our frameworks' design choices, they can find
guidance on mailing lists and in IRC. Kind souls will explain the
reasoning behind the design choices and steer the questioner back onto
the beaten path.
When others point out failing or surprising results in _your_ code,
David, you snort and mumble something about design choices. No wonder
it's called "My Library" — it's clearly meant only for you. Nobody
else can read your mind. Nobody else understands why your design
choices are jQuery's punts.
This newsgroup is a comedic wonder. Don't ever change, guys.
Cheers,
Andrew
David Mark
> On Feb 9, 12:40 am, David Mark <dmark.cins...@gmail.com> wrote:
>> I agree 100%. That is where most of them fail miserably (e.g. jQuery
>> "punts" on IE quirks mode, none of them handle attributes properly,
>> etc.)
>
> This is the most hilarious thing you've ever said, David.
Is it? Perhaps you've been asleep for the last few years (or working on
Prototype, which is roughly the same thing).
> There needs
> to be a word for someone who behaves exactly like a troll, but is
> completely sincere. I feel like I'm a shaman who just met my first
> albino.
You have an albino?
>
> It's a miserable failure for jQuery to "punt" on quirks mode? Was it a
> _different_ person named David Mark who said:
>
>> That's been answered too (somebody brought it up in my forum). It's
>> not _wrong_ as the function is not designed to deal with such ill-
>> advised prototype augumentations.
>
> And also:
>
>> You have a very child-like view of this. If I decide (as I did) to
>> _not_ allow bizarre markup (e.g. names and ID's that are the same for
>> different elements), that is my design choice. I want the developer
>> to know they are screwing up in that case. Other libraries took a
>> different tack.
>
>
> In other words, what you call a "design choice" when referring to your
> library is a "punt" when referring to jQuery.
A design choice is a conscious decision (as in returning null to signify
a failure in the markup). jQuery claimed for years that it worked in
quirks mode. That was proved wrong (by my reviews), so they "announced"
in their forum that they were "punting". That's ridiculous for a script
that claims to "smooth over" browser differences. And IE quirks mode is
not the only way to get varying box models. See also: XML documents,
XHTML documents, etc., etc. They are constantly surprised (and
irritated) by revelations that should not be revelations to "pro
Javascript" developers. ;)
And do you really think I "punted" because I couldn't figure out how to
loop through all of the ID/name dupes and find the "right" one? You are
quite the comedian yourself.
> I can see only one
> surface difference: jQuery's punts are documented, whereas your design
> choices are only publicized after a lengthy Usenet discussion.
No, see above. jQuery's documentation is pathetic (as is Prototype's).
I've never claimed mine was anywhere near comprehensive, but at least I
understand the code enough to write about it (and I've been writing more
of late). And we discussed the ID/name thing back in 2007 during the
CWR project. As far as I am concerned, returning null to signify an
underlying problem with the markup is far superior to superficially
glossing over it.
>
> No doubt you have some sort of rationalization for this. You'll likely
> argue that jQuery is not "designed" but rather the weekend project of
> some number of monkeys and typewriters.
Clearly it is. Again, where have you been?
>
> When users run afoul of our frameworks' design choices, they can find
> guidance on mailing lists and in IRC.
Now that's the funniest thing I've heard all day. Guidance by the
blind? That's a good way to go off a cliff.
> Kind souls will explain the
> reasoning behind the design choices and steer the questioner back onto
> the beaten path.
Not hardly (stifling uproarious laughter). Do some research. Their
forums are full of clueless meanderings, but largely bereft of informed
advice. Often the programmers are more confused than the users.
>
> When others point out failing or surprising results in _your_ code,
> David, you snort and mumble something about design choices.
Nonsense. Visit my forum and realize that the one guy who is finding
"surprising" results _here_ is hardly sincere (his latest folly was
comparing my DOM traversal to QSA).
> No wonder
> it's called "My Library" � it's clearly meant only for you.
Nope. It started out as an example. jQuery is the only one of the
"majors" that tried to imitate its techniques; but, of course, they
failed as they didn't understand what they were aping.
> Nobody
> else can read your mind. Nobody else understands why your design
> choices are jQuery's punts.
You really like to generalize, don't you? Do you consider their
attr/removeAttr BS to be a "punt?" If so, go back about two years and
start reading.
>
> This newsgroup is a comedic wonder. Don't ever change, guys.
>
And what does this newsgroup have to do with My Library?
And never mind "punts", how about forfeits:-
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/bf5fdb575cd7b354
Every one of those browser sniffs is an admission by the developer(s)
that they couldn't make their designs work, so opted instead to put up a
false front so that the users can delude themselves into thinking their
applications are cross-browser. And then the next versions of the three
or four "supported" browsers come out and it is back to the drawing
board (re-download the whole sorry mess again, re-test everything).
It's an endless cycle of futility. And none of this is news. Your
"rock solid" library is a pile of horse feathers.
Start here:-
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html
...and maybe one day you will be competent to write cross-browser
scripts. Until then, please stop trying to save the world from the
"buggy" browsers with your non-solutions. Thanks!
jdalton
> Interesting you went with an (almost) all-IE line-up this time. More
> chicanery? And don't talk to me about IE compatibility view.
Glad the word-a-day calendar is working out for you. If I didn't
present IE tests you would probably still complain.
>> Opera 9.50 (build 10063)
>> 160 150 55 *68 339 170 128
>
> Looks pretty inconclusive (not to mention spotty) now. So much for your
> "more accurate" tests. ;)
How so ?
> The original code that has sat around for two years is
> irrelevant now (except perhaps to those who are grasping for any excuse
> to denigrate).
Whatever. Your lib from the builder or from the download page yields
the same results.
> Visit my forum and realize that the one guy who is finding
> "surprising" results _here_ is hardly sincere (his latest folly was
> comparing my DOM traversal to QSA).
Your QSA-addon cannot be considered because it doesn't address any of
the bugs that QSA has. I have provided plenty of results that don't
use QSA and your lib is still one of the slowest.
On Jan 28, 1:18 pm
> Each instance
> of the latter is an admission by the author(s) that
On Feb 9, 7:18 pm
> Every one of those browser sniffs is an admission by the developer(s)
> that they couldn't make their designs work, so opted instead to put up a
Oh dear, he has started to repeat...
Updated tests with the mylib from
cinsoft.net/mylib-downloads.html
WinXP
-----
Opera 9.25
49 81 29 40* 151 90 42
Opera 9.50
159 146 57 112* 347 173 123
Opera 9.64
127 127 47 98* 316 143 108
Opera 10.10
201 352 62 109* 554 426 368
Chrome 1.0.154.36
252 407 139 279* 849 476 448
Chrome 2.0.172.28
267 615 144 335* 1499 830 716
Chrome 3.0.195.21
350 946 161 114* 2160 1333 970
IE6
29 47 18 35* 69 60 24
IE8 (Compatibility View)
61 97 38 81* 234 117 64
Firefox 3.6
244 305 188 99* 922 354 318
OSX 10.4
--------
Safari 2.0.0
1 0 9 1* 10 5 0
Safari 2.0.4
2 0 2 3* 15 0 2
Safari 3.04
17 20 13 15* 54 24 16
Safari 3.1
177 302 84 124* 562 387 362
Firefox 2.0
7 12 7 7* 28 14 7
David Mark
> Hi David,
>
>> Interesting you went with an (almost) all-IE line-up this time. More
>> chicanery? And don't talk to me about IE compatibility view.
> Glad the word-a-day calendar is working out for you. If I didn't
> present IE tests you would probably still complain.
You are still here?
>
>>> Opera 9.50 (build 10063)
>>> 160 150 55 *68 339 170 128
>> Looks pretty inconclusive (not to mention spotty) now. So much for your
>> "more accurate" tests. ;)
> How so ?
How so what? And once again, you've snipped out a good part of what you
are asking me to reply to. Incorrigible.
>
>
>> The original code that has sat around for two years is
>> irrelevant now (except perhaps to those who are grasping for any excuse
>> to denigrate).
> Whatever. Your lib from the builder or from the download page yields
> the same results.
The same results for what?
>
>
>> Visit my forum and realize that the one guy who is finding
>> "surprising" results _here_ is hardly sincere (his latest folly was
>> comparing my DOM traversal to QSA).
> Your QSA-addon cannot be considered because it doesn't address any of
> the bugs that QSA has. I have provided plenty of results that don't
> use QSA and your lib is still one of the slowest.
You have provided no such results. The only results that (falsely)
showed mine as "one of the slowest" was exposed as rigged.
>
>
> On Jan 28, 1:18 pm
>> Each instance
>> of the latter is an admission by the author(s) that
>
> On Feb 9, 7:18 pm
>> Every one of those browser sniffs is an admission by the developer(s)
>> that they couldn't make their designs work, so opted instead to put up a
> Oh dear, he has started to repeat...
It's when people say one thing one week and another the next that
there's a problem. I've been saying much the same thing about browser
sniffing since the early part of the century.
>
>
> Updated tests with the mylib from
> cinsoft.net/mylib-downloads.html
Oh here we go. I could have saved you some time as the differences in
the newer build won't affect these tests (at least not significantly).
I was referring to some of your other "bug reports" (a few of which were
valid, but already dealt with).
>
> WinXP
> -----
>
> Opera 9.25
> 49 81 29 40* 151 90 42
>
> Opera 9.50
> 159 146 57 112* 347 173 123
>
> Opera 9.64
> 127 127 47 98* 316 143 108
>
> Opera 10.10
> 201 352 62 109* 554 426 368
>
> Chrome 1.0.154.36
> 252 407 139 279* 849 476 448
>
> Chrome 2.0.172.28
> 267 615 144 335* 1499 830 716
>
> Chrome 3.0.195.21
> 350 946 161 114* 2160 1333 970
>
> IE6
> 29 47 18 35* 69 60 24
>
> IE8 (Compatibility View)
> 61 97 38 81* 234 117 64
>
> Firefox 3.6
> 244 305 188 99* 922 354 318
It's obviously the same QSA vs. non-QSA con. I've seen the handful of
workarounds in the other query engines for QSA quirks. The idea that
they are complete is ludicrous (as is the idea that you need QSA for
anything but dubious tests). And their "slow lanes" are fantasy code,
so you might as well disallow all of them as they have to fall back to
those in some cases (not to mention that most browsers in use today do
not have QSA at all).
Once I formalize _exactly_ which selectors I will support, I will make
sure that all of the layers (DOM traversal, XPath, QSA) match (and on
more than one random document). From the testing so far, there have
been no issues (not that that proves anything).
I don't even need to test the other libraries as their logic is so
obviously wrong (and deafeningly documented at this point). Basically,
XPath and QSA will be close, but the wheels fall off with DOM traversal
(which means the wheels fall off in IE). I've seen them fail on my
basic test document (most in older browsers, but not all). And (at the
moment), the tests do not do much with attribute-based queries. That's
one of the areas where the others break down. It only takes one
miscount (or exception) to disallow the results.
In the meantime, take my advice and forget about using CSS selector
queries (certainly if QSA is involved). They are obviously inherently
over-complicated error-prone, no matter whose library you use. For
every query-based solution, there are methods available to produce a
query-less solution. Make use of those instead. ;)
For information on which selectors I assert are stable in My Library
(with or without QSA), see the test page:-
http://www.cinsoft.net/slickspeed.html
I'll find out regardless, but anyone who can show that the selectors
tested on that page have problems with my QSA add-on is welcome to speak
up. Eh, except you. I don't care to waste time with loopy lunatics. :(
>
>
> OSX 10.4
> --------
>
> Safari 2.0.0
> 1 0 9 1* 10 5 0
>
> Safari 2.0.4
> 2 0 2 3* 15 0 2
>
> Safari 3.04
> 17 20 13 15* 54 24 16
>
> Safari 3.1
> 177 302 84 124* 562 387 362
>
> Firefox 2.0
> 7 12 7 7* 28 14 7
You know, the further back in browser history I go, the more the others
fail to qualify (due to miscounting or exceptions). It seems highly
unlikely that every one of these things (other than mine) passed every
test. ISTM that several of the "major" frameworks fail my SlickSpeed
tests (which are basically the originals plus a few extra like
.class1.class2) in IE8 (in one mode or another).
jdalton
> You are still here?
Yep
> >>> Opera 9.50 (build 10063)
> >>> 160 150 55 *68 339 170 128
> >> Looks pretty inconclusive (not to mention spotty) now. So much for your
> >> "more accurate" tests. ;)
> > How so ?
>
> How so what? And once again, you've snipped out a good part of what you
> are asking me to reply to. Incorrigible.
I snipped nothing out. That was your reply to the Opera results. If it
was to IE8 compatibility mode then the same question applies. How are
my tests *not* "more accurate" as you seem to be suggesting.
> > Whatever. Your lib from the builder or from the download page yields
> > the same results.
>
> The same results for what?
My previous Slickspeed results, follow along now Mark.
> > I have provided plenty of results that don't
> > use QSA and your lib is still one of the slowest.
>
> You have provided no such results.
Denial
> The only results that (falsely)
> showed mine as "one of the slowest" was exposed as rigged.
No rigging going on. You haven't exposed anything except your
ignorance.
> I've been saying much the same thing about browser
> sniffing since the early part of the century.
That horse has been beaten to a pulp.
> Oh here we go. I could have saved you some time as the differences in
> the newer build won't affect these tests (at least not significantly).
It took seconds to copy the file over no time lost. Yes, as I stated
the results were the same.
> It's obviously the same QSA vs. non-QSA con. I've seen the handful of
> workarounds in the other query engines for QSA quirks. The idea that
> they are complete is ludicrous
No one said any of them are complete, your QSA code *is* 100%
incomplete, at least the others put an effort into fixing the bugs.
> In the meantime, take my advice and forget about using CSS selector
> queries (certainly if QSA is involved).
Some talk from the guy using a cheap QSA hack in his slickspeed tests.
cinsoft.net/mylib-qsa-min.js
cinsoft.net/speedtest_mine.html
> You know, the further back in browser history I go, the more the others
> fail to qualify (due to miscounting or exceptions). It seems highly
> unlikely that every one of these things (other than mine) passed every
> test. ISTM that several of the "major" frameworks fail my SlickSpeed
> tests (which are basically the originals plus a few extra like
> .class1.class2) in IE8 (in one mode or another).
What's your point? If I expand the test to more complex selectors the
others will continue to pass while yours fails.
David Mark
> Hi David,
>
>> You are still here?
> Yep
>
>>>>> Opera 9.50 (build 10063)
>>>>> 160 150 55 *68 339 170 128
>>>> Looks pretty inconclusive (not to mention spotty) now. So much for your
>>>> "more accurate" tests. ;)
>>> How so ?
>> How so what? And once again, you've snipped out a good part of what you
>> are asking me to reply to. Incorrigible.
>
> I snipped nothing out. That was your reply to the Opera results. If it
> was to IE8 compatibility mode then the same question applies. How are
> my tests *not* "more accurate" as you seem to be suggesting.
If you didn't botch the quote, it's a first. And thanks for narrowing
down what you meant by "how so". In a nutshell, you first tested my
QSA-less stock version against QSA, which was ridiculous. And you'd
have probably got away with it if it weren't for some meddling kids. :)
Then you concluded from those results, which were supposedly "more
accurate" (in some unspecified way) for ascertaining the library
performance, that mine was the "one of the slowest". Correct me if I am
wrong (it is getting late), but your second set of numbers didn't show
mine to be "one of the slowest" at all. So which version is accurate
and what exactly does it predict?
>
>>> Whatever. Your lib from the builder or from the download page yields
>>> the same results.
>> The same results for what?
>
> My previous Slickspeed results, follow along now Mark.
Did you read all the way through? You misunderstood what I said about
the difference between the current builder source and what is on the
downloads page. And who is Mark? Do you fancy yourself a drill sergeant?
>
>
>>> I have provided plenty of results that don't
>>> use QSA and your lib is still one of the slowest.
>> You have provided no such results.
>
> Denial
Babbling.
>
>> The only results that (falsely)
>> showed mine as "one of the slowest" was exposed as rigged.
>
> No rigging going on. You haven't exposed anything except your
> ignorance.
LOL. You have your own perspective, that's for sure.
>
>> I've been saying much the same thing about browser
>> sniffing since the early part of the century.
>
> That horse has been beaten to a pulp.
And yet most of the "major" libraries and frameworks are still using
such error-prone methods (almost to the exclusion of anything else).
The only one that even tried (in 2008!) to wean themselves from browser
sniffing was jQuery. Of course...
>
>
>> Oh here we go. I could have saved you some time as the differences in
>> the newer build won't affect these tests (at least not significantly).
>
> It took seconds to copy the file over no time lost. Yes, as I stated
> the results were the same.
And as I stated, that's not surprising.
>
>
>> It's obviously the same QSA vs. non-QSA con. I've seen the handful of
>> workarounds in the other query engines for QSA quirks. The idea that
>> they are complete is ludicrous
>
> No one said any of them are complete, your QSA code *is* 100%
> incomplete, at least the others put an effort into fixing the bugs.
That dog don't hunt:-
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b#
>
>
>> In the meantime, take my advice and forget about using CSS selector
>> queries (certainly if QSA is involved).
> Some talk from the guy using a cheap QSA hack in his slickspeed tests.
> cinsoft.net/mylib-qsa-min.js
> cinsoft.net/speedtest_mine.html
>
>> You know, the further back in browser history I go, the more the others
>> fail to qualify (due to miscounting or exceptions). It seems highly
>> unlikely that every one of these things (other than mine) passed every
>> test. ISTM that several of the "major" frameworks fail my SlickSpeed
>> tests (which are basically the originals plus a few extra like
>> .class1.class2) in IE8 (in one mode or another).
>
> What's your point? If I expand the test to more complex selectors the
> others will continue to pass while yours fails.
>
Define "more complex" selectors? If they are not among those on my
SlickSpeed page (the ones I have asserted to support), then you are just
talking shit again. The point is that the others fail on those basic
tests on that one basic document (and not just in ancient browsers
either), yet seem oblivious to that fact, even after all of these years.
What do they think they are doing latching onto more problems with QSA?
Now, if I add a few rows using one of those simple selectors, which all
of the others assert to support as well, all hell will break loose (in
all but mine, of course). You do understand that, right? If not,
compare the attribute handling in theirs to:-
http://www.cinsoft.net/attributes.html
Should be a real eye opener (talk about incomplete!) ;)
And yes, I've transplanted almost every bit of that into My Library at
this point. You'll also notice that the newer one (from a few months
back) eschews the whole name/type node switcheroo. What does that tell
you? Or perhaps it already told you. ;)
Garrett Smith
> On Feb 9, 12:40 am, David Mark <dmark.cins...@gmail.com> wrote:
[...]
> This newsgroup is a comedic wonder. Don't ever change, guys.
>
*PLONK*
Have a nice day, sucker.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
jdalton
> In a nutshell, you first tested my
> QSA-less stock version against QSA, which was ridiculous.
It depends on the browser. In fact I first posted numbers that didn't
rely on QSA http://groups.google.com/group/comp.lang.javascript/msg/c62007cad51f2404
> And you'd
> have probably got away with it if it weren't for some meddling kids. :)
Gotten away with what ? I never said the tests contain your QSA hack,
erm addon.
> Then you concluded from those results, which were supposedly "more
> accurate" (in some unspecified way) for ascertaining the library
> performance, that mine was the "one of the slowest".
I explained it repeatedly, you must have tuned it out.
> Correct me if I am
> wrong (it is getting late), but your second set of numbers didn't show
> mine to be "one of the slowest" at all.
You are wrong. The majority of my tests show your lib as one of the
slowest.
> So which version is accurate
> and what exactly does it predict?
Both. They aren't inconsistent. You know exactly what it predicts, I
can repeatedly, in multiple browsers, versions of browsers, without
QSA, show that your lib is one of the slowest.
> > My previous Slickspeed results, follow along now Mark.
> And who is Mark?
> Do you fancy yourself a drill sergeant?
Naw, it was a typo it is late :D
> LOL. You have your own perspective, that's for sure.
I guess you do too :D
>> No one said any of them are complete, your QSA code *is* 100%
>> incomplete, at least the others put an effort into fixing the bugs.
>
> That dog don't hunt:-
>
> http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...
>
Yes, talking to yourself again (that's not crazy). Your rant was less
a review and more about nitpicking unrelated things. Again, no one
said any of them are complete, but your QSA code *is* 100% incomplete.
> Define "more complex" selectors? If they are not among those on my
> SlickSpeed page (the ones I have asserted to support), then you are just
> talking shit again.
So when you support dead browsers outside the scope of other
frameworks it's OK to compare your lib to them in that context, but
when I compare valid selectors that others support and you lack
support for that is crossing the line ?
> The point is that the others fail on those basic
> tests on that one basic document (and not just in ancient browsers
> either), yet seem oblivious to that fact, even after all of these years.
They may fail a few attribute selectors or use weak object inference
in places, but your's fails many unit tests as well and lacks robust
selector support. So I guess you're in the same boat. Enjoy the
company.
> You do understand that, right? If not,
> compare the attribute handling in theirs to:-
>
> http://www.cinsoft.net/attributes.html
>
> Should be a real eye opener (talk about incomplete!) ;)
I guess I could say the same about your selector support. Sure they
have bugs, oh well, yours is incomplete and buggy too.
> What does that tell you? Or perhaps it already told you. ;)
It tells me your persistent winking creeps me out.
Andrea Giammarchi
> B. PureDom is just a script and it is clearly not optimal. Not only
> that, but the various test functions for each library are apples and
> oranges. So don't look at those tests as magic either.
PureDOM is optimal and linear for what it does, perform tasks exactly
as they are described but I agree PureDOM should be better described
somewhere in TaskSpeed.
I will create a PureHack/PureCheat version so that games will be
basically over for whatever library and I wonder at that time who
would be interested in PureHack "chart column" anymore ... this is not
interesting to me, nobody needs to demonstrate a direct innerHTML is
faster than a function call with inside the same operation, we all
know this, and it's kinda obvious to me.
However, since devs expectation about PureDOM seems to be the fastest
hack ever, rather than a linear way to solve tasks as described, I
guess this column to compare should be there.
Regards
Richard Cornford
> jdalton wrote:
>> Hi David,
>
> This is a newsgroup. And what are you replying to?
>
>> Heh,
>> You have it backwards (larger number is better),
So nothing like being consistent?
<snip>
>> smaller is worse, that means your methods executed slower
>> than anyone else.
>
> But, assuming your tests make sense, ...
<snip>
A reasonable question, given how botched the 'pure DOM' part of
TaskSpeed turned out to be.
Looking at those test pages I observe that each HTML page that gets
queried makes lots of referees to:-
<URL: http://davidmissedthemark.com/slickspeed/system/blank.gif >
- which all get HTTP 404 responses (with quite a sizable (50Kb) 404
page body). It seems unlikely that failing to find the images would
have much, if any, impact on the results of these test, but it would
be nice to see test set-up functioning correctly before anyone started
using it.
Each of the test pages differ in the 'JS library' that they import and
a single line of code that calls the querying method from that
library, as you would expect. The following is the dojo example of the
actual test function from:-
<URL: http://davidmissedthemark.com/slickspeed/system/dojo.html >
| <script type="text/javascript">
| var context = document;
|
| function getLength(elements){
| return typeof elements.length == 'function'
| ? elements.length()
| : elements.length;
| }
|
| function test(selector){
| try {
| var data, elements, start, end,
| i = 0, comps = 0, distance = 0,
I don't see why these variable declarations are here inside the - try
- block instead of being at the beginning of the function body, but
their location will make no practical difference.
| times = [],
| start = +new Date();
The above is the recording of the start time for this test.
| function once() {
| return dojo.query(selector, context);
This is the line that calls the "library's" selector, and the only
point of difference inside the test function between the different
libraries.
| }
But what is this apparent function declaration doing here (in this
location) at all? ECMAScript syntax rules do not accommodate a
function declaration inside a block, and would not accept the above as
a function expression because then you would have an
ExpressionStatement that started with the - function - keyword, which
is forbidden.
So the only thing that is going to allow the above to be acceptable in
this location is going to be the language implementation supporting a
syntax extension. Most of them do, but there are two distinct styles
of syntax extension that accommodate apparent function declarations in
Statement contexts. The first is the IE style, where the apparent
declaration is seen as a function declaration despite its context and
'hoisted' to the being of the function body, evaluated during variable
instantiation, and so will have no impact here. The second, on the
other hand, is the style of syntax extension that introduces the
concept of a FunctionStatement, which gets evaluated at runtime just
like any other statement. The problem with that is that we have
already recoded the start time, and now we are going to be timing the
act of creating a function object as the result of a
FunctionStatement, but only in environments that provide that
particular syntax extension.
There really never was any need for the - once - function to be
declared inside a Block, and sticking with the vanilla ECMAScript
syntax would have avoided a variation in the test process across
platforms.
| (selector);
And what is this doing here? Either it is doing nothing at all (which
is what ECMA 262 says it should do), in which case why is it here at
all, or it is perhaps some attempt to call the preceding function (as
if it was a function expression, by some syntax extension where
ExpressionStatements are allowed to start with the function keyword).
This could do with being explained/justified.
| elements = once();
|
| do {
| comps++;
| once();
| } while ((distance = +new Date() - start) < 200);
This is the main timing loop. The - once - function gets called once
in order to set - elements -, - comps - is incremented and - once -
called again (meaning it has now been called twice since the start of
the timing), and then the - while - expression is evaluated. This
evaluation of the - while - expression involves the creation of a new
Date object, so the rate of creation of date objects is significant
for the test.
I wonder why the unary plus operator is applied to the Date object, as
the subsequent subtraction operation would force type-conversion of
its operands to numeric, but that is more a little odd than
significant.
The most important thing in this expression is the number 200 at the
end of the expression. It means that if the time reported by the new
Date object is more than 200 milliseconds after the date reported by
the original (start) date object then the - while - loop will be
stopped. That is, this test will terminate as soon after 200
milliseconds as the performance of the query method plus the rate of
Date object creation will allow.
As I have said before; I would not trust timing results that did not
differ from each other by less then 200 milliseconds. Dates in
browsers are just not that precise in the worst cases. Having the
whole test take little more than 200 milliseconds is quite likely to
see the influence of background tasks on the computer combined with
timing inaccuracies render the results meaningless.
Now, suppose that after the first pass through the - do - loop body
the 200 milliseconds has elapsed; the - once - function has been
executed twice, and - comps - has been incremented to the numeric
value of 1. This means that - comp , - as a measure of how many
operations have been performed within the timed period, is 50% off the
correct number. This error is reduced as the number of operations
performed increases, but it does mean the test is going to exaggerate
its built in bias against the worst performing 'library'.
I wonder what the point of assigning the millisecond duration to the -
distance - variable is. When the - do - loop ends this value will
(minus the inaccuracies of javascript Date objects) contain the amount
of time taken for the number of operations actually performed (plus
any function creating resulting form FunctionStatement syntax
extensions, and a certain amount of Date object creation, etc.). So
this value, combined with the - comp - value (if it wasn't up to 50%
inaccurate) should be able to provide the important 'operations pre
millisecond' result of this test. But strangely - distance - is never
referenced again, and so assigning it a value here is just another
operation being timed in the loop.
| return {
| 'time': 0,
| 'found': getLength(elements),
| 'ops': comps / 100
Here (assuming no exceptions have been thrown) the result is returned.
But what is going on here; - comps -, which not quite the number of
operations performed, is divided by a seemingly very arbitrary 100?
The loop is constrained by a 200 millisecond value. The test process
must come in at over 200 milliseconds; dividing by 200 would still not
be the right thing to do, but dividing by 100 seems distinctly odd.
The values reported by these test are certainly not operations per
millisecond, by any reasonable measure of what operations pre
millisecond could mean.
| };
| }
| catch(e){
| if (elements == null)
| elements = { 'length': -1 };
| return {
| 'ops': 0,
| 'time': ((+new Date() - start) / (i || 1)) || 0,
| 'found': getLength(elements),
| 'error': (e.fileName || '?.js')
| .replace(/^.*(\/[^\/]+)$/, '$1') +
| '#' + e.lineNumber + ': ' + e.message
| };
| }
| };
|
| test.name = "dojo1.4.js?1264409293";
|
| </script>
I am afraid that as it stands these tests are a mess, and I would not
attribute any meaning to their results.
Richard.
jdalton
Thanks for the review. The tests were originally generated by PHP (I
am not the original author).
`(selector);` was part of that. If a custom method was defined it
would become `custom(selector)`.
I have made adjustments based on your review. The cost of `new Date`
is not really a concern because it is shared by all tests/libs.
The operations count for each is now higher, because more time is
allowed to pass, but the overall trend of MyLib being one of the
slowest (lowest number of executions per period of time) is unchanged.
IE8 (Compatibility Mode)
5,958 8,362 3,238 5,681* 17,768 8,630 3,499
Opera 9.25
7,675 13,137 4,688 6,599* 25,826 14,941 6,620
Opera 9.50
33,643 31,268 11,725 24,128* 71,395 36,086 27,150
Safari 3.0.4
2,715 2,561 2,333 2,325* 8,794 3,787 2,547
David Mark
> On Feb 9, 8:49 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> B. PureDom is just a script and it is clearly not optimal. Not only
>> that, but the various test functions for each library are apples and
>> oranges. So don't look at those tests as magic either.
>
> PureDOM is optimal and linear for what it does, perform tasks exactly
> as they are described but I agree PureDOM should be better described
> somewhere in TaskSpeed.
Well, that depends on your definition of "optimal".
>
> I will create a PureHack/PureCheat version so that games will be
> basically over for whatever library and I wonder at that time who
> would be interested in PureHack "chart column" anymore ... this is not
> interesting to me, nobody needs to demonstrate a direct innerHTML is
> faster than a function call with inside the same operation, we all
> know this, and it's kinda obvious to me.
You are really defensive. And what is it you plan to do that is "cheating?"
>
> However, since devs expectation about PureDOM seems to be the fastest
> hack ever, rather than a linear way to solve tasks as described, I
> guess this column to compare should be there.
>
Whatever. Is this a contest?
David Mark
> Richard,
>
> Thanks for the review. The tests were originally generated by PHP (I
> am not the original author).
> `(selector);` was part of that. If a custom method was defined it
> would become `custom(selector)`.
>
> I have made adjustments based on your review. The cost of `new Date`
> is not really a concern because it is shared by all tests/libs.
> The operations count for each is now higher, because more time is
> allowed to pass, but the overall trend of MyLib being one of the
> slowest (lowest number of executions per period of time) is unchanged.
As noted in the recent review of QSA tack-ons, your test is rigged
(compares QSA to a script). Thanks for trying though.
[snip bogus results[
jdalton
I don't think prending your argument is valid is getting you anywhere
(honestly it's pathetic). Everyone can see that the overwhelming
majority of browsers I have been reporting don't use QSA. Nothing is
rigged, you simply can't accept that you have *failed* to produce a
faster/more complete alternative.
jdalton
> I don't think prending your argument is valid is getting you anywhere
I don't think pretending...
David Mark
> Hi David,
>
> I don't think prending your argument is valid is getting you anywhere
> (honestly it's pathetic).
What argument is that? Your quoting is abysmal (as always). Did you
mean the argument that demonstrated you are completely full of shit for
trying to pass off a QSA vs. DOM comparison as a valid test? Your
excuse was that QSA is "buggy in all browsers" (or something like that)
and the valiant "majors" have been feverishly working to combat these
issues, but my add-on is oversimplified because it doesn't include the
slew of workarounds present in theirs. Well:-
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b#
> Everyone can see that the overwhelming
> majority of browsers I have been reporting don't use QSA.
All I've seen is that your tests are full of holes. And there's not a
single shred of evidence that the non-QSA browsers show mine as "one of
the slowest". Quite the contrary, I run (relevant) tests on non-QSA
browsers all the time and mine is always one of the fastest (usually the
fastest by a large, even exponential margin), particularly in older
and/or limited environments where it counts. ;)
I consider your "results" to be nothing more than random numbers. And
given your track record of one half-truth (or outright lie) after
another, they could very well be made up. I really don't care at this
point (and hard to imagine anyone else does either, excluding your
various alter ego sock puppets).
And the others are all ill-equipped to handle non-QSA browsers as they
can't even read attributes straight, even with browser sniffing in
place. It's spelled f-o-l-l-y. Get it?
> Nothing is
> rigged, you simply can't accept that you have *failed* to produce a
> faster/more complete alternative.
>
Not hardly. You simply can't admit that you don't know what you are
doing. And you need to stop focusing on queries anyway. How many times
do I have to tell you that they are the least important issue at hand.
Trying for weeks to come up with a query-based test that proves my
library is "one of the slowest" just makes you look like a jackass.
And "more complete?" Are you kidding? Mine works on virtually
anything, past, present and (very likely) future. Theirs are software
of the month clubs trying (and failing) to keep with just the latest
versions of three or four browsers (in their default configurations).
One is almost zero cost of ownership, the others are bottomless money
pits. Get that? ;)
jdalton
> Your excuse was that QSA is "buggy in all browsers" (or something like that)
> and the valiant "majors" have been feverishly working to combat these
I didn't say "feverishly working to combat", but they do put forth an
effort.
> issues, but my add-on is oversimplified because it doesn't include the
> slew of workarounds present in theirs.
Yes it is overly simplified. You are completely ignorant to the issues
because you have failed to research them.
> All I've seen is that your tests are full of holes. And there's not a
> single shred of evidence that the non-QSA browsers show mine as "one of
> the slowest".
Denial. I am curious how do you rationalize using a benchmarking tools
created by MooTools/Dojo devs when you bash them and their
frameworks ?
> Quite the contrary, I run (relevant) tests on non-QSA
> browsers all the time and mine is always one of the fastest (usually the
> fastest by a large, even exponential margin),
Delusional. You aren't running my tests or tests that accurately show
anything.
> I consider your "results" to be nothing more than random numbers. And
> given your track record of one half-truth (or outright lie) after
There is no half truths. I have been consistent.
> another, they could very well be made up.
They aren't.
> point (and hard to imagine anyone else does either, excluding your
> various alter ego sock puppets).
Check the IP addresses from the other posters non map to me.
> And the others are all ill-equipped to handle non-QSA browsers as they
> can't even read attributes straight, even with browser sniffing in
> place. It's spelled f-o-l-l-y. Get it?
You are hung up on the few attribute bugs they have. You don't get it.
> > Nothing is
> > rigged, you simply can't accept that you have *failed* to produce a
> > faster/more complete alternative.
>
> Not hardly. You simply can't admit that you don't know what you are
> doing.
Denial
> And you need to stop focusing on queries anyway.
> How many times do I have to tell you that they
> are the least important issue at hand.
Then why do you promote your false performance ?
> Trying for weeks to come up with a query-based test that proves my
> library is "one of the slowest" just makes you look like a jackass.
Weeks ? I just posted the Slickspeed tests yesterday.
> And "more complete?" Are you kidding? Mine works on virtually
> anything, past, present and (very likely) future.
Delusional.
> Theirs are software
> of the month clubs trying (and failing) to keep with just the latest
> versions of three or four browsers (in their default configurations).
> One is almost zero cost of ownership, the others are bottomless money
> pits. Get that? ;)
Mindless ranting. Ahh that creepy wink again.
David Mark
[...]
So what do you have here anyway? Looks like the typical hand-picked
result set. Why not stay consistent from one post to the next? And why
all QSA-less browsers this time around? Why do we need your hacked
version of SlickSpeed for that? Wasn't the whole point to show more
detail than the 0ms QSA results?
Assuming these are less like random numbers than the previous batches
(and aren't made up).
>
>
> IE8 (Compatibility Mode)
> 5,958 8,362 3,238 5,681* 17,768 8,630 3,499
As mentioned, all of the others are disallowed in compatibility mode
(for reasons that should be obvious to anyone who actually reads this
group). Hint: they can't deal with buggy MSHTML attribute methods.
They don't "punt", they throw a Hail Mary into the stands.
So you threw out your previous attempt at "more accurate" tests and came
up with a new batch. And these incomplete results hardly indicate mine
is "one of the slowest". It's unclear if they indicate anything more
than delusion on the part of "jdalton" and a couple of sock puppets. ;)
>
> Opera 9.25
> 7,675 13,137 4,688 6,599* 25,826 14,941 6,620
>
> Opera 9.50
> 33,643 31,268 11,725 24,128* 71,395 36,086 27,150
>
> Safari 3.0.4
> 2,715 2,561 2,333 2,325* 8,794 3,787 2,547
Odd choices. Do you throw darts at a list of browsers? Or perhaps you
cherry-pick the results that appear to support your ridiculous claims?
Opinion appears divided on the validity of your tests (and the relevance
of the results). Richard says they are meaningless, you say they mean
everything. Who are we to believe? :)
I say none of these rapid-fire query tests has much in the way of
practical value. The TaskSpeed tests are clearly a better approximation
of a Web application. But at least the other SlickSpeed variations (all
but yours) have some modicum of acceptance in the industry.
Every other test out there shows mine as fast (or much faster). Your
pet test, which doesn't seem to have any practical merits at all, shows
it as middle of the pack at worst. So your ravings about "one of the
slowest" would seem to indicate you are a crackpot.
David Mark
> Hi David,
Again, this is a newsgroup.
>
>> Your excuse was that QSA is "buggy in all browsers" (or something like that)
>> and the valiant "majors" have been feverishly working to combat these
> I didn't say "feverishly working to combat", but they do put forth an
> effort.
>
>> issues, but my add-on is oversimplified because it doesn't include the
>> slew of workarounds present in theirs.
> Yes it is overly simplified. You are completely ignorant to the issues
> because you have failed to research them.
>
>> All I've seen is that your tests are full of holes. And there's not a
>> single shred of evidence that the non-QSA browsers show mine as "one of
>> the slowest".
> Denial. I am curious how do you rationalize using a benchmarking tools
> created by MooTools/Dojo devs when you bash them and their
> frameworks ?
>
>> Quite the contrary, I run (relevant) tests on non-QSA
>> browsers all the time and mine is always one of the fastest (usually the
>> fastest by a large, even exponential margin),
> Delusional. You aren't running my tests or tests that accurately show
> anything.
Would that be yesterday's tests or today's? Yesterday's were supposed
to be "more accurate" than something in some way. Today they are
garbage? What about tomorrow's?
>
>> I consider your "results" to be nothing more than random numbers. And
>> given your track record of one half-truth (or outright lie) after
> There is no half truths. I have been consistent.
Anyone who can read English knows that is false.
>
>> another, they could very well be made up.
> They aren't.
Pardon me if I don't take your word for it. You've proven yourself to
be dishonest.
>
>> point (and hard to imagine anyone else does either, excluding your
>> various alter ego sock puppets).
> Check the IP addresses from the other posters non map to me.
>
>> And the others are all ill-equipped to handle non-QSA browsers as they
>> can't even read attributes straight, even with browser sniffing in
>> place. It's spelled f-o-l-l-y. Get it?
> You are hung up on the few attribute bugs they have. You don't get it.
>
>>> Nothing is
>>> rigged, you simply can't accept that you have *failed* to produce a
>>> faster/more complete alternative.
>> Not hardly. You simply can't admit that you don't know what you are
>> doing.
> Denial
>
>> And you need to stop focusing on queries anyway.
>> How many times do I have to tell you that they
>> are the least important issue at hand.
> Then why do you promote your false performance ?
Excuse you? There are two sets of tests on my site. I've said numerous
times which I consider the more relevant. And I didn't invent or
encourage acceptance of either. They are just there.
>
>> Trying for weeks to come up with a query-based test that proves my
>> library is "one of the slowest" just makes you look like a jackass.
> Weeks ? I just posted the Slickspeed tests yesterday.
>
>> And "more complete?" Are you kidding? Mine works on virtually
>> anything, past, present and (very likely) future.
> Delusional.
>
>> Theirs are software
>> of the month clubs trying (and failing) to keep with just the latest
>> versions of three or four browsers (in their default configurations).
>> One is almost zero cost of ownership, the others are bottomless money
>> pits. Get that? ;)
> Mindless ranting. Ahh that creepy wink again.
>
You are not one to talk about creepy. You come off like an obsessed fan
with your tribute page and seemingly endless fixation with my script.
But I know you are simply trying to stop me from derailing whichever of
the "majors" is your current favorite. Good luck with that!
jdalton
I guess people have access to both benchmarks (yours and mine) as well
as the source for both. They can make up their own minds. I am not
cheerleading for any major framework and don't have a fixation on your
script. I just think you are overly critical towards others (endless
nitpicking in code or posts, personal attacks, character
assassination) when your own work is flawed. I wish you treated others
in clj as good as you do in your own g-group (it shows you have the
potential for pleasantness). Good luck.
David Mark
> David,
>
> I guess people have access to both benchmarks (yours and mine) as well
> as the source for both.
I don't have any benchmark. I use what is out there. And you know
_full well_ that the typical library aficionado is neither capable nor
willing to interpret the source. Richard, on the other hand... :)
> They can make up their own minds.
Bullshit. You know you lied. Just admit it. You deliberately posted a
test that pits QSA against non-QSA without a disclaimer. That's not
just goofy, but starkly dishonest. Your excuse about "buggy browsers"
and valiant workarounds by the others was shredded to ribbons in five
minutes:-
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b#
...yet you persist.
> I am not
> cheerleading for any major framework and don't have a fixation on your
> script.
That doesn't fit the evidence (certainly not the latter bit).
> I just think you are overly critical towards others (endless
> nitpicking in code or posts, personal attacks, character
> assassination) when your own work is flawed.
I think you are a disingenuous, obsessed, attention-starved asshole of
the first order. And a complete non-entity in this industry to boot.
How about that?
> I wish you treated others
> in clj as good as you do in your own g-group (it shows you have the
> potential for pleasantness). Good luck.
You get what you put in. Have a nice life (or whatever you have that
passes for one). :)
Andrea Giammarchi
> Whatever. Is this a contest?
TaskSpeed is a contest itself, so, is your one a question?
What I am saying is that PureDOM, as baseline, is fine to me.
A TaskSpeed test not focused on tasks as they are but focused only
into "hacks to score" won't be useful, neither it will demonstrate
anything.
// PureHack
dom.innerHTML = "whatever";
// some lib
function $(dom, whatever) {
dom.innerHTML = whatever;
};
$(dom, "whatever");
----------------------
is there any interest into above test? Consider the DOM a library
itself, with methods to do things in a "linear" way to solve tasks.
This is PureDOM, a baseline to compare DOM methods with libraries
methods, and this makes sense to me while the precedent example test
would be pointless.
It's not about being defensive, it's just about understanding PureDOM
column.
Regards
jdalton
"QSA--buggy in lots of browsers?"
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/7ee2e996c3fe952b#msg_b16895423bcb4731