jQuery vs. My Library

[David Mark]

I agree, though probably in a different way than you.
Probably.


I'm curious, do you have any predictions?

The sun will rise tomorrow.

Goals? Time lines?

What are those?

What
exactly are you trying to accomplish and how will you know if you've
achieved it?

I don't know. Do you know why you do everything? The short-term
results has been a couple of new clients. I'm happy with that for the
moment. Destroying jQuery (and everything like it) would be a plus as
well. The world is really better off without such scripts.

 

[S.T.]

An uninspiring look? Or do you mean uninspiring looks? And it's just a
mock-up waiting for some real content (e.g. some custom graphics).
Leave it alone.

And what the hell does the look have to do with the scripting? And what
does that 15K script (uncompressed, but minified) have to do with My
Library. It's like you are watching everything intently but somehow
mixing everything up. Glad you stopped to ask questions.

My mistake. I thought the code at the bottom of the page was the
compressed library followed by some actual use of the library. Looked
similar in a glance at least. Whatever.

So it's not being used, as best I can tell. That's not an insult to a
young library necessarily, but does make it harder to evaluate and
certainly question whether the bold claims you make have been adequately
vetted.

That's the API. And what is curious about names like createElement,
createFlash, getEBI, getEBTN, setOpacity, etc.? As mentioned
repeatedly, there's an OO layer that you can take or leave. Looks a lot
like jQuery too (just makes more sense).

Uh huh... Somehow I'm not shocked you feel you've perfectly nailed the
naming aspect, seeing as how you wrote it.

No. Legacy browsers is a red herring. The point of testing on as many
lesser browsers as possible is to expose cracks in the feature detection
and testing logic. That's all. You've got to figure that if the entire
build can load and run in NN4.7, as well as IE8, chances are good for
virtually anything else out there (and the future). Really good.

Makes some sense.

You said all of that shit, not me. But if you think Resig has anything
on me when it comes to cross-browser scripting (or programming in
general), you are sadly deluded.

You may be right. I don't know and don't really care. I'm now bored with
the rest of your post.

I will say Resig is WAY ahead of you in cross-browser library
development, in the sense that he's done so with widespread adoption and
extraordinarily high user satisfaction while you have yet to do so.

So far you've written a script that apparently passes some test cases.
Your grade in the library venue would be an 'incomplete' so far. The
fact that you believe that by merely releasing a library you've a) now
achieved success and b) will surely win the developer community's heart
if they would only take a few moments to look at it is the reason this
project is presently headed towards failure (or, at least, obscurity).

Here's some free advice, which you'll no doubt ignore or more likely
rant about instead, but I'll offer it anyhow.

If you actually want your library to gain some traction:

1. Figure out your target demographic. I get that you feel it's not
merely the best, but the ONLY solution for a cross-browser DOM library
-- but honestly... it's not. Craft your demos, documentation, community,
etc towards a subset of the development community and speak to them.
Don't try to pull every would-be library user with you. I would
recommend the more experienced JS base. Other subsets will follow if you
can succeed with the first.

2. Promote the library on its merits rather than some net kook bash-fest
on other open source projects that appears to be your present approach.

3. Diplomacy. Related to the above. Get into your frenzies in random CLJ
threads all you want but when it comes to discussing your library, even
if someone bashes it, display unwavering tact. Crazy rants don't inspire
confidence in potential community members.

4. Take criticism better and scale back your ego. Related to the above.
For instance getting featured on Ajaxian was a huge opportunity to reach
a large and targeted audience. If your goal is to actually see the
library used, you getting virtually blacklisted from them was an
enormous blunder.

That's what I'd suggest. Unfortunately I seriously doubt you'll do any
of this and sadly (assuming your library has merit) I'm almost certain
your library will remain in near total obscurity as a result. Maybe I
could beat Kobe Bryant one-on-one in basketball, but I'll never get a
game for anyone to find out. Likewise your library is never going to get
a shot at taking on the "majors" out there because your non-technical
approaches to the library are painful to watch.

 

[David Mark]

My mistake. I thought the code at the bottom of the page was the
compressed library followed by some actual use of the library. Looked
similar in a glance at least. Whatever.

