Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > My Library _passes_ TaskSpeed in IE < 7

Reply
Thread Tools

My Library _passes_ TaskSpeed in IE < 7

 
 
David Mark
Guest
Posts: n/a
 
      02-18-2010
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.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      02-18-2010
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/T...d/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).
 
Reply With Quote
 
 
 
 
S.T.
Guest
Posts: n/a
 
      02-19-2010
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/T...d/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.



 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
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/T...d/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).
 
Reply With Quote
 
Eric Bednarz
Guest
Posts: n/a
 
      02-19-2010
David Mark <(E-Mail Removed)> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
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/T...d/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).
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-19-2010
Eric Bednarz wrote:
> David Mark <(E-Mail Removed)> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-20-2010
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.
 
Reply With Quote
 
S.T.
Guest
Posts: n/a
 
      02-20-2010
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


 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-20-2010
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 . 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).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
My Library TaskSpeed tests updated David Mark Javascript 31 02-23-2010 08:08 PM
TaskSpeed results for My Library David Mark Javascript 90 02-11-2010 05:38 PM
Re: Difference between Web Control Library and Class Library Alan Ferrandiz [MCT] ASP .Net 0 09-11-2004 01:51 PM
Re: Difference between Web Control Library and Class Library Mythran ASP .Net 0 08-24-2004 05:53 PM
Library in library... Sweep C++ 1 12-09-2003 04:12 AM



Advertisments