jQuery vs. My Library
in [JavaScript]
|
From: Scott Sauyet on 23 Jan 2010 12:17 On Jan 22, 8:59 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > Scott Sauyet wrote: >> You started this off with the following: > > Oh here we go with the time-wasting. :) Yes, I'm starting to agree that reading your twisting pseudo-logic is a waste of time. When I called your bluff, you tried to change the argument. Do you really think many people care how your code runs on ancient browsers in FF1? When's the last time you say that browser in your logs? If you want to say that the difference in performance is mostly a non- issue, I will certainly agree with you. But you are the one who made a point of bragging about it, and then pointed your latest library against much older versions of the competition. I don't have very old machines laying around to test with. There are four computers in my house; all are slower than the work machine I tested with yesterday, but none are dog-slow; they are all between one and five years old. I've tested three of them, with whatever browsers I still had on them (the majors, all at recent releases on my machine, FF, IE8, and OP on my kids's, FF & IE6 on my wife's.) Perhaps we don't represent average users, but I cover ever browser that has appeared in the logs of three sites I checked. Although the numbers were in most cases higher than I posted earlier, the only changes in relative speeds was that MooTools and Prototype swapped places on my son's Vista machine in both Safari and FF. > Also, it makes no sense to compare QSA to DOM traversal. Think. I have been thinking. I wish you would join me in this endeavor. You say it makes no sense to compare these. The only way I can make sense of that is if you're saying that your techniques are so much better than the previous techniques of the other libraries, and that users should spend their time contemplating the beauty of your code instead of using the best tool for the job. Is that what you mean? If not, why does it not make sense to compare the libraries as they are built? Instead, you seem to be saying, "Well, you haven't hobbled yourself to come down to my level; that's obviously not fair!" > 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.. So your changing your initial argument from saying that yours is faster, then? Not it's simply "way the hell faster where it matters."? Which clearly does not include powerful machines with recent browsers. >> 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. No, sorry, there's only room for one lobotomized participant per discussion, and you've already filled that spot. >> 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. So, you think your lack of support is a *good* thing? >> 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. Why, though, when you provide such a great role model for how to do it? >> 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! :) I think you really believe this. Pathetic! -- Scott
From: David Mark on 23 Jan 2010 12:46 On Jan 23, 12:17 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > On Jan 22, 8:59 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > Scott Sauyet wrote: > >> You started this off with the following: > > > Oh here we go with the time-wasting. :) > > Yes, I'm starting to agree that reading your twisting pseudo-logic is > a waste of time. No. You are the lone twisted voice of illogic here. What is it you don't understand? 1. QSA === no benefit, several drawbacks 2. No QSA === good tests where it matters That's it. ;) > > When I called your bluff, you tried to change the argument. As we have been over (and over), you lost the farm on that bluff. :) > Do you > really think many people care how your code runs on ancient browsers > in FF1? There you go again. I tested lots of modern browsers too. Did you forget or are you just an incorrigible, confusing little sod? > When's the last time you say that browser in your logs? You just don't get it at all, do you? That was one browser tested. One. It thrashes them in FF1-3 and is more than competitive (fast enough) in the QSA-enabled FF3.5. Then there's IE7, IE8, Chrome, etc. > > If you want to say that the difference in performance is mostly a non- > issue, I will certainly agree with you. It's a huge issue in older (or slower) environments. > But you are the one who made > a point of bragging about it, and then pointed your latest library > against much older versions of the competition. No. That test page has been up there since the end of 2007. ;) And, as we've seen, it makes more sense to use that than testing QSA wrappers (where the differences are insignificant). > > I don't have very old machines laying around to test with. Then run browsers that do _not_ have QSA. Then you can get some significant results. ;) > There are > four computers in my house; all are slower than the work machine I > tested with yesterday, but none are dog-slow; they are all between one > and five years old. Great. > I've tested three of them, with whatever browsers > I still had on them (the majors, all at recent releases on my machine, > FF, IE8, and OP on my kids's, FF & IE6 on my wife's.) And...? > Perhaps we > don't represent average users, but I cover ever browser that has > appeared in the logs of three sites I checked. You are still thinking about this in simplistic terms. The point of testing older browsers is to eliminate QSA from the equation. For one, you can put IE8 in compatibility mode to accomplish this. > Although the numbers > were in most cases higher than I posted earlier, the only changes in > relative speeds was that MooTools and Prototype swapped places on my > son's Vista machine in both Safari and FF. So what? > > > Also, it makes no sense to compare QSA to DOM traversal. Think. > > I have been thinking. I wish you would join me in this endeavor. You are the one that is not making sense. AFAICT, I don't _need_ to add QSA at all at this point. It's more than fast enough without it. > > You say it makes no sense to compare these. The only way I can make > sense of that is if you're saying that your techniques are so much > better than the previous techniques of the other libraries, and that > users should spend their time contemplating the beauty of your code > instead of using the best tool for the job. You missed by a mile. There's little difference in the fast PC/QSA results, so they don't really matter. There's a _huge_ difference in the non-QSA results, which will apply to older PC's with older browsers, mobile devices, etc. This where speed matters. Now do you get it? > Is that what you mean? No, but it is clear that my slap-dash selector engine from two years ago is far superior to the "slow lanes" featured in the various "major" libraries. For those end-users stuck in the slow lane, that's a positive boon. > If not, why does it not make sense to compare the libraries as they > are built? We've been over this. We _are_ comparing them as they were built (when testing the latest libraries). One set of results is significant, one is not. > Instead, you seem to be saying, "Well, you haven't hobbled > yourself to come down to my level; that's obviously not fair!" No, that's not what I'm saying at all. If I add a QSA wrapper on top of what I have, the insignificant results will converge a bit more. Who cares? Then there are the significant results, which will never change. > > > 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. > > So your changing your initial argument from saying that yours is > faster, then? It is _much_ faster where it _matters_. > Not it's simply "way the hell faster where it > matters."? Which clearly does not include powerful machines with > recent browsers. In those, they are all about the same as they are using the browser's built-in queries. At that point, the results are insignificant (though it is telling that mine is competitive at that level, even without QSA). > > >> 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. > > No, sorry, there's only room for one lobotomized participant per > discussion, and you've already filled that spot. Twit. > > >> 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. > > So, you think your lack of support is a *good* thing? > > >> 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. > > Why, though, when you provide such a great role model for how to do > it? Again. > > >> 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! :) > > I think you really believe this. Pathetic! Anyone here that doesn't believe it (other than this loser?)
From: Esa on 23 Jan 2010 13:28 On Jan 22, 10:37 pm, Stevo <n...(a)mail.invalid> wrote: > > That'll lead to some fun discussions :) Like calling your band "That > Band" http://en.wikipedia.org/wiki/The_Band
From: Andrew Poulos on 23 Jan 2010 16:12 On 24/01/2010 4:17 AM, Scott Sauyet wrote: > On Jan 22, 8:59 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >> Scott Sauyet wrote: > >>> You started this off with the following: >> >> Oh here we go with the time-wasting. :) > > Yes, I'm starting to agree that reading your twisting pseudo-logic is > a waste of time. > > When I called your bluff, you tried to change the argument. Do you > really think many people care how your code runs on ancient browsers > in FF1? When's the last time you say that browser in your logs? IE 6 is 10 years old and my corporate clients still use it, and won't upgrade any time soon, so ancient browsers are important. > If you want to say that the difference in performance is mostly a non- > issue, I will certainly agree with you. But you are the one who made > a point of bragging about it, and then pointed your latest library > against much older versions of the competition. I have colleagues who work for large development houses that *do* use the "common" js libraries on a day-to-day basis. I learnt very early on to not ask how their latest js project was going because of the violent denunciation of whatever bug they had just discovered and were trying to workaround. (I've been too "afraid" to ask why they don't drop using a library). ap
From: Thomas 'PointedEars' Lahn on 23 Jan 2010 19:09
David Mark wrote: > Garrett Smith wrote: >> Matt Kruse wrote: >>> With so many globals, I would suggest giving them full names as well >>> as the single-letter identifiers. E===Element, etc >>> >> That would conflict with any code that uses:- >> >> Element.prototype.myFunc = [...] > > Yes. It will likely end up as MyElement, MyForm, MyImage, MyDocument, > etc. > > var myEl = MyElement('#test'); Or better myLib.getElement(...), as (structurally) suggested before? PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann |