My Library _passes_ TaskSpeed in IE < 7

Discussion in 'Javascript' started by David Mark, Feb 18, 2010.

  1. David Mark

    David Mark Guest

    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. ;)
    David Mark, Feb 18, 2010
    #1
    1. Advertising

  2. David Mark

    David Mark Guest

    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).
    David Mark, Feb 18, 2010
    #2
    1. Advertising

  3. David Mark

    S.T. Guest

    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.
    S.T., Feb 19, 2010
    #3
  4. David Mark

    David Mark Guest

    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). :)
    David Mark, Feb 19, 2010
    #4
  5. David Mark

    Eric Bednarz Guest

    David Mark <> 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. :)
    Eric Bednarz, Feb 19, 2010
    #5
  6. David Mark

    David Mark Guest

    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). ;)
    David Mark, Feb 19, 2010
    #6
  7. David Mark

    David Mark Guest

    Eric Bednarz wrote:
    > David Mark <> 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.
    David Mark, Feb 19, 2010
    #7
  8. David Mark

    David Mark Guest

    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.
    David Mark, Feb 20, 2010
    #8
  9. David Mark

    S.T. Guest

    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
    S.T., Feb 20, 2010
    #9
  10. David Mark

    David Mark Guest

    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).
    David Mark, Feb 20, 2010
    #10
  11. David Mark

    S.T. Guest

    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.
    S.T., Feb 22, 2010
    #11
  12. David Mark

    David Mark Guest

    S.T. wrote:
    > 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.


    And as for your experience, it pales in the light of hard evidence:-

    http://www.cinsoft.net/slickspeed.html

    ....where the results with the very latest versions of these things in
    the very latest browsers are a patchwork quilt of errors and miscounts
    that vary from one environment to the next. And forget anything that
    came out last year (or is coming out today). That's not working as
    their stated goal was to "smooth out" differences between browsers
    (they've done the 180 degree opposite).

    And, as noted in my forum, the mistakes documented are the tip of the
    proverbial iceberg. Once I fix that stupid testing framework to accept
    no results as viable (it currently thinks zero is always bad), the
    floodgates will really open up. For example, what do you suppose that
    at least some of these things will return for:-

    div[className]

    ....if you have been following along here, the answer should be
    predictable (as well as inconsistent, enabling neophytes to fool
    themselves once again).

    >
    > ... but onwards a few of your points/questions


    Onward!

    >
    > 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


    Well, except fucking it up by adding unload listeners for no reason. ;)

    > -- 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.


    You don't understand. It has nothing to do with how many people use
    that browser (which is likely also found in phones, game consoles, etc.)
    The idea is that you have no idea how many browsers/configurations are
    out there (or are coming), so it behooves you to test in as many
    environments as possible. Opera 9 is not exactly a big issue in this
    regard. Opera 8 starts to get interesting, most of the "major"
    libraries will likely fall on their faces in Opera 7 and will definitely
    blow up in Opera 6. So if you aren't upgrading these things
    _constantly_, your sites eventually degenerate into rubbish. That's not
    sound Web development strategy. A primary example is IE8, which none of
    them has close to right at this point (over a year after it hit
    end-users' machines). And they spent all sorts of time and effort with
    the Betas as well. The open source GP libraries just don't save time on
    any level as the authors, in general, have no clue what they are doing.
    Instead they rely on empirical observations and constantly fiddle with
    their browser sniffing while simultaneously introducing enough
    incompatibilities to make keeping up a nightmare for all but the
    simplest applications.

    http://vids.myspace.com/index.cfm?fuseaction=vids.individual&VideoID=7622124

    > 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.


    Relying on empirical observations and dismissing visitors who have the
    gall to use Opera (a very capable, standards-based browser which is
    popular in Europe) is not sound Web development strategy.

    >
    >>>
    >>> 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.


    Sounds like marketing voodoo to me.

    >
    > 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.


    That's hardly scientific.

    >
    > 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.


    I don't see what this has to do with using a dubious script (or scripts
    rather as it comes out with a new and incompatible version every other
    month) like jQuery (or the like). What you are doing is ensuring
    constant maintenance issues and expensive re-testing.

    >
    > 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.


    I don't buy that mobile users can be dismissed as unqualified leads.
    For example, what well-heeled individual today is without an iPhone or
    Blackberry (or the like?)

    >
    > 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.


    That's the typical excuse/mistake. You don't need to build and maintain
    two sites to support mobile users. Doing so is a waste of time and money.

    > 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.


    You don't have to eschew JS either. Just use proper progressive
    enhancement. Here is a basic example:-

    http://www.cinsoft.net/hartkelaw/

    Granted, I should really leverage built-in CSS transitions when possible
    (more than I have), but you get the idea.

    >
    >>>
    >>> 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.


    About jQuery trying to prove something with that ridiculous TaskSpeed
    graph (ooo look it is way less sluggish than before, particularly if
    your app uses the body selector incessantly).

    And those morons at Ajaxian still haven't published anything about My
    Library, which kills jQuery for speed (yes, even the TaskSpeed variety),
    compatibility and virtually any other metric you might measure. All
    because I said their site sucks. Well, it does suck and news sites are
    not supposed to take personal feelings into account when reporting the
    news. As an example of them sucking, I reported (in a comment) years
    ago that every author name in the comments links to http://null/. And
    that's the tip of the iceberg as well. IIRC, they have major problems
    with unicode, spitting out gobbledygook in place of perfectly valid
    characters.

    > 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).

    > I don't think you're able to
    > rationally discuss jQuery and similar libraries so I'm not gonna spend
    > any more time trying.


    Um, why don't you just look at the _evidence_. I mean, you don't have
    to take my word for anything.

    >
    > Best of luck to you and your library.
    >
    >


    Thanks!
    David Mark, Feb 22, 2010
    #12
  13. David Mark

    David Mark Guest

    Andrew Poulos 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).
    >


    Yes. And throw in the fact that they routinely bitch about my reviews,
    insult me personally for posting them, post superficial "criticism" of
    my (clearly superior) library, etc., etc. It's been going on for
    _years_ and rags like Ajaxian are partially to blame for posting gushing
    reviews of jQuery (and seemingly every other library they can find,
    except mine). :(

    The latest quote was that as jQuery "optimized" their body selector (and
    how do you start out slow with that?) to make their obviously
    incompetent TaskSpeed test functions run slightly faster, they clearly
    had their "pedal to the metal". Oh, howls of derision. I'm sure it is
    still a relative tortoise as they are hemmed in by an incompetent design
    that they can't change. ;)
    David Mark, Feb 22, 2010
    #13
  14. David Mark

    S.T. Guest

    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.
    S.T., Feb 22, 2010
    #14
  15. David Mark

    Matt Kruse Guest

    On Feb 22, 2:01 pm, Andrew Poulos <> 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
    Matt Kruse, Feb 22, 2010
    #15
  16. David Mark

    David Mark Guest

    S.T. wrote:
    > 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.


    Still, what does this have to do with jQuery (or not using jQuery?)

    >
    >
    >>> 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.


    I am, but why should I ignore the "competitor" shortcomings. Seems
    relevant to me (and to others apparently).
    David Mark, Feb 22, 2010
    #16
  17. David Mark

    David Mark Guest

    Matt Kruse wrote:
    > On Feb 22, 2:01 pm, Andrew Poulos <> 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.


    You are very poor at apologizing for _massive_ problems that you don't
    fully understand (or perhaps you just like to see your name in print).
    How can you still be in here two years later pretending that DOM
    properties and attributes are not primary concerns for DOM scripting
    libraries. And the stuff I post is the tip of the proverbial iceberg.

    > He isn't very good at understanding what impact - or what
    > lack of impact - that has in a particular situation.


    Now, how stupid is that statement? Obviously I understand _exactly_
    what the impact is as I hit a bullseye every time I write a new test.
    All you have to do is read (and understand) the code.

    BTW, as you are still stuck with jQuery 1.2x due to compatibility
    problems, you should really have a look at how that one "performs" in
    the very latest browsers (supposedly the only ones you care about).
    Your stuff is rotting under your feet (and it wasn't that fresh to begin
    with). ;)

    > 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.


    No, you are just ignorant (or an incessant apologist). You've been
    spouting the same bullshit for years. When are you going to realize you
    have become a laughingstock because of it?
    David Mark, Feb 22, 2010
    #17
  18. David Mark

    David Mark Guest

    S.T. wrote:
    > On 2/22/2010 2:43 PM, David Mark wrote:
    >> S.T. wrote:
    >>> 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.

    >>
    >> Still, what does this have to do with jQuery (or not using jQuery?)

    >
    > This subtopic began with my reasoning as to why I don't care if jQuery
    > works for mobile browsers -- specifically, because I don't care about
    > the mobile market and the reason why.


    But you work on public-facing sites and mobile browsers are out there
    (in droves these days). There's nothing wrong with degrading
    (gracefully) back to a static document for these visitors. What is
    definitely wrong is using a script that gets in the way of (rather than
    enables) progressive enhancement, so that your documents may be rendered
    unusable due to an exception thrown in the middle of one of your
    enhancements. Think about that. If you pretend that mobile (or older)
    browsers do not exist, visitors will respond by pretending that your
    clients' sites do not exist. ;)

    >
    >>>
    >>>
    >>>>> 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.

    >>
    >> I am, but why should I ignore the "competitor" shortcomings. Seems
    >> relevant to me (and to others apparently).

    >
    > Recognizing competitor's shortcomings doesn't exactly translate to
    > jumping into any post that happens to reference one of them, proclaiming
    > them fatally flawed garbage written by clueless fools.


    If the shoe fits... :)
    David Mark, Feb 22, 2010
    #18
  19. David Mark

    S.T. Guest

    On 2/22/2010 2:43 PM, David Mark wrote:
    > S.T. wrote:
    >> 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.

    >
    > Still, what does this have to do with jQuery (or not using jQuery?)


    This subtopic began with my reasoning as to why I don't care if jQuery
    works for mobile browsers -- specifically, because I don't care about
    the mobile market and the reason why.

    >>
    >>
    >>>> 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.

    >
    > I am, but why should I ignore the "competitor" shortcomings. Seems
    > relevant to me (and to others apparently).


    Recognizing competitor's shortcomings doesn't exactly translate to
    jumping into any post that happens to reference one of them, proclaiming
    them fatally flawed garbage written by clueless fools.
    S.T., Feb 22, 2010
    #19
  20. David Mark

    David Mark Guest

    Andrew Poulos wrote:
    > On 23/02/2010 10:12 AM, S.T. wrote:
    >> On 2/22/2010 2:43 PM, David Mark wrote:
    >>> S.T. wrote:
    >>>> 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.
    >>>
    >>> Still, what does this have to do with jQuery (or not using jQuery?)

    >>
    >> This subtopic began with my reasoning as to why I don't care if jQuery
    >> works for mobile browsers -- specifically, because I don't care about
    >> the mobile market and the reason why.

    >
    > You know that if I was your manager and I brought my shiny new mobile
    > device to you to help me get our company's web site to display on it
    > properly and you told me that you don't care the site doesn't display
    > properly on mobile devices your next task would be to update your resume.


    Well said. The industry needs more managers like you. Unfortunately,
    it is my experience that the typical middle manager is an enabler of
    incompetence. They don't know anything, so they assume that shiny
    jQuery muck is genius, reinforcing the delusions of the programmers and
    making it harder to tell them they are dead wrong (how could a "genius"
    be wrong so often?)

    >
    >>>>>> 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.
    >>>
    >>> I am, but why should I ignore the "competitor" shortcomings. Seems
    >>> relevant to me (and to others apparently).

    >>
    >> Recognizing competitor's shortcomings doesn't exactly translate to
    >> jumping into any post that happens to reference one of them, proclaiming
    >> them fatally flawed garbage written by clueless fools.

    >
    > Still attacking the messenger and not checking whether the message that
    > is carried is valid or not.
    >


    Yes. See also Matt Kruse, who demonstrated your point exactly. Works
    for him! :)
    David Mark, Feb 22, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mythran
    Replies:
    0
    Views:
    2,406
    Mythran
    Aug 24, 2004
  2. Alan Ferrandiz [MCT]
    Replies:
    0
    Views:
    436
    Alan Ferrandiz [MCT]
    Sep 11, 2004
  3. Sweep

    Library in library...

    Sweep, Dec 8, 2003, in forum: C++
    Replies:
    1
    Views:
    378
    Jack Klein
    Dec 9, 2003
  4. David Mark

    TaskSpeed results for My Library

    David Mark, Jan 27, 2010, in forum: Javascript
    Replies:
    90
    Views:
    647
    jdalton
    Feb 11, 2010
  5. David Mark

    My Library TaskSpeed tests updated

    David Mark, Feb 12, 2010, in forum: Javascript
    Replies:
    31
    Views:
    404
    Scott Sauyet
    Feb 23, 2010
Loading...

Share This Page