Indeed. Doesn't really matter.

So it's not being used, as best I can tell.

By lots of public sites? Not that I know of. But it is being used.

That's not an insult to a
young library necessarily, but does make it harder to evaluate and
certainly question whether the bold claims you make have been adequately
vetted.

Yes. Of course, there is no such ambiguity with jQuery. Even the
lamest of claims can be blown off as bluster.

Uh huh... Somehow I'm not shocked you feel you've perfectly nailed the
naming aspect, seeing as how you wrote it.

I don't think I've perfectly named anything, but it is hard to imagine
another name for createELement or setOpacity.

Makes some sense.

You have to be ready for about anything these days. It seems like there
is a new browser every other day and people are starting to actually use
them on the go.

You may be right. I don't know and don't really care. I'm now bored with
the rest of your post.

I am very sorry to hear that. Your entertainment is paramount, of
course.

I will say Resig is WAY ahead of you in cross-browser library
development, in the sense that he's done so with widespread adoption and
extraordinarily high user satisfaction while you have yet to do so.

Um, that's cross-browser library _marketing_. And his users
satisfaction is unmeasurable, but I'll generalize and say it is in the
toilet.

So far you've written a script that apparently passes some test cases.

There's a ringing endorsement.

Your grade in the library venue would be an 'incomplete' so far.

In other words, I haven't marketing a free library. I likely never
will. Suddenly people are discovering it, so I am accommodating them.
I always said I would if there were interest. I never set out to beat
people over the head with it as I'm not in the business of selling free
libraries (I'm in the business of selling very dear consulting).

The
fact that you believe that by merely releasing a library you've a) now
achieved success and b) will surely win the developer community's heart
if they would only take a few moments to look at it is the reason this
project is presently headed towards failure (or, at least, obscurity).

Where do you get this stuff? Did I say any of that? And I hardly think
it can be a considered a failure compared to the futility that has come
before it. Not much chance of obscurity though. That ship has sailed.

Here's some free advice, which you'll no doubt ignore or more likely
rant about instead, but I'll offer it anyhow.

Oh brother. Thanks so much for the charity.

If you actually want your library to gain some traction:

1. Figure out your target demographic. I get that you feel it's not
merely the best, but the ONLY solution for a cross-browser DOM library
-- but honestly... it's not.

No, really. At present, it is the only comprehensive JS framework out
there that eschews 1990's era browser sniffing. The others are buried
in it (and soon to be buried with it). Check it out.

Craft your demos, documentation, community,
etc towards a subset of the development community and speak to them.

I do need to get some volunteers to work on the documentation as I am
too busy at the moment. That's the biggest weakness.

Don't try to pull every would-be library user with you.

I'm not. Other than those who pay for my consulting services, I
couldn't care less what anybody uses (it's their funeral).

I would
recommend the more experienced JS base. Other subsets will follow if you
can succeed with the first.

It seems too much like a strategy to me. I prefer chaos.

2. Promote the library on its merits rather than some net kook bash-fest
on other open source projects that appears to be your present approach.

No, that's your idiotic interpretation of my posts criticizing your
favorite blob of browser scripting (jQuery wasn't it?)

3. Diplomacy. Related to the above. Get into your frenzies in random CLJ
threads all you want but when it comes to discussing your library, even
if someone bashes it, display unwavering tact. Crazy rants don't inspire
confidence in potential community members.

Apparently you've never been to my community.

4. Take criticism better and scale back your ego. Related to the above.

What criticism? I'm usually the one dishing it out. Do you have any
examples where I reacted badly to criticism?

For instance getting featured on Ajaxian was a huge opportunity to reach
a large and targeted audience.

Oh, alas. And now I've muffed it forever. Get real.

If your goal is to actually see the
library used, you getting virtually blacklisted from them was an
enormous blunder.

You are projecting some sort of power onto those two clods that they
don't have. See how they took the bait and announced they weren't
publishing the article for... spite? LOL. Any credibility they might
have had flew out the window at that point (as I knew it would). One of
their editors is a jQuery "evangelist" as well, so they really have no
credibility at all as journalists. Anyone who thinks they do is too
stupid for words (at least for mine).

That's what I'd suggest. Unfortunately I seriously doubt you'll do any
of this and sadly (assuming your library has merit) I'm almost certain
your library will remain in near total obscurity as a result.

I thought you said it was headed towards obscurity. Here;s a thought.
It can't be obscure when everyone is talking about it.

Maybe I
could beat Kobe Bryant one-on-one in basketball, but I'll never get a
game for anyone to find out.

I think it's a safe assumption he'd school you.

Likewise your library is never going to get
a shot at taking on the "majors" out there because your non-technical
approaches to the library are painful to watch.

Non-technical? Is Ajaxian supposed to be technical in some way? Are
the jQuery people technical people? And if it pains you, why are you
watching?

 

[Scott Sauyet]

Huh?  The Speed Test on my site.  I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin).

