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: Eric Bednarz on 18 Feb 2010 19:49 David Mark <dmark.cinsoft(a)gmail.com> writes: > 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 Works for me with the setups below (all on VirtualBox with OS X 10.6 as host; guests are pretty much up to date as far as excluding newer IE and SP versions gets you). I have no idea how to copy/extract the (relevant parts of the) results on the windows guests without quitting my day job, so here's just the final column: IE 6 Windows XP SP3 1722 20870 6893 3414 21164 12173 11796 2643 6188 3793 4130 2383 1911 2000 IE 6 Windows XP SP2 1613 32047 8633 3705 28720 15010 13219 2852 4937 3937 4654 2403 2101 2097 IE 6 Windows 2000 SP4 1484 28553 6347 3095 24585 11389 11286 2403 5057 2623 4247 2192 1743 1914 make, indexof, sethtml and insertbefore are consistently faster/fastest, the rest is gray (I suppose that's supposed to mean 'average' in some parts of the flat world without needing a legend). IE 5.5 on Windows 2000 SP4 gave a bunch of errors and froze halfway through, so I didn't bother to check in 5.0. :-)
From: David Mark on 18 Feb 2010 19:58 Andrew Poulos wrote: > 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 I can't remember what red means. Slowest perhaps? I have found that in _some_ browsers (IE included for sure), extraneous activity on the PC can cause hiccups. So I usually run them a dozen times or so to determine patterns. > > though all the libraries found 844 items. Good to hear. They all count properly in the latest browsers AFAIK, other than Prototype, which invariably returns undefined for one of them. > > > Times: > > jquery 1.4.1 (alter) came in at 2833 IIRC, that was after Scott optimized the "expert" tests put forth by the jQuery team. Perfectly allowable, of course. > mylib 2862 > mylib (qsa) 2102 Yeah, I finally updated the online version to use the non-QSA version. I had done it locally (where I do most of my testing), but must have forgotten to upload it. > mylib (alter) 2534 That was after Scott adjusted a few of my tests. I don't remember the exact details, but it is all a matter of interpretation of the rules. JFTR, I never read the rules at all (just looked at what the others were doing). In retrospect, I suppose the "rules" wouldn't have helped anyway. :) > prototype 1.6.0.3 came in at 30,825 with tonnes of errors. LOL. To be fair, I don't think that is the very latest Prototype. But on the other hand, Prototype has been around for five years and certainly purported to "smooth out" cross-browser issues (meaning IE in their limited experience with "all browsers"). So LOL again. Pity for those who bought into Prototype and now must come to the realization that they have been had. Those friendly forum denizens weren't really their friends at all. Close inspection will likely reveal that at least some of them are selling books about Prototype (about as compelling today as books about slide rules). :) Thanks for your help Andrew! As always, it is much appreciated. Seems like we really have something now. Granted, I still need to do some work on the documentation, but then the others aren't exactly standouts in that department either. I've got some very cool add-ons on the way as well, including localization and data transports. Now if I can just get some others interested in writing widgets on top of it (and giving them away of course), the game will be all but over. :) And as mentioned in the My Library forum, everything to this point should be considered late Beta. I think a release candidate will be in order shortly. Still, I'd take my Beta over their "releases" any day. When things go wrong, you know who to call (and you know you won't be directed to file a ticket). ;)
From: David Mark on 18 Feb 2010 20:12 Eric Bednarz wrote: > David Mark <dmark.cinsoft(a)gmail.com> writes: > >> 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 > > Works for me with the setups below (all on VirtualBox with OS X 10.6 as > host; guests are pretty much up to date as far as excluding newer IE and > SP versions gets you). > > I have no idea how to copy/extract the (relevant parts of the) results > on the windows guests without quitting my day job, so here's just the > final column: > > IE 6 Windows XP SP3 > 1722 20870 6893 3414 21164 12173 11796 2643 6188 3793 4130 2383 1911 2000 > > IE 6 Windows XP SP2 > 1613 32047 8633 3705 28720 15010 13219 2852 4937 3937 4654 2403 2101 2097 > > IE 6 Windows 2000 SP4 > 1484 28553 6347 3095 24585 11389 11286 2403 5057 2623 4247 2192 1743 > 1914 > > make, indexof, sethtml and insertbefore are consistently faster/fastest, > the rest is gray (I suppose that's supposed to mean 'average' in some > parts of the flat world without needing a legend). Right. > > IE 5.5 on Windows 2000 SP4 gave a bunch of errors and froze halfway > through, so I didn't bother to check in 5.0. :-) Yeah, a lot of the included libraries (not mine) throw errors immediately. All but mine passed the tests, but most of the others had already died before I clicked the start button. Bad news for those stuck with Windows 2000. :) I haven't run TaskSpeed in IE5 either. I suspect that the test framework itself will fail. I think my wrapper objects are pruned in IE5 as well (require Function.prototype.call/apply), so the point is moot. That's why I advise using the API instead (it's not that much more typing). :) Queries should work in IE5, but tell that to jQuery and the rest who are still struggling with IE8 (and dreading IE9 I'm sure). var Q, E, D; if (Q && E && D) { // start "concise" object-centric app here } These test suites aren't ready for that. ;) Thanks for your help, Eric! It is much appreciated.
From: David Mark on 19 Feb 2010 19:51 Eric Bednarz wrote: [...] > > IE 5.5 on Windows 2000 SP4 gave a bunch of errors and froze halfway > through, so I didn't bother to check in 5.0. :-) I can confirm that the testing framework itself fails in IE5.01, which is perfectly ludicrous behavior if you ask me. But then, it is a hastily hacked version of SlickSpeed, which was written by the MooTools team. I mean, it's not that anyone in their right mind would use IE5.01 today, but there are lots of sub-standard browsers that are in use and likely some of them have similar shortcomings. And if you can't handle a browser, you have to exit gracefully. Blowing up right in the middle of an enhancement is clearly not a planned exit strategy, but carelessness on the part of the developers. Scripts are not allowed to die without permission! :) Other than the initial bombing by the various "majors" and lots of freezing during the tests, IE5.5 came out okay (for My Library) and virtually all blacked out for the rest. Same for SlickSpeed.
From: S.T. on 19 Feb 2010 19:58
On 2/18/2010 4:26 PM, David Mark wrote: >> No errors in either on IE6 on a WS 2003 box. > > Thanks S.T.! No problem! > 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. ;) I know what you're saying, but.... In my couple year's of jQuery experience, which is admittedly a small sample being one developer, I've had virtually no issues with upgrading -- both browsers and newer jQuery versions. Specifically zero problems when IE8 was introduced, zero problems swapping jQuery 1.2 for 1.3, and the single problem I had upgrading to jQuery 1.4 was a plugin called BlockUI failed. I removed it's functionality in the interface in about 45 seconds and all was resolved (generally speaking, I avoid jQuery plugins for this reason). Perhaps I should explain what I do, as maybe a narrow niche makes me a better candidate for jQuery than others. My work (aside from occasional freelance project) entails, basically, six projects - 2 public-facing websites and 4 projects best described as intranet apps, two of which are quite extensive. As a footnote, every single page on my sites is DOCTYPE'd HTML4.01 Strict (aside from those outputting JSON, etc). Perhaps that is among the reason I run into virtually no issues. On the public websites, the javascript functionality is fairly trivial stuff intended simply to enhance the experience for visitors, and to a lesser degree for SEO. We're talking basic AJAX stuff, toggling some div visibility for makeshift filtering of results, form validation, *very* light animation to, etc. I can barely get Joe Surfer to consistently realize he should click the giant orange button that says "Proceed" in the event he wishes to proceed -- much less create complex interfaces for public use. Of my past month's visitors (roughly 20K), 98.8% of visitors are on Safari3+, IE6+, FF2+ or Chrome -- or what jQuery claims to support (granted, Android and iPhones will be lumped in there too. More on that below). If I add in Opera9+, not officially supported but seems to work anyhow, its 0.2% share brings the total is 99%. 3.2% of last month's traffic was mobile (iPhone, iPod, Android and Blackberry). Our site is a poor candidate for mobile browsers. We are in the travel sector with an average transaction of ~$3600. Folks are not using their mobile phones to plan $3600 travel packages, nor will they in the near future. I can see the search terms mobile browsers use to reach the site and they're ALL reference searches, not commercial searches. I'm happy to help these guys out but, to put it bluntly, reference seekers don't matter to my primary objective (sales/revenue). Most are just seeking a phone number or property address - even if my jQuery code is failing on those browsers (don't know, don't care) they're unlikely to spot the error. So on the public side I'm perfectly content with jQuery's limitations as they don't have any negative impact except, possibly, the <1% of my sites' non-mobile visitors using obscure browsers. I don't know for certain but can live with it regardless. Perhaps this is because I'm not doing anything 'cutting edge', just some convenience for AJAX and DOM selection and basic manipulation. jQuery's advantages here aren't dramatic either, but it's just faster, much much faster, for me to code using it's wrappers. Since most visitors have it cached from Google already, or worst-case an efficient CDN delivers it to them, I prefer to use it. Now on the intranet side my coding is a bit more 'adventurous'. More dramatic appending and re-arranging the DOM, overlays to set crop marks on photos, drag and drop, etc. More wide-ranging stuff that's a little more suspect on the cross-browser front. But, being an intranet, I get to tell the users to use the latest version of FF or Chrome -- or else don't bother me if there's a problem. I don't bother to support IE in-house largely because it's slow and due to it's rendering bugs. Some still use IE on occasion (third-party airline res systems used in-house require IE and they'll forget to switch browsers) and, while I never bother to test any of my intranet stuff on IE, the only 'errors' I've been called to fix were the result of non-jQuery stuff - awful overflow: rendering or float: issues. In fact, since IE8 came out, all my intranet stuff appears to work just fine except a) parts of my UI's rely on CSS -*-border-radius: to look correct and b) re-arranging a couple hundred DIVs on a sorting function still takes 5x longer vs. FF or Chrome. The development I'm doing on intranet sites is RIDICULOUSLY faster using jQuery. For me, at least. Its AJAX and DOM selection, animation effects, bubbling for virtually all event types (since 1.4), it's handy Serialize() function couple with PHP's parse_str() -- all of it has sped up development... I'm guessing here... five-fold. Most importantly, it allows me to code in a manner that feels much more comfortable to me. Many compact, independent functions - easy to code, easy to debug. Others might use a different coding mindset with jQuery but I like to keep it simple, even if slightly inefficient. I don't doubt you that attr() has issues, but not for what I'm using it for. I'm not trying to change tabindex on the fly or convert an <input> from 'text' to 'file' or use change a predefined input's 'value' that may then conflict with a user-input value. Or whatever odd uses might cause errors. I'd prefer it to be flawless, but it doesn't really matter to me. I use it to switch an src, or perhaps grab/switch an alt or title as a hacky means of outputting SQL data into parts of the DOM. Works fine for those purposes. Maybe jQuery over-advertises by calling itself "cross-browser". Maybe "cross-current-major-desktop-browser" is more apt. For many of us, that's all we need. Maybe you're right and it's not a great choice for "build it and forget about it" development -- most everything I do will never live more than one IE cycle before being revisited/enhanced/tweaked/completely rewritten anyhow regardless of jQuery. Mostly jQuery gives me time, and a lot of it. Faster development time and the ability to code pretty advanced stuff without an extensive knowledge of each browser's nuances, or need to learn it. That time, and what I'm able to accomplish with it, is far more valuable to our bottom line than a minute percentage of our traffic who may be struggling with certain functionality on our sites because jQuery isn't perfect. My goal is not to cater our sites to 100% of the possible audience. My goal is to maximize revenue and minimize expenses. In our company's case I can assure you, in no uncertain terms, jQuery assists dramatically. Perhaps your library will become an even better choice for those in my situation (for me, as a non-JS expert, once documented a bit better and more sample code found to review can be found) and jQuery should have followed the path you've taken to begin with -- but that still wouldn't discount the value jQuery has provided. Best regards |