My Library _passes_ TaskSpeed in IE < 7
in [JavaScript]
|
Prev: A good opportunity to investment
Next: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
From: David Mark on 18 Feb 2010 15:43 Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box crashed a week ago. Perfect (as expected). Can anyone else see a problem in IE < 7? http://www.cinsoft.net/taskspeed.html Will update this post with an analysis of the code for the three tests that were mentioned as failing recently (likely due to a fleeting problem with a bad build). I have been adding new features daily for about a week and there was at least one day where a bad bug made it onto the server for a day or so. No idea why it would have led to a failure in IE6 though. Perhaps an analysis of the code will tell. One thing is for sure, asking the user to file a ticket will not tell anything. ;)
From: David Mark on 18 Feb 2010 18:19 David Mark wrote: > Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box > crashed a week ago. Perfect (as expected). Can anyone else see a > problem in IE < 7? > > http://www.cinsoft.net/taskspeed.html > And same results for this one:- http://scott.sauyet.com/Javascript/Test/taskspeed/2010-02-15a/ So, is IETester a complete crock or is Scott seeing things? There's really no in-between. I don't mean to imply that Scott's vision is impaired. Rather I suspect that IETester is impaired in some odd way (and unfortunately it is my only option for testing IE < 7 at the moment).
From: S.T. on 18 Feb 2010 19:10 On 2/18/2010 3:19 PM, David Mark wrote: > David Mark wrote: >> Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box >> crashed a week ago. Perfect (as expected). Can anyone else see a >> problem in IE< 7? >> >> http://www.cinsoft.net/taskspeed.html >> > And same results for this one:- > > http://scott.sauyet.com/Javascript/Test/taskspeed/2010-02-15a/ No errors in either on IE6 on a WS 2003 box. On your test My Library came in slightly behind PureDom, roughly the same as qooxdoo and Dojo1.4, slightly ahead of jQuery 1.4 with the remainder trailing quite a bit. On Scott's test My Library was a little behind PureDom and YUI3, about the same as jQuery 1.4 (alter), qooxdoo and Dojo 1.4 with the rest well behind. PureDom was crushing all until it really stalled sethtml() and eeked out a win. The jQuery 1.4(alter) was on pace to beat all except PureDom until it crapped out on destroy() and ended up lumped with a bunch of others in the ~5000ms range. > > So, is IETester a complete crock or is Scott seeing things? There's > really no in-between. I don't mean to imply that Scott's vision is > impaired. Rather I suspect that IETester is impaired in some odd way > (and unfortunately it is my only option for testing IE< 7 at the moment). I see essentially the same results (albeit at 3x faster) using IETester on a substantially faster Win7 box versus the 'real' IE6 on an older WS2003. Best I can tell IETester is accurately emulating native IE6. One of the dojo tests threw an error on Scott's page, but that occurred on both setups.
From: David Mark on 18 Feb 2010 19:26 S.T. wrote: > On 2/18/2010 3:19 PM, David Mark wrote: >> David Mark wrote: >>> Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box >>> crashed a week ago. Perfect (as expected). Can anyone else see a >>> problem in IE< 7? >>> >>> http://www.cinsoft.net/taskspeed.html >>> >> And same results for this one:- >> >> http://scott.sauyet.com/Javascript/Test/taskspeed/2010-02-15a/ > > No errors in either on IE6 on a WS 2003 box. Thanks S.T.! I had one other report by email that it was fine on a virtual PC and then there are my "IETester" results. Looking pretty promising at this point. I am eager to hear what the beef was on Scott's end (though I don't doubt that _something_ was going wrong there). > > On your test My Library came in slightly behind PureDom, roughly the > same as qooxdoo and Dojo1.4, slightly ahead of jQuery 1.4 with the > remainder trailing quite a bit. Yep. I can confirm that is the typical result for IE < 7 and IE8 compatibility mode. Of course, jQuery is cheating beyond belief as they call getAttribute with no attempt to determine if it will work (and it often doesn't in these environments). > > On Scott's test My Library was a little behind PureDom and YUI3, about > the same as jQuery 1.4 (alter), qooxdoo and Dojo 1.4 with the rest well > behind. PureDom was crushing all until it really stalled sethtml() and > eeked out a win. The jQuery 1.4(alter) was on pace to beat all except > PureDom until it crapped out on destroy() and ended up lumped with a > bunch of others in the ~5000ms range. One other thing to keep in mind is that all of these (save for jQuery 1.4) rely on sniffing the UA string, so can't be assumed to work on anything that wasn't tested _today_. ;) > >> >> So, is IETester a complete crock or is Scott seeing things? There's >> really no in-between. I don't mean to imply that Scott's vision is >> impaired. Rather I suspect that IETester is impaired in some odd way >> (and unfortunately it is my only option for testing IE< 7 at the >> moment). > > I see essentially the same results (albeit at 3x faster) using IETester > on a substantially faster Win7 box versus the 'real' IE6 on an older > WS2003. Best I can tell IETester is accurately emulating native IE6. It seemed like it based on my observations. Did a fair job with 5.5 as well. But Scott's results were giving me nagging doubts about the veracity of IETester. I feel much better about it now. :) > One > of the dojo tests threw an error on Scott's page, but that occurred on > both setups. > D'oh! It fails several of the SlickSpeed tests as well, even in the very latest browsers (and it is hardly alone in that respect). The problem I have with such efforts is exemplified by a response I saw recently regarding an issue with their attr method. The user had used some slightly older version of the framework and found that their app broke in IE8. The first thing out of the mouth of the responder was "that version never _claimed_ to support IE8". That about sums it up, doesn't it? That's the mindset and it is completely out of step with sound cross-browser scripting practices. If a script can't survive from one version of IE (or any major browser) to the next, what possible shot does it have with older, unknown or otherwise "unsupported" browsers. As Richard has said, such multi-browser scripts can only be _expected_ to work in environments where they have been _demonstrated_ to work (paraphrasing and emphasis is mine). Taken to the extreme, due to the seemingly constant browser revisions and automated delivery mechanisms such as Windows Update, you really can't feel confident in anything you haven't tested _today_. And seeing as IE - for example - has more configuration permutations than can be tested in one lifetime, understanding and logic has to win out over confused hacking by empirical observation. ;) But I digress. Thanks again for your input. It is _much_ appreciated (and would have been even if the results had gone the other way). :)
From: Andrew Poulos on 18 Feb 2010 19:38
On 19/02/2010 10:19 AM, David Mark wrote: > David Mark wrote: >> Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box >> crashed a week ago. Perfect (as expected). Can anyone else see a >> problem in IE< 7? >> >> http://www.cinsoft.net/taskspeed.html >> > > And same results for this one:- > > http://scott.sauyet.com/Javascript/Test/taskspeed/2010-02-15a/ > > So, is IETester a complete crock or is Scott seeing things? There's > really no in-between. I don't mean to imply that Scott's vision is > impaired. Rather I suspect that IETester is impaired in some odd way > (and unfortunately it is my only option for testing IE< 7 at the moment). Under IE 6 on Win XP the bind selector caused the My Library cell to go red: 781 844 msfound though all the libraries found 844 items. Times: jquery 1.4.1 (alter) came in at 2833 mylib 2862 mylib (qsa) 2102 mylib (alter) 2534 prototype 1.6.0.3 came in at 30,825 with tonnes of errors. Andrew Poulos |