Scott said:
Yup, a number of problems there. Interestingly the fastest libraries
in my only test (FF3.6)
FF3.6 should be considered the Snoopy run (for children and the
disabled). Try - for example - Opera < 9 or FF1 (or any version of IE).
(JQ1.3.2, MyLib, Dojo1.3.2, JQ1.4.1,
Dojo1.4.0, and PT1.6.1, in that order) were the ones that also seemed
to have the fewest problems. Is that due to the leveling effect of
QSA?
Sure it is. Now, go back a version (library or browser) and watch
things fall apart. This is what I've been saying. Just because they
come out with a new library every six months does not mean that every
site will suddenly upgrade (quite the contrary as they _always_ break
compatibility). Furthermore, just because some clueless developer
decides that IE6 - for example - doesn't matter anymore, doesn't mean
that people are not still using it. Testing just the latest browsers
with QSA-enabled libraries is _almost_ meaningless. Of course, QSA is a
whole new playing field for them to tear up. Near as I can tell, they
are going at it with the same sluggish apathy as they did DOM and XPath.
The results are predictable and really very sad as such endless
futility will likely kill browser scripting for good.
You still don't get to disqualify them!
I mean I am giving the medal back as I don't feel it is justified to
call something the fastest if it doesn't pass all of the (supported)
tests.
I did misunderstand. But please do recognize that any performance
tests, especially against fast-changing libraries is always a snapshot
in time.
Fast-changing libraries is the whole problem. They never needed to be
fast-changing. Lots of twits think they are in a race against each
other, so they keep piling on the bullshit (ooh, our "major" library is
cooler than _yours_).
And, of course, with browser sniffing you do have to keep maintaining
them forever. It's so completely stupid it makes me want to scream
(especially when I find myself on a site that is wearing out my PC due
to jQuerification).
The results show what was available at that time. Tests can
be bungled, misapplied, or poorly conceived. But if the are
appropriate and competently executed, the results demonstrate the
state of things at that time.
What I meant was that any positive that could be gleaned from the speed
comparisons should be taken with a grain of salt. It failed as far as I
am concerned. One failure in one browser in one configuration for any
of the (supported) tests is unacceptable. Contrast that with something
like jQuery or Dojo. They change their stuff out all the time, yet they
fail all sorts of basic tests, even in the very latest browsers (and
forget anything that came out a few months back). There's a fundamental
difference in philosophy here. They say it is okay to work "well
enough", even if that means taking something that is 100% reliable (e.g.
gEBI, gEBTN, etc.) and turning it into something akin to a coin flip.
And they have to work really, really hard just to tread water at that
level of "proficiency" in just a handful of browsers (what they refer to
as "all browsers" on "all platforms"). I say that is all bullshit. If
you couldn't pull off a CSS query engine, you shouldn't have spent years
trying, failing, deluding developers, proposing patches, pissing off
users, etc.
I won't have much time until the weekend, but I'll try to throw
together another test then.
Cool. The versions on the Downloads page are always the very latest and
are "mirrored" in the repository.
Things like this are very convenient:
select("div.navigation a:not(li.special a)");
Honestly, that looks ludicrous to me. And why on earth would you trust
these things with something so complex when they plainly can't deal with
very basic queries consistently cross-browser (or even in an IE-only
environment?) It's blind faith in people who have earned no faith at
all. On the contrary, after years of failures, everyone should be ready
to either give up on browser scripting or admit that the big open source
projects were not the way.
Sure I can do that with enough code, but that concisely captures a
reasonably complicated bit of work.
Aha, but what makes you think it will be accurate?
I guess because I kept writing more and more complicated element
traversal code, all tending toward something like the CSS query
engines, but without the insight to do it in a generic way, the query
engines seemed incredibly helpful when they first arrived. I've come
to take them for granted at this point.
Major league fucking mistake. I don't know how else to put it.
Sure I could code without
them, but I think I'd be less efficient.
Is it efficient to have to re-do things? And how about re-testing? You
can see that these selector query black boxes are not the magical
cross-browser wonders they are marketed as. How could you use these
things and sleep at night unless you had literally tested _every_
browser in use today? And you'd still have to worry about _new_
browsers. It's pure insanity when they can't even get IE right after
they had years to get ready for it. Hell, none of them even bothered
with the attributes stuff, which I first warned would break IE8 all to
hell back in 2007.
The example above was a real
selector that I really had to code without the benefit of a selector
engine. I think it was on the order of twenty lines of code for me in
2003. I'd probably be more efficient now, but I don't think it would
be quick and easy.
The number of lines is a _very_ poor indicator of efficiency. Write a
function once and be done with it. Don't rely on magical query engines
that aren't.
Of course I'm introducing a dependency that I don't know as intimately
as I do my own code; that's always an issue.
Especially when the authors don't know it very well either.
But I do that all the
time. I certainly have not written my own HTTP server (ok, so I have,
but that's not the point: I don't *use* it!) or my own encryption
library, or any of a myriad of other tools I use so long as they seem
to work for me.
That's not the point. These are dubious scripts written by half-ass
weekend warrior programmers, not real software. The confusion may come
from the fact that some of these "warriors" have been picked up by real
companies that don't know any better (browser scripting is a bit of a
mystery for most people).
Browser scripting is a bit more problematic because
of the number of distinct platforms I need to support, but as I don't
feel the need to support Lynx or Netscape 4, I can restrict the test
environment to a large, but manageable subset.
You got it straight that browser scripting is more problematic. You
better believe it. And the wares available are of relatively poor
quality. Do the math.
Clearly browser sniffing is, to say the least, well past its prime.
It never had a prime, unless you count the mid-nineties.
I
can't agree that it invalidates the libraries or their test results.
Of course it does. Look at how the results shift from one column to the
next. It's the whole sad history laid out for you. The influence of
outrageous foolishness is unmistakable. Now, look at the third
dimension here (time). Compare - for example - Opera 8, 9 and 10 and
notice that as they moved to "support" the next version, they broke the
previous. Nobody went out and notified all of the users, of course, and
the users don't care what browser scripting nitwits think anyway (they'd
slam the door on them for sure). IE 6, 7, 8 is also an interesting
progression. It becomes quite clear why they keep whining about
"dropping" IE < 8. They are out of their tiny little minds, of course
(IE8 can mimic IE7 with the touch of a button), but their motivations
are quite clear: they are tired of looking stupid. I say smarten up
rather than saying things that add to the perception of stupidity (like
dropping IE < 8). Be fair, they are likely more ignorant than stupid,
but why split hairs?
But as long as the libraries are depending upon it, they will forever
be scrambling unless some very clear and nearly universal DOM-
scripting standards are available.
Yes, scrambling is an apt term for that. As a site owner or Web
developer, you want to steer well clear of their mad scrambling. It's
very bad for business (not to mention morale). I find it very
irritating too, but that's just me.
Test-driven development means to me writing specifications in terms of
tests that need to be passed. It has little to do with twiddling
except that every regression ever created should have its own test.
As I mentioned, your test-driven development is not the same as my
"test-driven" design/development. I am referring to stupid shit like
un-declaring all globals because some half-wit (or two) reported that it
made the library "faster" in some version/configuration/simulation of
IE. True story. The jQuery people didn't do that one, but are famous
for similarly bizarre design decisions where dubious test results are
substituted for research and thinking things through. It's like they
are trying to conserve brain cells. In any event, it bears no
resemblance to science (other than the junk variety).