Are you referring to this?:

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

Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js


My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40


The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

-- Scott
____________________
[1] http://mootools.net/slickspeed/

 

[David Mark]

Are you referring to this?:

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


Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008.

My Library is from the Fall of 2007 (the query stuff is untouched and
most is a matter of public record). The others are whatever was on the
test page when I copied it. It's not my original work (as noted).

That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

No, it isn't. It may change your interpretation of the results though.
Anything today is going to be a QSA wrapper, so such testing is largely
superfluous. I'll get to that.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support.

Great. It's all a waste of time.

Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed.

So what? And I don't think it is 30%. More like ten of about fifty.
I've mentioned this numerous times and it says it right at the top of
the page. I don't feel it is useful to add all of those selectors, but
estimate it would take me an hour or two to do so. If the users really
care, I'll add them. I wrote the whole engine in a weekend.

Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

They do not cause errors unless you do not follow the instructions.
You aren't allowed to use selectors that aren't supported and the speed
test page is the indicator (as I've mentioned).

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries.

That's not true. As noted, in IE, that test page has two extra elements
added by the Audio module. I should use a build without that module, of
course. I just ran it in Chrome (and have run it in virtually every
browser I have). For "*":-

4 ms | 251 found 8 ms | 251 found 2 ms | 251 found 3 ms | 251 found

All 251. That's what I have seen for years in all but IE.

As for the other one:-

2 ms | 242 found 6 ms | 242 found 4 ms | 242 found 3 ms | 242 found

All the same and I've run this on almost everything. So what are you
saying?

I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

See above.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

Okay, good. You are testing the very latest ones.

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js
Okay.



My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Waste of time. They are all using QSA now, which is incompatible with
their "slow lane" branches. It's stupid. But I can add QSA too. It's
just silly to compare apples and oranges at the moment.

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40

What do these totals even mean if you used selectors unsupported by My
Library?

The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

QSA. You might try IE in compatibility mode to get a level playing
field. But realize that the methods are built into the browsers, so
testing becomes a measure of just the wrappers (where mine will
certainly win again).

Also, you need to run these tests on slower machines. That's where the
results matter anyway. For example, on FF1 on an old XP box, mine
came in thousands ahead of the nearest "competitor". Nobody cares about
a few milliseconds difference on fast machines. It's the phones and
other lesser browsers where speed kills.

I'll run a few tests here on an old machine and post the results...

 

[David Mark]

Huh? The Speed Test on my site. I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin).

Are you referring to this?:

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

Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js


My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40


The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

LOL. Here's a result from a relatively slow machine running FF1:-

999 1561 1107 842 358

The result is far more significant than the above (half of which are
completely irrelevant) combined.

 

[David Mark]

Matt Kruse wrote:
And take a guess which is faster. Rather, don't guess but try the the
Speed Test.
Have you? Will you post the results?
Huh? The Speed Test on my site. I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin).

Are you referring to this?:

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

Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js


My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40


The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

LOL. Here's a result from a relatively slow machine running FF1:-

999 1561 1107 842 358

The result is far more significant than the above (half of which are
completely irrelevant) combined.

Running it the latest Chrome, I did notice the two discrepancies.
Clearly this new test page has exposed some bugs. It can't be the same
content as the last one. I bet I'll fix them and they won't come back.
I'm not shocked that there are bugs in there. I've never claimed
to have tested the CSS selector queries with any sort of seriousness
(I've stated the exact opposite numerous times here).

Thing is, various people (who know who they are) should have been doing
what you are doing two years ago. That's how this project was supposed
to go. But never mind, no time like the present. I wouldn't bother
testing _unsupported_ selectors though.

90 53 209 87 174

Not bad considering the others are using QSA (except perhaps Mootools,
which is still slower two years later). You have to test the fallback
branches to get an indication of how fast the query implementations are.
In fact, that's why my test page is actually better. It's the older,
slower, QSA-less browsers (and other agents) that will expose efficiency
problems. The new ones using QSA will all act about the same. As mine
is competitive even without QSA, it would seem to be the winner.

 

[RobG]

Don't need to elaborate on what I've said when it's all been done for me:

"Someone is critical of a widely used library and at the same time promoting
their own library? Call me cynical, but given the inherent conflict of
interest I'd look for another opinion or 2 before taking their word as the
definitive answer."

What is the point of an anonymous quote?

Initial responses to David's criticisms of various libraries were
along the lines of "you can't criticise it if you haven't written a
library". So he released his own.

Now the response is "you're only criticising it to promote your own".
Whatever.

Regarding the quote itself, should anyone adopt a library for a non-
trivial purpose without thoroughly reviewing it against their
requirements and and seeking expert opinions from various sources? And
if that is a recommended strategy for selecting a library, then how is
advising someone to do it a substantial criticism of MyLibrary?

 

[David Mark]

Matt Kruse wrote:
And take a guess which is faster. Rather, don't guess but try the the
Speed Test.
Have you? Will you post the results?
Huh? The Speed Test on my site. I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin).
Are you referring to this?:

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

Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js


My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40


The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

LOL. Here's a result from a relatively slow machine running FF1:-

999 1561 1107 842 358

The result is far more significant than the above (half of which are
completely irrelevant) combined.

