Scott said:
Do you *really* need to ask that question when you proceed to make
complaints about it?
The post you referenced to start this thread, begins, "Added :root
pseudo and finished up the positional selectors. Lots of new tests
added to the SlickSpeed page"
New tests, not new selectors. CSS3 has been around for years, as have
the claims of support for them by makes of selector engines. What you
meant to say was that I added variations of the same old CSS3 selectors
(e.g. mth-child(4n+3) as opposed to the usual nth-child(2n+1)). Somehow
, you see this as "cheating", which indicates you don't really
understand what these tests are for.
Six weeks ago, you posted your version of Slickspeed with 28
selectors, down from the original 40 that are usually found in
Slickspeed.
You are wildly mistaken. I posted that roughly two years ago. And it
was perfectly appropriate to remove the tests for selectors I did not
support when I first wrote the library. In fact, there was a disclaimer
that the top that point it out.
When I commented on your reducing the number by 30% you
said that it couldn't be that high; for the record 12 is exactly 30%
of 40.
Um, don't break your arm patting yourself on the back for accuracy. I
didn't count them at all. So what? Is that supposed to make up for all
of this newly posted and misleading nonsense?
I posted a copy of Slickspeed with different libraries but
with the same set of selectors at
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22b/
Yes, we've been over that. You didn't understand at the time about QSA.
We finally got past that (or so I thought). Anyway, so what?
In this thread, you now have 81 selectors.
Yes, adding additional test cases is a good thing.
As your page keeps
changing, my version, with your selectors is here:
Yes, adding non-DIV's to test is a good thing too. Testing DIV's
exclusively is inherently limited (for reasons that should be obvious).
I find myself asking you this a lot, but what's the point in all of
this? It's like you go on and on about nothing and hope that the sheer
weight of it will make naive readers think there is something to it.
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/
And as mentioned before I even posted it. The whole point was that
posting misleading tests is BS. If you still can't see how that
applies to your own post, your blindness is rather stunning.
No, as I explained. You are blind to the fact that 98% (go calculate it
and tell me it is really 97) of the additions are variations of
selectors that are ostensibly supported by the "competition". Do you
not understand that you have to test variations to get anything more
than the same superficial results that have been deluding you (and the
library authors) into thinking all is well?
I'm not sure what "then" you are using here. This was a brand new
version of Slickspeed posted today using the set of selectors you
promoted.
The "then" was when you compared QSA to non-QSA and proclaimed that QSA
was faster.
ISTM you are doing something similar now, proclaiming (admittedly
disingenuously) that an old rendition of mine, which predates any
support for the newly added CSS3 selectors is "broken", "miscounting",
etc. and that the others are "faster", when in fact, the others are
simply handing the queries off to the browsers (using QSA) and have been
demonstrated to screw up lots of them when that crutch is taken away (as
it often is in the wild).
I'm explaining what was wrong with my hypothetical post.
^^^^^^^^^^^^
FYI, That's spelled h-y-p-o-c-r-i-t-i-c-a-l. It's like making an
obnoxious joke and qualifying it with something like "if I were a real
jackass, I would have said..." You said it. You also posted bogus
tests.
By
comparison, you might see some of what's wrong with yours.
No, that was your qualification that was supposed to make you look
gallant and restrained rather than disingenuous and obnoxious.
So, your six-week old version can't handle many of the tests thrown at
it, but you think it's perfectly legitimate to compare it to a 130-
week old version of jQuery. Hmmm.
You really need to get a grip. There are _three_ versions of jQuery on
that page. They are all clearly labeled. It is up to you to interpret
what the results mean to you. Seeing the history of these things has
been a real eye-opener for those who can think straight. It's not a
conspiracy to make jQuery 1.21 look lousy. But then, jQuery 1.21
claimed to support virtually all of the selectors on the page.
And, as for my six-week-old version, it handled exactly what I claimed
it would handle and I listed exactly what was _not implemented at all_
six weeks back. See the difference now? I never even wanted to add all
of these silly selectors, but as there have been requests and tests
posted that made it look broken due to the fact that it didn't support
some "standard" set of selectors...
Again, what are you trying to say?
The whole point is that I wouldn't actually post such misleading
claptrap, and I really wish you would stop doing so yourself.
But you did. That's one of my points. The other is that much of what
you say and do with regard to these SlickSpeed tests is laughably inept
and demonstrates a severe misunderstanding about JS libraries, their
claims, history and how all of this paints a picture of enduring abject
incompetence. The fact that I never wanted to follow in their
footsteps, hadn't really done so six weeks back, did trample them of
late, etc. is irrelevant. Look at the big picture and imagine if I had
never even wrote a library.
And yet you continually bemoan how the so-called major libraries
constantly are being updated without stable releases...
So what? I've never released mine at all. In fact, it sat on the shelf
for over two years, with me telling anyone who would listen not to use
any GP library (including mine). During that time, despite numerous
mistakes on my part, it survived the releases of several major browsers,
including IE8 without my lifting a finger. That demonstrated how the
feature testing beat the hell out of the browser sniffing that was
popular at the time. A month or two back, I started working on it
again, tested all the way back to the late 90's browsers, patched some
holes in the feature detection as a result and will release it when I
feel like it. So what?
And how is adding support for additional selectors the same as endlessly
twiddling with browser sniffing, epiphanies about IE that should have
occurred years ago, etc.? It's not as if I am fixing bugs in my
non-existent release version, am I? As a matter of fact, I'm not fixing
bugs at all. I'm adding features by request (notably from you).
And remember, one of the biggest selling points of those "major"
libraries is that they are so well-tested because they have so many
vigilant users and developers. LOL.
Well, testing that six week old library against your new list, there
were 17 errors and 12 additional wrong answers in FF. On the original
forty Slickspeed selectors, there were 5 errors and 10 additional
wrong answers as can still be seen here:
http://scott.sauyet.com/Javascript/Test/slickspeed/2010-01-22a/
Um, once again, you were testing selectors that I explicitly did not
support, which was plainly documented at the top of the page. I never
claimed (two years ago) to support all forty of those "standard"
selectors (quotes indicate there are lots of variations of this test out
there). So how stupid is it to keep parroting about these imagined
failures? You can't have a failure without an assertion, can you?
Of course you don't have to use the ones you found. You can alter the
document. You can replace the list of selectors.
And what sort of fool wouldn't? The original set of selectors was all
DIV's (as was 99% of the document). How stupid was that?
You can even change
how the timing is determined. As long as it seems clear that the
intent is not to simply make one's own library look better, any of
this is fair game.
And obviously adding (4n+3) and (-2n+1) next to (2n+1) is necessary to
verify that your positional selectors are working properly. What sort
of fools (besides the authors of the original test page) wouldn't do
that? FYI, as mentioned, the primary purpose of that page is to _test_
my engine. Embarrassing the other efforts is just a highly unexpected
bonus.
However, if I were to post a version that included
only those queries at which dojo is fastest, and then tried to use it
to demonstrates the superiority of dojo, others would understandably
object. That is what it seems you are doing.
You are completely full of shit. How is adding lots of additional
positional tests going to make mine appear faster? I can't even fathom
what you are saying. Do you think I studied the ins and outs of all of
the others and determined that this area (which was coincidentally
lacking in the original list) was the perfect place to add more tests to
make mine look faster?! And perhaps adding lots of attribute variations
(which preceded these latest additions) would also make mine look faster
too. Or maybe, just maybe, I want to create as stressful a set of tests
as I can and never mind the impact on speed (an area where I have never
been exactly lacking?) Think about it.
So, is including QSA an appropriate thing to do or not?
Depends on what you are trying to compare, doesn't it?
Not for the
other libraries, for yours?
Huh? AFAIK, the others don't give you any option. That's why you have
to look at their old versions side by side to compare with both of mine
(meaning with and without the QSA add-on). I really hope these concepts
are starting to congeal at this point.
If it is, fine. If it's not, fine.
The
other libraries have made their choices (subject as always to the
vagaries of changing design.)
Huh?
If it's most appropriate to use QSA
with My Library, then stop whining about others including it, and just
use it.
Whining?! I've always included both versions on my tests. End of
story. What you do is really of no consequence, except that it often
exposes your lack of understanding for what your tests are comparing.
If it's not, then live with the fact that others libraries
will probably be faster for a great number of queries, although they
might get things entirely wrong when the native QSA fails. That's
just the way it goes.
Why not compare both and let the users decide what they want. That's
what I did.
The main issue is that tools like Slickspeed are great for minor
bragging rights about speed. They are useful to fix a minimal list of
expected behavior from libraries. When you add selectors like this,
you're obviously trying to use it in a very different manner:
td[title='test1" # . > ~ + test2[1]']
Don't be juvenile. It's a stress test. I added it primarily to make
sure that _my_ parsing was working as expected. You are acting like
this is some sort of contest. Well, there are no prizes and the other
libraries have supposedly had a multi-year-head start on most of this stuff.
What's a head start in something that's not a contest?
I clearly was referring to your use of the word "contest". But call
them efforts as it is more appropriate.
Don't be disingenuous. You are promoting My Library unabashedly
here.
Over using YUI or Dojo or jQuery? You bet. And I hope it is clear at
this point that you really shouldn't use CSS selector queries,
regardless of the library.
I wouldn't have bothered to respond if it hadn't been for your
saying, "I had a feeling that this would create a lot more black cells
in the results table (in anything West of the last two columns of
course). Did it ever." You are treating this as a contest.
No, it is a chart of results. Nothing more. My assertion was that they
would have lots of errors (and miscounts) for these less-than-trivial
additions and they did. So what?
Yes, it looks like MooTools can't handle nth-*: an + b where a is
negative.
Yes. It sends them into an infinite loop, which doesn't speak well of
their QA. Again, the "well tested by many eyes" argument turns out to
be bunk.
No, they are equally BS. That was the point.
Don't write wrong answers on the blackboard as somebody is likely to
copy them down.
I have nothing to add to Peter Michaud's excellent argument in favor
of CSS-selector queries as a DOM-selection mechanism.
Oh Christ, take me now. He had no argument at all. It was the same
generalized BS over and over. It was like he was posting from a coma.
But have you thought about the overall logic of your post at all? The
argument seems to be, "Queries suck. Don't use them. But I'm going
to spend the effort to add them to My Library, so that it's better
than all the other libraries. Just remember not to actually use
them."
Actually, that is what I am saying and it is quite logical. Nobody will
even consider a library if it doesn't have CSS3 selector queries.
That's a fact of life. I say don't even include that crap in the build
(and have always said that). And if I am going to honor requests for
more selectors, I'm going to make sure that they work in as many
browsers and configurations as I can before announcing that they are
available for user. Logical?
In most environments I've worked, I wouldn't be able to
even *try* to suggest that the client consider using MyLib, not when
it's presented in such an arrogant fashion.
Your client is unlikely to read technical posts in my forum. [ ... ]
Many clients want to see the mechanisms for getting help with the
tools I suggest for them. When I point out the helpful community
around Wicket (a Java Web framework) they are much more likely to
accept it as an alternative to the more well-known frameworks.
Java?! So what?
With
My Library, I would have to actively steer them away from your rants
if I ever wanted them to accept it.
Don't be ridiculous. Even my harshest critics have acknowledged that my
support (particularly in that forum) is grade-A. I don't think your
client would care what I said about the other libraries, particularly as
it is all true.
David, as much as you may find this hard to believe, I'm one of the
ones who wants to help I don't think the ecosystem of JS libraries is
anywhere near rich enough.
It's been on the brink of bankruptcy for years.
I really want to see more innovation. But
the style in which you present your library makes it next to
impossible to even give it a chance.
For God's sake, if you want me to make progress (on the code) cut out
these marathon responses.
