jQuery vs. My Library
in [JavaScript]
|
From: Scott Sauyet on 22 Jan 2010 20:35 On Jan 22, 5:56 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Scott Sauyet wrote: >> 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. 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
From: john on 22 Jan 2010 20:54 On 22 Jan 7:06 PM, David Mark wrote: > john wrote: >> <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.
From: David Mark on 22 Jan 2010 20:59 Scott Sauyet wrote: > On Jan 22, 5:56 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Scott Sauyet wrote: >>> 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. > > 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. :)
From: David Mark on 22 Jan 2010 21:09 john wrote: > On 22 Jan 7:06 PM, David Mark wrote: >> john wrote: >>> <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. ;) > >> 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". 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. ;)
From: RobG on 22 Jan 2010 21:36
On Jan 23, 11:35 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: [...] > > 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. -- Rob |