Running it the latest Chrome, I did notice the two discrepancies.
Clearly this new test page has exposed some bugs. It can't be the same
content as the last one. I bet I'll fix them and they won't come back.
I'm not shocked that there are bugs in there. I've never claimed
to have tested the CSS selector queries with any sort of seriousness
(I've stated the exact opposite numerous times here).

Thing is, various people (who know who they are) should have been doing
what you are doing two years ago. That's how this project was supposed
to go. But never mind, no time like the present. I wouldn't bother
testing _unsupported_ selectors though.

90 53 209 87 174

They vary wildly from one load to the next:-

144 174 282 82 164

Clearly the results from Chrome are insignificant (as were most of
yours). Look for _major_ differences in the slower machines. That's
what tells the tale.

 

[David Mark]

Matt Kruse wrote:
And take a guess which is faster. Rather, don't guess but try the the
Speed Test.
Have you? Will you post the results?
Huh? The Speed Test on my site. I've ran it in everything from IE8 to
FF1 (and most in between). My Library kills its contemporaries (the
further back you go, the larger the margin).
Are you referring to this?:

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

Because I see several problems with it. If not, could you let us know
what page we should examine?

The first problem I see is that you're comparing an up-to-date version
of My Library with a version of MooTools that came out in November,
2007, a version of Prototype from January, 2008, and a version of
JQuery from May, 2008. That is certainly enough to invalidate the
results in the fast-moving world of JS libraries.

Second of all, although slickspeed has numerous faults, it has
performed at least one useful service to the ecosystem of CSS selector
engines: it has helped to standardize the collection of selectors
libraries are expected to support. Instead of adding support for
these selectors, you simply remove 30% of the tests from the original
slickspeed. Five of those removed selectors cause errors in My
Library in recent versions of Firefox, Opera, and Webkit-based
browsers.

And third, even among those selectors tested, there are two ("*", and
"div + div") for which My Library returns different values in every
browser than do the other libraries. I haven't gone and counted, and
perhaps My Library is correct, but I'd be surprised if each of the
other libraries got it wrong, yet all got identical values.

I made two new versions based on the original slickspeed [1]. The
first one keeps intact the original selectors. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

I used the latest versions of Dojo, JQuery, MooTools, and Prototype
from:

http://code.google.com/apis/ajaxlibs/

and the version of My Library posted here:

http://www.cinsoft.net/mylib-min.js


My results, all on Win XP SP2 (results in milliseconds, low numbers
are better):

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 56, Proto - 7, MyLib -
30
FF 3.5.7 : Dojo - 58, JQ - 40, Moo - 105, Proto - 58,
MyLib - 75
IE 8 : Dojo - 16, JQ - 16, Moo - 405, Proto - 282,
MyLib - 46
Opera 9.64 : Dojo - 30, JQ - 0, Moo - 94, Proto - 16, MyLib
- 0
Safari 4.0.3 : Dojo - 27, JQ - 25, Moo - 56, Proto - 30,
MyLib - 40


The second version uses the set of selectors from the My Library
page. It's at

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

With the same testing configuration, my results were:

Chrome 3.0.195.27 : Dojo - 4, JQ - 3, Moo - 23, Proto - 13, MyLib
- 13
FF 3.5.7 : Dojo - 34, JQ - 21, Moo - 81, Proto - 50,
MyLib - 53
IE 8 : Dojo - 0, JQ - 0, Moo - 1063, Proto - 31,
MyLib - 0
Opera 9.64 : Dojo - 0, JQ - 0, Moo - 0, Proto - 16, MyLib -
0
Safari 4.0.3 : Dojo - 23, JQ - 15, Moo - 29, Proto - 22,
MyLib - 21


This hardly looks like a win for My Library.

LOL. Here's a result from a relatively slow machine running FF1:-

999 1561 1107 842 358

The result is far more significant than the above (half of which are
completely irrelevant) combined.

Running it the latest Chrome, I did notice the two discrepancies.
Clearly this new test page has exposed some bugs. It can't be the same
content as the last one. I bet I'll fix them and they won't come back.
I'm not shocked that there are bugs in there. I've never claimed
to have tested the CSS selector queries with any sort of seriousness
(I've stated the exact opposite numerous times here).

Thing is, various people (who know who they are) should have been doing
what you are doing two years ago. That's how this project was supposed
to go. But never mind, no time like the present. I wouldn't bother
testing _unsupported_ selectors though.

90 53 209 87 174

Not bad considering the others are using QSA (except perhaps Mootools,
which is still slower two years later). You have to test the fallback
branches to get an indication of how fast the query implementations are.
In fact, that's why my test page is actually better. It's the older,
slower, QSA-less browsers (and other agents) that will expose efficiency
problems. The new ones using QSA will all act about the same. As mine
is competitive even without QSA, it would seem to be the winner.

IE8:

109 15 7330 282 218


See what happens? You lost Mootools. The other differences are
insignificant.

In compatibility mode:-

344 454 4001 6860 328

Wow. Prototype and Mootools (latest versions) are unusable in IE8
compatibility mode. My Library is the clear winner, but not
significantly faster than the other two. This is an older machine, but
hardly a clunker.

The slower the machine, the older the browsers, the wider the margin.
Running such tests on blazing fast machines is a waste of time as the
differences aren't significant enough to be palpable.

 

[john]

LOL. Here's a result from a relatively slow machine running FF1:-

999 1561 1107 842 358

The result is far more significant than the above (half of which are
completely irrelevant) combined.

here are some more results.

<http://www.cinsoft.net/mylib-testspeed.html>
---
54 122 112 38 # Opera 9.64 +
70 121 117 47 # Firefox 3.0.12 +
1 1964 184 2352 # iCab 3.0.5 + *
543 290 191 299 # Internet Explorer 6 -
547 278 187 274 # Internet Explorer 7 -
360 167 135 144 # Internet Explorer 8 -
53 51 1383 1362 # OmniWeb 5.1 + **
940 661 591 611 # Netscape Navigator 6.2.3 -
1147 1451 1303 1377 # iPhone 3.1.2 (7D11)
---

<http://www2.webkit.org/perf/slickspeed/>
---
14529 11520 5827 646 # Firefox 3.6 +
6059 6666 3916 225 # Safari 4.0.4 +
5806 8766 4825 647 # Opera 10.5 pre-alpha -
559 8201 4841 274 # Google Chrome 3.0.195.38 -
# Internet Explorer 8 - ***
---

clearly it is unfair to compare results which use a branch for
QuerySelectorAll capable browsers and a different branch for "old" browsers.

---
+ tested on a relatively fast Mac Pro under "typical" (for me anyway)
system load

- tested in a VMWare virtual machine running XP SP3 with just the tested
browser running.

* My Library miscounts `div:last-child` while MooTools miscounts
`div[class!=madeup]`. Prototype errors on everything and jQuery
miscounts everything.

** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked
version of WebKit from around about January 2005.

*** i think Internet Explorer 8 may have a buggy/incomplete QSA
implementation as it was unable to complete the tests. so i have to
wonder what would happen if something like jQuery were to take the QSA
branch on IE8. errors or a "the script on this page is running too slow"
message i guess. does anyone know if they skip IE8s buggy/incomplete QSA
implementation?

 

[john]

Waste of time. They are all using QSA now, which is incompatible with
their "slow lane" branches. It's stupid. But I can add QSA too. It's
just silly to compare apples and oranges at the moment.

my results confirm the futility of comparing results gathered from QSA
and from the "slow lane" branch. i'd like to see you add QSA to My
Library (and if possible make it aware of the possible quirks in the IE8
implementation of QSA).

 

[David Mark]

here are some more results.

<http://www.cinsoft.net/mylib-testspeed.html>
---
54 122 112 38 # Opera 9.64 +
Cool.

70 121 117 47 # Firefox 3.0.12 +
Cool.

1 1964 184 2352 # iCab 3.0.5 + *

Ah, two of the others bombed out.

543 290 191 299 # Internet Explorer 6 -

That's a horse race. Your VM is much faster than my real (slow) Wintel
boxes.

547 278 187 274 # Internet Explorer 7 -

Definitely much faster than my test machines.

360 167 135 144 # Internet Explorer 8 -

Here we see the effect of taking the standard getAttribute branch.
And it's actually a horse race with jQuery (which is using QSA).

53 51 1383 1362 # OmniWeb 5.1 + **

First two bombed out of course.

940 661 591 611 # Netscape Navigator 6.2.3 -
1147 1451 1303 1377 # iPhone 3.1.2 (7D11)

Woohoo! We support phones too! And ours actually has a shot at working
on them (due to the feature testing). Normal tasks (e.g. creating
elements) should be light years ahead in terms of speed on slow moving
mobile devices as well.

I haven't seen that browser yet. Downloaded it, but haven't installed.

6059 6666 3916 225 # Safari 4.0.4 +

That's what I'm talking about. But this second set of tests is tainted
by the unsupported (by My Library) selectors. Personally, I don't
consider four or five scripts agreeing on one page to be a standard
though. I say we shouldn't try to handle every one of them as most apps
don't need them all.

5806 8766 4825 647 # Opera 10.5 pre-alpha -
559 8201 4841 274 # Google Chrome 3.0.195.38 -

# Internet Explorer 8 - ***
---

clearly it is unfair to compare results which use a branch for
QuerySelectorAll capable browsers and a different branch for "old"
browsers.

Right. I should add the QSA support at some point, but I don't want to
rush into it as I don't see how it will make any palpable difference on
fast machines and I already own all of the old ones (and other lesser
browsers), which don't have QSA anyway. So it can only buy
incompatibility at the moment (something the others picked up in droves).

---
+ tested on a relatively fast Mac Pro under "typical" (for me anyway)
system load

- tested in a VMWare virtual machine running XP SP3 with just the tested
browser running.

* My Library miscounts `div:last-child` while MooTools miscounts
`div[class!=madeup]`. Prototype errors on everything and jQuery
miscounts everything.

** MooTools and Prototype error on everything. OmniWeb 5.1 uses a forked
version of WebKit from around about January 2005.

*** i think Internet Explorer 8 may have a buggy/incomplete QSA
implementation as it was unable to complete the tests. so i have to
wonder what would happen if something like jQuery were to take the QSA
branch on IE8. errors or a "the script on this page is running too slow"
message i guess. does anyone know if they skip IE8s buggy/incomplete QSA
implementation?

I know they don't skip it entirely. More likely they skip it for a
handful of cases where they've observed inconsistencies. Granted,
that's a completely insane approach, but then history always repeats
itself.

There's just no way any of these things should have dove into QSA. But
then these five deluded groups of programmers think they are in some
sort of significant arms race. They think people are too stupid to
realize they are all on QSA now (except in older or lesser browsers
where they are using something incompatible with QSA). These things are
definitely going to die out soon (and I don't necessarily mean because
of My Library).

 

[David Mark]

my results confirm the futility of comparing results gathered from QSA
and from the "slow lane" branch. i'd like to see you add QSA to My
Library (and if possible make it aware of the possible quirks in the IE8
implementation of QSA).

Will do if it turns out to be viable in IE8 (and it will definitely be
optional). I'm going to fix the current branches first though
(combinator problems it appears).

 

[Scott Sauyet]

Waste of time.  They are all using QSA now, which is incompatible with
their "slow lane" branches.  It's stupid.  But I can add QSA too.  It's
just silly to compare apples and oranges at the moment.

Face it. I called your bluff.

You started this off with the following:

| And take a guess which is faster. Rather, don't guess but try the
| the Speed Test. The "do everything" cross-browser script that
| doesn't need dozens of dubious plug-ins is much faster than the
| "optimized" (more like lobotomized) script.

I went and looked at your speed test, which pairs old versions of the
other libraries with your latest and greatest. When I compare yours
with the recent versions of these scripts, your claims were not
substantiated. Or -- excuse me, maybe I misunderstood -- did you
perhaps mean to imply that My Library is the lobotomized script?

Trying to bury this in post after post of results that don't reinforce
your claims only serves to obfuscate.the issue. If there is something
wrong with these two slickspeed tests, please let us know:

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

Otherwise, go ahead and add your QSA code. Feel free to crow
(briefly, please) about your speed when you've done so and are again
at least in the running for the fastest library.

I'd tell you that it's fine to downplay the meaning of these tests,
but you are the one bringing them up as support for the advantages of
your library.

Bluff called.

-- Scott

 

[john]

<http://www2.webkit.org/perf/slickspeed/>
[QSA beating the pants off of javascript selector implementations]

That's what I'm talking about. But this second set of tests is tainted
by the unsupported (by My Library) selectors.

the second set of tests didn't test My Library at all it's:
Prototype 1.6.0.2 / jQuery 1.2.3 / ext 2.0 / QSA

sorry for the confusion.

the point was just to show that QSA is generally an order of magnitude
faster than the fastest javascript implementation; thus results which
don't take that into consideration are useless.

I say we shouldn't try to handle every one of them as most apps
don't need them all.

agreed; but inevitably some one is going to put up a page such as:
<http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/> and
say "This hardly looks like a win for My Library." while not
understanding what has been tested; and inevitably someone with even
less understanding will see the results and decide jQuery must be the
"best".

that being said i still agree some of those selectors are useless
regardless of the speed at which they run. John Resig apparently said
the same: <http://ejohn.org/blog/selectors-that-people-actually-use/>
although that post seems to contradict itself in a couple of places.

 

[David Mark]

Face it. I called your bluff.

And you fell right on your face (again). You only tested a fast machine
and you weren't testing the right thing at all. The QSA branches will
always be about the same (and My Library's QSA-less implementation is
almost as fast as they are). How do you like that?

You started this off with the following:

Oh here we go with the time-wasting.

| And take a guess which is faster. Rather, don't guess but try the
| the Speed Test. The "do everything" cross-browser script that
| doesn't need dozens of dubious plug-ins is much faster than the
| "optimized" (more like lobotomized) script.

I went and looked at your speed test, which pairs old versions of the
other libraries with your latest and greatest.

Which only makes sense as it's an old test and My Library's query module
was written two years ago. Also, it makes no sense to compare QSA
to DOM traversal. Think.

When I compare yours
with the recent versions of these scripts, your claims were not
substantiated.

Sure they were. Keep reading all the way to the end of the thread.
Mine is way the hell faster where it matters (and competitive enough
where it doesn't, even without QSA). Your tests proved me 100% correct.

Or -- excuse me, maybe I misunderstood -- did you
perhaps mean to imply that My Library is the lobotomized script?

Obviously not. But you might want to consider one the way you are going
here. Did you hear nothing Richard told you about speed tests?

Trying to bury this in post after post of results that don't reinforce
your claims only serves to obfuscate.the issue.

But the results (which were not all posted by me) _do_ reinforce it in
spades. It wasn't even a horse race (as predicted).

If there is something
wrong with these two slickspeed tests, please let us know:

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/

That one is irrelevant as it includes unsupported selectors. I'm
telling you and you are alone. There's no "us". LOL.

http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

Yeah, that's the one I used. Were the results unclear? Executive
summary: a massacre. I even posted a link to this thread from my forum.
You should stop making a fool of yourself.

Otherwise, go ahead and add your QSA code.

Do you understand that testing QSA like this is pretty much worthless?

Feel free to crow
(briefly, please) about your speed when you've done so and are again
at least in the running for the fastest library.

Ah, you don't get it. For one, QSA is not compatible with all of the
old bullshit, so they all fucked up by rushing into it. For two, QSA is
built into the browsers. There's no point in running repetitive
comparisons on that. For three, on older and lesser browsers (where
speed variations actually matter), the others are orders of magnitude
slower. Nobody will notice the minor variations in the QSA wrappers on
blazing fast machines. Everybody will notice massive slowdowns on older
PC's, phones, etc. Face it, you didn't understand what you were testing
or why (sound familiar?)

I'd tell you that it's fine to downplay the meaning of these tests,

Who's downplaying them? I clearly won by a landslide. Thanks so much!

but you are the one bringing them up as support for the advantages of
your library.

And you are the one bringing them up now. Thanks again!

Bluff called.

You lose.

 

[David Mark]

<http://www2.webkit.org/perf/slickspeed/>
[QSA beating the pants off of javascript selector implementations]

That's what I'm talking about. But this second set of tests is tainted
by the unsupported (by My Library) selectors.

the second set of tests didn't test My Library at all it's:
Prototype 1.6.0.2 / jQuery 1.2.3 / ext 2.0 / QSA

I get it.

sorry for the confusion.
BP.


the point was just to show that QSA is generally an order of magnitude
faster than the fastest javascript implementation; thus results which
don't take that into consideration are useless.

Exactly. That's what I told the "bluff-caller" who started this
conversation and still doesn't realize he lost.

agreed; but inevitably some one is going to put up a page such as:
<http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/> and
say "This hardly looks like a win for My Library." while not
understanding what has been tested; and inevitably someone with even
less understanding will see the results and decide jQuery must be the
"best".

Oh I know. It's the old Matt Kruse strategy. That's why he put up
tests for selectors that aren't even supported (and it's documented that
they aren't supported). He's trying to make it look like it is broken.
That's also why he only tested (or posted tests from) one fast machine.
He's been told recently that's a losing strategy for speed tests, but
he's not really trying to win (just to come up with results that will
make him look clever). Whatever.

I think I refuted his "call" well enough, but I will definitely add QSA
when I get a chance. Still a bunch of nearly identical results on
really fast machines won't really tell the tale.

that being said i still agree some of those selectors are useless
regardless of the speed at which they run.

No question. What I have in there should be enough for anyone. Granted,
there is a problem with two of them. That bit wasn't BS and I am
grateful for that feedback. As I've mentioned several times over the
years, I don't like CSS selector queries and didn't spend much time on
my implementation (I always figured those who did like them would test
them and help to improve them, but that never happened).

John Resig apparently said
the same: <http://ejohn.org/blog/selectors-that-people-actually-use/>

Yes, he eventually punted (smartly in this case).

although that post seems to contradict itself in a couple of places.

LOL. That's him all over.

 

[RobG]

Trying to bury this in post after post of results that don't reinforce
your claims only serves to obfuscate.the issue.  If there is something
wrong with these two slickspeed tests, please let us know:

   http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
   http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/

I ran the tests on iPhone - they seem to work OK, but for some reason
the results are set a huge distance down the page so it takes several
minutes to scroll to them. Can you fix that please? The result tables
appear briefly just after the text, but then are shifted so it appears
to be something to do with the default CSS being altered by script.

 

[john]

BP.

what does "BP" stand for?

boiling point? badly played? ballpark? best practice? blood pressure?
British Petroleum?