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 19 Feb 2010 21:01 S.T. wrote: > On 2/18/2010 4:26 PM, David Mark wrote: [...] >> >> 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. There's no question it can happen for some people in some contexts (and it is a little hard to tell unless you talk to every visitor). But what if I offered you a new type of calculator that makes calculations a little easier and the only caveat is that occasionally, for some operations, it may give an incorrect answer? And what if you had to constantly upgrade it, else the invalid results will become more prevalent, eventually degrading to all wrong answers? It may be hard to spot the issues at first and if you constantly upgrade it you may never spot them, but they are definitely there. > 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. The plug-ins are absolutely poison. Even the staunchest jQuery defender will tell you that. And now that jQuery is releasing a new incompatible version every month or so, it will just get worse as there is no way to keep the third parties in sync. It just can't work, except superficially (and not even that the way they are going). And, let me tell you, there isn't a single version of jQuery that is consistent from one IE version (or mode) to the next. You are just straddling the very well-documented land mines. Take a step in any direction and you could well blow up. That's not a good foundation in any type of software development, particularly browser scripting. > 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). Good idea. But plug-ins are its main "selling point". Without those, what have you got? It's a poorly designed API with almost zero flexibility, a single $ factory function for every task and a very buggy and inconsistent CSS selector query engine. All in about 70K, minified. :) > > Perhaps I should explain what I do, as maybe a narrow niche makes me a > better candidate for jQuery than others. It would have to be _very_ narrow. :) > 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. You can't use that thing on the Web. There's no telling what browsers/modes/configuration/plug-ins are in play. It's not a cross-browser script, but a multi-browser stream of inferences based on the observations of relative neophytes. Just don't. Your users will thank you with more visits. > As a footnote, every single page on my sites is > DOCTYPE'd HTML4.01 Strict (aside from those outputting JSON, etc). Okay. Good to avoid quirks mode and phony XHTML. > Perhaps that is among the reason I run into virtually no issues. No. Avoiding quirks mode only sidesteps a few recent revelations (for their developers). Everything else I've documented over the last few years applies to either mode. > > 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. You aren't doing your visitors any favors by making them download 70K of jQuery to do trivial stuff. And what about SEO? For one, jQuery does not do progressive enhancement at all. It isn't capable. You call a method and it either works or blows up. It's like trying to defuse a bomb by shaking it violently. :) > We're talking basic AJAX stuff, toggling some div > visibility for makeshift filtering of results, form validation, *very* > light animation to, etc. Toggling styles is clearly trivial and the same for form validation, which should work in any UA, not just the handful that the jQuery team "supports" (they love to pretend that anything released last year has ceased to exist, but the end-users are oblivious to their delusions). And jQuery is terrible for animations, which are also trivial. It's got a little bit of everything in it, but does virtually nothing well. It has been well documented (here and elsewhere). > 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. Proceed to what? If your users are confused, it is your problem to solve. jQuery can't help you there either. > > 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. "Claims" is the operative word. :) And forget mobile with jQuery. It's too large and lumbering (like a dinosaur), as well as inorganic due to incessant interdependencies. The ugly truth is that jQuery is just a brand. They are working on some "new jQuery" that will work "better" on mobile devices. But why would you need two scripts? Wouldn't you then need two sites? That's going in the wrong direction. Also, you can't trust browser statistics at all, for reasons that have been discussed here ad nauseam (search the archive). > 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%. I assure you that jQuery isn't close to compatible with Opera 9 and it goes downhill from there (e.g. Opera 8). And those things are in game consoles (Wii), tons of fairly capable phones and other devices. http://www.cinsoft.net/slickspeed.html > > 3.2% of last month's traffic was mobile (iPhone, iPod, Android and > Blackberry). Our site is a poor candidate for mobile browsers. There you go. It is self-imposed. :) > 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. Why not? It sounds like exactly the sort of site that _needs_ to work on mobile devices (at least on the iPhone). > I can see the search terms mobile browsers use to > reach the site and they're ALL reference searches, not commercial > searches. I don't follow. > I'm happy to help these guys out but, to put it bluntly, > reference seekers don't matter to my primary objective (sales/revenue). Still. How do you pigeonhole potential customers? > 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. I really don't follow that. What they will likely spot is their browser bogging down or crashing before they get a chance to read your pitch. :( > > 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 think you are mistaken. > 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. But you are using a sledgehammer to swat a fly and it is excluding potential customers. > 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. No good. I just read a post from one of their UI guys explaining to a user that their site was broken because the latest CDN jQuery was three days behind the latest UI stuff and to please wait it out. And there are lots of other reasons not to rely on a third-party host like that (search the archive). Also, iPhones won't cache jQuery. It's too large. > > 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. You could do all of that without jQuery. Why don't you try mine as it does actually work in IE. ;) > > 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. Yes, jQuery and its various plug-ins and widgets are notoriously slow. From what I've seen they are now claiming that the latest rendition (sixth so far in twelve months I think) has caught up to Dojo. They are all lagging way behind context-specific solutions, as well as My Library. :) http://www.cinsoft.net/taskspeed.html > > The development I'm doing on intranet sites is RIDICULOUSLY faster using > jQuery. For me, at least. Its AJAX and DOM selection, You shouldn't be using that query engine. It's notoriously slipshod. As for Ajax, download my Ajax module and be done with it. ;) > animation effects, As mentioned, they aren't very good at those. > bubbling for virtually all event types (since 1.4), The whole "live" event thing is a sham (trying to bottle event delegation because the original jQuery way of attaching a gazillion listeners was pointed out to be outrageously inefficient). You don't want to attach _every_ listener to the documentElement. Trust me as I actually have some practical experience with event delegation. :) And their endless attempts to "normalize" things like event bubbling are just complicating something that is already way to complicated. These are marketers, not scientists. > it's handy > Serialize() function couple with PHP's parse_str() -- all of it has sped > up development... Form serialization? That was the first topic covered by CWR (search the archive) and is alive and well in My Library. I'm sure mine will work with PHP as well. ;) > I'm guessing here... five-fold. Guessing what? > Most importantly, it > allows me to code in a manner that feels much more comfortable to me. I think you need to snap out of that. Kicking in a door may feel rewarding (it does to me anyway), but a key works much better and is unlikely to break the hinges. > Many compact, independent functions - easy to code, easy to debug. jQuery has the worst sort of API. In fact, it really has no API (just a single object with a lot of oddly named and "overloaded" methods). How is it readable (or efficient) when you have to count the number of arguments passed to a method to determine whether it is a get or a set? > Others might use a different coding mindset with jQuery but I like to > keep it simple, even if slightly inefficient. Show me the code. I have to believe it (like most jQueried JS) is more than a _little_ inefficient. And keeping it simple is a good thing, but jQuery is outrageously complex (and error-prone, of course) under the hood. > > I don't doubt you that attr() has issues, but not for what I'm using it > for. How do you know? Which version of jQuery? It has changed just enough over the years to cause obscure compatibility breakages, but has never moved an inch towards something that makes sense. What is it you think that function does? I can tell you that the documentation doesn't have the answer and neither do the authors. > 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. You have mistaken minor issues for the majors that are found in jQuery's attr method. Search the archive (or just take my word for it at this point). :) > Or whatever odd uses might > cause errors. What do you consider odd? And do you know which odd uses cause problems (which are not always manifested as errors, but silent inconsistencies). This stuff can be hard enough to debug without adding a buggy abstraction layer on top of the DOM. > I'd prefer it to be flawless, but it doesn't really matter > to me. I use it to switch an src, Oops. The file URI properties/attributes are a big problem that they don't handle properly. If you foul those up, depending on the user cache settings, your slide shows may have hiccups. > 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. I don't follow that last bit. And how do you know it works fine? How many modes, versions and configurations of the major browsers (even the latest ones) have you tested thoroughly? ISTM that you are relying on the alleged expertise of John Resig, who has been demonstrated to be something less of an expert in this field (to put it very mildly). > > Maybe jQuery over-advertises by calling itself "cross-browser". It's a flat-out lie. It's multi-browser at best and shifts constantly to "keep up" with the very latest browsers in their default configurations, with default plug-ins enabled, etc., etc. That's not how cross-browser scripting works. Cross-browser scripts don't fall apart in new (or old) browsers for a start. > Maybe > "cross-current-major-desktop-browser" is more apt. More apt, but still not accurate. Every jQuery script uses that attr method to death. That method is not even cross-IE8-compatible (not by a longshot). Wouldn't it be a good idea to consider my opinion on this? http://www.cinsoft.net/attributes.html > For many of us, that's all we need. But you aren't getting what you think you are getting. Not even close. > 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. And why should that be? > > Mostly jQuery gives me time, and a lot of it. Ultimately it is a major time _thief_ due to the need for constant upgrades and revisited regression testing (for those that bother with minor details like that). :) > 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. But in the time you spent learning jQuery... > 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. It's trivial to script a handful of modern browsers without jQuery. Why not try it the other way before you try to compare the two methodologies? > > My goal is not to cater our sites to 100% of the possible audience. My > goal is to maximize revenue and minimize expenses. You absolutely, positively cannot do that with jQuery. Not on this planet. > In our company's case > I can assure you, in no uncertain terms, jQuery assists dramatically. I hardly feel assured by such a general statement. What makes you think it is doing anything positive for you? You need to try something else before you can make a comparison. > 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. Thanks for the vote of confidence! I hope I can help you in the future. And more documentation is coming (a lot of it).
From: S.T. on 22 Feb 2010 14:35 We're gonna have to agree to disagree on the main premise, whether jQuery actually works. You're telling me it doesn't work and is chock full of errors, but that doesn't match my experience. .... but onwards a few of your points/questions On 2/19/2010 6:01 PM, David Mark wrote: >> 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. > > Proceed to what? If your users are confused, it is your problem to > solve. jQuery can't help you there either. jQuery doesn't play any real role in basic navigation -- that's not the issue. My point is it's mind-numbing working to make a nav path and visual cues on a simple interface that a high percentage of the surfing traffic will follow. I don't even try to do so with a complicated UI. >> 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%. > > I assure you that jQuery isn't close to compatible with Opera 9 and it > goes downhill from there (e.g. Opera 8). And those things are in game > consoles (Wii), tons of fairly capable phones and other devices. My public sites work fine with Opera 9 on a Win environment. Maybe it's luck -- who knows? With a 0.17% market share I'm not panicking either way. If I find something that doesn't work, I'll fix it but if I find something live has been broken on Opera for two weeks -- it's not a crisis. >> >> 3.2% of last month's traffic was mobile (iPhone, iPod, Android and >> Blackberry). Our site is a poor candidate for mobile browsers. > > There you go. It is self-imposed. :) > >> 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. > > Why not? It sounds like exactly the sort of site that _needs_ to work > on mobile devices (at least on the iPhone). > >> I can see the search terms mobile browsers use to >> reach the site and they're ALL reference searches, not commercial >> searches. > > I don't follow. > >> I'm happy to help these guys out but, to put it bluntly, >> reference seekers don't matter to my primary objective (sales/revenue). > > Still. How do you pigeonhole potential customers? > >> 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. > > I really don't follow that. What they will likely spot is their browser > bogging down or crashing before they get a chance to read your pitch. :( In the travel industry at least (and I'm certain other industries as well, though not all) you can accurately measure the potential revenue of a visitor based on their search query. We don't deal with Las Vegas but it provides for decent example. For instance, revenue potential on the following searches: "Caesars Vegas" - good value. The most volume though hard to gauge intent. Many will be non-revenue type, but plenty will be potential revenue. "Caesars Vegas off season" - very high value. Almost certainly a booking-related query. Same with "Caesars Vegas specials" or "Caesars Vegas package deals" "Caesars Vegas photos" - questionable value. High percentage totally unrelated to booking, the remainder may be in a booking cycle already and will be tough to 'pull' from whomever they've started working with as this surfer has no interest in reading (your prices, your services, etc) "Caesars Vegas check in time" - virtually no value. Same with "Caesars Vegas airport shuttle" or "Caesars Vegas concierge desk". Nearly every one of these folks have already booked. They represent revenue, but you're past the window to grab that revenue. If you ever craft a pay-per-click campaign in a competitive field using wildcards and don't incorporate negative keywords to filter out garbage traffic you'll learn, in a hurry, the mistake of equally valuing all traffic. Mobile traffic gravitates towards this lower-tier of revenue generating surfers. Lower-end travel (airport hotels, some car rental, airport shuttles) may well find opportunity. Higher end will not. Too much research on the part of consumers (mobile offers convenience, but not a good research environment relative to desktop) and too much reliance on photos in the decision making process. If I ever bother catering to mobile for revenue, and I don't see it happening soon, it'll be it's own site that won't utilize jQuery or likely any javascript whatsoever. The more likely candidate for any mobile-centric work would be a site supporting our clients as they're traveling and, again, would most likely be sans-javascript. >> >> 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 think you are mistaken. > >> 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. > > But you are using a sledgehammer to swat a fly and it is excluding > potential customers. > >> 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. > > No good. I just read a post from one of their UI guys explaining to a > user that their site was broken because the latest CDN jQuery was three > days behind the latest UI stuff and to please wait it out. And there > are lots of other reasons not to rely on a third-party host like that > (search the archive). Also, iPhones won't cache jQuery. It's too large. Oy! Just noticed you went off on another rant/bashfest in some Ajaxian comments. Thought we were making progress. I don't think you're able to rationally discuss jQuery and similar libraries so I'm not gonna spend any more time trying. Best of luck to you and your library.
From: Andrew Poulos on 22 Feb 2010 15:01 On 23/02/2010 6:35 AM, S.T. wrote: .... > Oy! Just noticed you went off on another rant/bashfest in some Ajaxian > comments. Thought we were making progress. I don't think you're able to > rationally discuss jQuery and similar libraries so I'm not gonna spend > any more time trying. I think that's because DM has made one objective criticism after another about jquery and the response by "fans of jquery" is typically of the nature "it works for me" (instead of rationally discussing each criticism raised). Andrew Poulos
From: S.T. on 22 Feb 2010 17:08 On 2/22/2010 12:58 PM, David Mark wrote: >> In the travel industry at least (and I'm certain other industries as >> well, though not all) you can accurately measure the potential revenue >> of a visitor based on their search query. > > Sounds like marketing voodoo to me. Yikes! Ever wonder why PPC keywords in a similar theme will see bids deviating by a factor of 10 or more? Hint: It's not voodoo. >> Thought we were making progress. > > You'll have to enlighten me. I didn't know "we" were doing anything. > If you mean that _you_ have been more reasonable in _here_ of late, then > I will give you that. ISTM that you have been helpful of late (and less > likely to flame me for condemning your library of choice). Meaning for a brief while there it seemed you had taken a step back and were content to discuss your library's merits.
From: Matt Kruse on 22 Feb 2010 17:11
On Feb 22, 2:01 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > On 23/02/2010 6:35 AM, S.T. wrote: > > Oy! Just noticed you went off on another rant/bashfest in some Ajaxian > > comments. Thought we were making progress. I don't think you're able to > > rationally discuss jQuery and similar libraries so I'm not gonna spend > > any more time trying. > I think that's because DM has made one objective criticism after another > about jquery and the response by "fans of jquery" is typically of the > nature "it works for me" (instead of rationally discussing each > criticism raised). DM is very good at identifying very specific problems in jQuery and other libs. He isn't very good at understanding what impact - or what lack of impact - that has in a particular situation. Nor does he ever seem willing to discuss the other factors that matter to developers who choose to use jQuery, or how it may fit into a larger, "non-ideal" development environment and solve considerably more problems than it causes. Matt Kruse |