TaskSpeed results for My Library
in [JavaScript]
|
From: Andrew Dupont on 9 Feb 2010 19:57 On Feb 9, 12:40 am, David Mark <dmark.cins...(a)gmail.com> wrote: > I agree 100%. That is where most of them fail miserably (e.g. jQuery > "punts" on IE quirks mode, none of them handle attributes properly, > etc.) This is the most hilarious thing you've ever said, David. There needs to be a word for someone who behaves exactly like a troll, but is completely sincere. I feel like I'm a shaman who just met my first albino. It's a miserable failure for jQuery to "punt" on quirks mode? Was it a _different_ person named David Mark who said: > That's been answered too (somebody brought it up in my forum). It's > not _wrong_ as the function is not designed to deal with such ill- > advised prototype augumentations. And also: > You have a very child-like view of this. If I decide (as I did) to > _not_ allow bizarre markup (e.g. names and ID's that are the same for > different elements), that is my design choice. I want the developer > to know they are screwing up in that case. Other libraries took a > different tack. In other words, what you call a "design choice" when referring to your library is a "punt" when referring to jQuery. I can see only one surface difference: jQuery's punts are documented, whereas your design choices are only publicized after a lengthy Usenet discussion. No doubt you have some sort of rationalization for this. You'll likely argue that jQuery is not "designed" but rather the weekend project of some number of monkeys and typewriters. When users run afoul of our frameworks' design choices, they can find guidance on mailing lists and in IRC. Kind souls will explain the reasoning behind the design choices and steer the questioner back onto the beaten path. When others point out failing or surprising results in _your_ code, David, you snort and mumble something about design choices. No wonder it's called "My Library" it's clearly meant only for you. Nobody else can read your mind. Nobody else understands why your design choices are jQuery's punts. This newsgroup is a comedic wonder. Don't ever change, guys. Cheers, Andrew
From: David Mark on 9 Feb 2010 20:18 Andrew Dupont wrote: > On Feb 9, 12:40 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> I agree 100%. That is where most of them fail miserably (e.g. jQuery >> "punts" on IE quirks mode, none of them handle attributes properly, >> etc.) > > This is the most hilarious thing you've ever said, David. Is it? Perhaps you've been asleep for the last few years (or working on Prototype, which is roughly the same thing). > There needs > to be a word for someone who behaves exactly like a troll, but is > completely sincere. I feel like I'm a shaman who just met my first > albino. You have an albino? > > It's a miserable failure for jQuery to "punt" on quirks mode? Was it a > _different_ person named David Mark who said: > >> That's been answered too (somebody brought it up in my forum). It's >> not _wrong_ as the function is not designed to deal with such ill- >> advised prototype augumentations. > > And also: > >> You have a very child-like view of this. If I decide (as I did) to >> _not_ allow bizarre markup (e.g. names and ID's that are the same for >> different elements), that is my design choice. I want the developer >> to know they are screwing up in that case. Other libraries took a >> different tack. > > > In other words, what you call a "design choice" when referring to your > library is a "punt" when referring to jQuery. A design choice is a conscious decision (as in returning null to signify a failure in the markup). jQuery claimed for years that it worked in quirks mode. That was proved wrong (by my reviews), so they "announced" in their forum that they were "punting". That's ridiculous for a script that claims to "smooth over" browser differences. And IE quirks mode is not the only way to get varying box models. See also: XML documents, XHTML documents, etc., etc. They are constantly surprised (and irritated) by revelations that should not be revelations to "pro Javascript" developers. ;) And do you really think I "punted" because I couldn't figure out how to loop through all of the ID/name dupes and find the "right" one? You are quite the comedian yourself. > I can see only one > surface difference: jQuery's punts are documented, whereas your design > choices are only publicized after a lengthy Usenet discussion. No, see above. jQuery's documentation is pathetic (as is Prototype's). I've never claimed mine was anywhere near comprehensive, but at least I understand the code enough to write about it (and I've been writing more of late). And we discussed the ID/name thing back in 2007 during the CWR project. As far as I am concerned, returning null to signify an underlying problem with the markup is far superior to superficially glossing over it. > > No doubt you have some sort of rationalization for this. You'll likely > argue that jQuery is not "designed" but rather the weekend project of > some number of monkeys and typewriters. Clearly it is. Again, where have you been? > > When users run afoul of our frameworks' design choices, they can find > guidance on mailing lists and in IRC. Now that's the funniest thing I've heard all day. Guidance by the blind? That's a good way to go off a cliff. > Kind souls will explain the > reasoning behind the design choices and steer the questioner back onto > the beaten path. Not hardly (stifling uproarious laughter). Do some research. Their forums are full of clueless meanderings, but largely bereft of informed advice. Often the programmers are more confused than the users. > > When others point out failing or surprising results in _your_ code, > David, you snort and mumble something about design choices. Nonsense. Visit my forum and realize that the one guy who is finding "surprising" results _here_ is hardly sincere (his latest folly was comparing my DOM traversal to QSA). > No wonder > it's called "My Library" � it's clearly meant only for you. Nope. It started out as an example. jQuery is the only one of the "majors" that tried to imitate its techniques; but, of course, they failed as they didn't understand what they were aping. > Nobody > else can read your mind. Nobody else understands why your design > choices are jQuery's punts. You really like to generalize, don't you? Do you consider their attr/removeAttr BS to be a "punt?" If so, go back about two years and start reading. > > This newsgroup is a comedic wonder. Don't ever change, guys. > And what does this newsgroup have to do with My Library? And never mind "punts", how about forfeits:- http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/bf5fdb575cd7b354 Every one of those browser sniffs is an admission by the developer(s) that they couldn't make their designs work, so opted instead to put up a false front so that the users can delude themselves into thinking their applications are cross-browser. And then the next versions of the three or four "supported" browsers come out and it is back to the drawing board (re-download the whole sorry mess again, re-test everything). It's an endless cycle of futility. And none of this is news. Your "rock solid" library is a pile of horse feathers. Start here:- http://www.jibbering.com/faq/faq_notes/not_browser_detect.html ....and maybe one day you will be competent to write cross-browser scripts. Until then, please stop trying to save the world from the "buggy" browsers with your non-solutions. Thanks!
From: jdalton on 9 Feb 2010 22:37 Hi David, > Interesting you went with an (almost) all-IE line-up this time. More > chicanery? And don't talk to me about IE compatibility view. Glad the word-a-day calendar is working out for you. If I didn't present IE tests you would probably still complain. >> Opera 9.50 (build 10063) >> 160 150 55 *68 339 170 128 > > Looks pretty inconclusive (not to mention spotty) now. So much for your > "more accurate" tests. ;) How so ? > The original code that has sat around for two years is > irrelevant now (except perhaps to those who are grasping for any excuse > to denigrate). Whatever. Your lib from the builder or from the download page yields the same results. > Visit my forum and realize that the one guy who is finding > "surprising" results _here_ is hardly sincere (his latest folly was > comparing my DOM traversal to QSA). Your QSA-addon cannot be considered because it doesn't address any of the bugs that QSA has. I have provided plenty of results that don't use QSA and your lib is still one of the slowest. On Jan 28, 1:18 pm > Each instance > of the latter is an admission by the author(s) that On Feb 9, 7:18 pm > Every one of those browser sniffs is an admission by the developer(s) > that they couldn't make their designs work, so opted instead to put up a Oh dear, he has started to repeat... Updated tests with the mylib from cinsoft.net/mylib-downloads.html WinXP ----- Opera 9.25 49 81 29 40* 151 90 42 Opera 9.50 159 146 57 112* 347 173 123 Opera 9.64 127 127 47 98* 316 143 108 Opera 10.10 201 352 62 109* 554 426 368 Chrome 1.0.154.36 252 407 139 279* 849 476 448 Chrome 2.0.172.28 267 615 144 335* 1499 830 716 Chrome 3.0.195.21 350 946 161 114* 2160 1333 970 IE6 29 47 18 35* 69 60 24 IE8 (Compatibility View) 61 97 38 81* 234 117 64 Firefox 3.6 244 305 188 99* 922 354 318 OSX 10.4 -------- Safari 2.0.0 1 0 9 1* 10 5 0 Safari 2.0.4 2 0 2 3* 15 0 2 Safari 3.04 17 20 13 15* 54 24 16 Safari 3.1 177 302 84 124* 562 387 362 Firefox 2.0 7 12 7 7* 28 14 7
From: David Mark on 9 Feb 2010 23:07 jdalton wrote: > Hi David, > >> Interesting you went with an (almost) all-IE line-up this time. More >> chicanery? And don't talk to me about IE compatibility view. > Glad the word-a-day calendar is working out for you. If I didn't > present IE tests you would probably still complain. You are still here? > >>> Opera 9.50 (build 10063) >>> 160 150 55 *68 339 170 128 >> Looks pretty inconclusive (not to mention spotty) now. So much for your >> "more accurate" tests. ;) > How so ? How so what? And once again, you've snipped out a good part of what you are asking me to reply to. Incorrigible. > > >> The original code that has sat around for two years is >> irrelevant now (except perhaps to those who are grasping for any excuse >> to denigrate). > Whatever. Your lib from the builder or from the download page yields > the same results. The same results for what? > > >> Visit my forum and realize that the one guy who is finding >> "surprising" results _here_ is hardly sincere (his latest folly was >> comparing my DOM traversal to QSA). > Your QSA-addon cannot be considered because it doesn't address any of > the bugs that QSA has. I have provided plenty of results that don't > use QSA and your lib is still one of the slowest. You have provided no such results. The only results that (falsely) showed mine as "one of the slowest" was exposed as rigged. > > > On Jan 28, 1:18 pm >> Each instance >> of the latter is an admission by the author(s) that > > On Feb 9, 7:18 pm >> Every one of those browser sniffs is an admission by the developer(s) >> that they couldn't make their designs work, so opted instead to put up a > Oh dear, he has started to repeat... It's when people say one thing one week and another the next that there's a problem. I've been saying much the same thing about browser sniffing since the early part of the century. > > > Updated tests with the mylib from > cinsoft.net/mylib-downloads.html Oh here we go. I could have saved you some time as the differences in the newer build won't affect these tests (at least not significantly). I was referring to some of your other "bug reports" (a few of which were valid, but already dealt with). > > WinXP > ----- > > Opera 9.25 > 49 81 29 40* 151 90 42 > > Opera 9.50 > 159 146 57 112* 347 173 123 > > Opera 9.64 > 127 127 47 98* 316 143 108 > > Opera 10.10 > 201 352 62 109* 554 426 368 > > Chrome 1.0.154.36 > 252 407 139 279* 849 476 448 > > Chrome 2.0.172.28 > 267 615 144 335* 1499 830 716 > > Chrome 3.0.195.21 > 350 946 161 114* 2160 1333 970 > > IE6 > 29 47 18 35* 69 60 24 > > IE8 (Compatibility View) > 61 97 38 81* 234 117 64 > > Firefox 3.6 > 244 305 188 99* 922 354 318 It's obviously the same QSA vs. non-QSA con. I've seen the handful of workarounds in the other query engines for QSA quirks. The idea that they are complete is ludicrous (as is the idea that you need QSA for anything but dubious tests). And their "slow lanes" are fantasy code, so you might as well disallow all of them as they have to fall back to those in some cases (not to mention that most browsers in use today do not have QSA at all). Once I formalize _exactly_ which selectors I will support, I will make sure that all of the layers (DOM traversal, XPath, QSA) match (and on more than one random document). From the testing so far, there have been no issues (not that that proves anything). I don't even need to test the other libraries as their logic is so obviously wrong (and deafeningly documented at this point). Basically, XPath and QSA will be close, but the wheels fall off with DOM traversal (which means the wheels fall off in IE). I've seen them fail on my basic test document (most in older browsers, but not all). And (at the moment), the tests do not do much with attribute-based queries. That's one of the areas where the others break down. It only takes one miscount (or exception) to disallow the results. In the meantime, take my advice and forget about using CSS selector queries (certainly if QSA is involved). They are obviously inherently over-complicated error-prone, no matter whose library you use. For every query-based solution, there are methods available to produce a query-less solution. Make use of those instead. ;) For information on which selectors I assert are stable in My Library (with or without QSA), see the test page:- http://www.cinsoft.net/slickspeed.html I'll find out regardless, but anyone who can show that the selectors tested on that page have problems with my QSA add-on is welcome to speak up. Eh, except you. I don't care to waste time with loopy lunatics. :( > > > OSX 10.4 > -------- > > Safari 2.0.0 > 1 0 9 1* 10 5 0 > > Safari 2.0.4 > 2 0 2 3* 15 0 2 > > Safari 3.04 > 17 20 13 15* 54 24 16 > > Safari 3.1 > 177 302 84 124* 562 387 362 > > Firefox 2.0 > 7 12 7 7* 28 14 7 You know, the further back in browser history I go, the more the others fail to qualify (due to miscounting or exceptions). It seems highly unlikely that every one of these things (other than mine) passed every test. ISTM that several of the "major" frameworks fail my SlickSpeed tests (which are basically the originals plus a few extra like ..class1.class2) in IE8 (in one mode or another).
From: jdalton on 10 Feb 2010 00:11
Hi David, > You are still here? Yep > >>> Opera 9.50 (build 10063) > >>> 160 150 55 *68 339 170 128 > >> Looks pretty inconclusive (not to mention spotty) now. So much for your > >> "more accurate" tests. ;) > > How so ? > > How so what? And once again, you've snipped out a good part of what you > are asking me to reply to. Incorrigible. I snipped nothing out. That was your reply to the Opera results. If it was to IE8 compatibility mode then the same question applies. How are my tests *not* "more accurate" as you seem to be suggesting. > > Whatever. Your lib from the builder or from the download page yields > > the same results. > > The same results for what? My previous Slickspeed results, follow along now Mark. > > I have provided plenty of results that don't > > use QSA and your lib is still one of the slowest. > > You have provided no such results. Denial > The only results that (falsely) > showed mine as "one of the slowest" was exposed as rigged. No rigging going on. You haven't exposed anything except your ignorance. > I've been saying much the same thing about browser > sniffing since the early part of the century. That horse has been beaten to a pulp. > Oh here we go. I could have saved you some time as the differences in > the newer build won't affect these tests (at least not significantly). It took seconds to copy the file over no time lost. Yes, as I stated the results were the same. > It's obviously the same QSA vs. non-QSA con. I've seen the handful of > workarounds in the other query engines for QSA quirks. The idea that > they are complete is ludicrous No one said any of them are complete, your QSA code *is* 100% incomplete, at least the others put an effort into fixing the bugs. > In the meantime, take my advice and forget about using CSS selector > queries (certainly if QSA is involved). Some talk from the guy using a cheap QSA hack in his slickspeed tests. cinsoft.net/mylib-qsa-min.js cinsoft.net/speedtest_mine.html > You know, the further back in browser history I go, the more the others > fail to qualify (due to miscounting or exceptions). It seems highly > unlikely that every one of these things (other than mine) passed every > test. ISTM that several of the "major" frameworks fail my SlickSpeed > tests (which are basically the originals plus a few extra like > .class1.class2) in IE8 (in one mode or another). What's your point? If I expand the test to more complex selectors the others will continue to pass while yours fails. |