My Library _passes_ TaskSpeed in IE < 7
David Mark
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
> 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).
S.T.
> 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.
David Mark
> 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). :)
Andrew Poulos
Under IE 6 on Win XP the bind selector caused the My Library cell to go red:
781 844
msfound
though all the libraries found 844 items.
Times:
jquery 1.4.1 (alter) came in at 2833
mylib 2862
mylib (qsa) 2102
mylib (alter) 2534
prototype 1.6.0.3 came in at 30,825 with tonnes of errors.
Andrew Poulos
Eric Bednarz
> 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. :-)
David Mark
> 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
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
[...]
>
> 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.
S.T.
>> 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
David Mark
> 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).
S.T.
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.
Andrew Poulos
...
> Oy! Just noticed you went off on another rant/bashfest in some Ajaxian
> comments. Thought we were making progress. I don't think you're able to
> rationally discuss jQuery and similar libraries so I'm not gonna spend
> any more time trying.
I think that's because DM has made one objective criticism after another
about jquery and the response by "fans of jquery" is typically of the
nature "it works for me" (instead of rationally discussing each
criticism raised).
Andrew Poulos
David Mark
> 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
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. ;)
S.T.
>> 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.
Matt Kruse
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
David Mark
> 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
> On Feb 22, 2:01 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
>> On 23/02/2010 6:35 AM, S.T. wrote:
>>> Oy! Just noticed you went off on another rant/bashfest in some Ajaxian
>>> comments. Thought we were making progress. I don't think you're able to
>>> rationally discuss jQuery and similar libraries so I'm not gonna spend
>>> any more time trying.
>> I think that's because DM has made one objective criticism after another
>> about jquery and the response by "fans of jquery" is typically of the
>> nature "it works for me" (instead of rationally discussing each
>> criticism raised).
>
> DM is very good at identifying very specific problems in jQuery and
> other libs.
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?
S.T.
> 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.
David Mark
> 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... :)
Andrew Poulos
> 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.
>>>>> 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.
Andrew Poulos
David Mark
> 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! :)
S.T.
> On 23/02/2010 10:12 AM, S.T. wrote:
>> 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.
>
Thank goodness I'm a part-owner (though not majority) and not all that
easy to get rid of. I'm not discussing a client here -- I might not be
so cavalier about my decision to write off mobile for the time being
were it for a client who's business I did not know inside out. Hell,
were it for a client I could milk more billable hours to ensure mobile
bliss, regardless of mobile's actual value to that business.
Look, I could put up a mobile-friendly version of the site in a matter
of days. At present there is little to no value. You don't have to
believe me, but at least believe I'm working off more data than my gut
instinct and simply maintain I'm interpreting the data wrong.
Fact is my resources are better served elsewhere, though admittedly
participating in endless loop arguments on cljs might suggest otherwise.
>> 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.
I'd say "attacking" is overstating my demeanor just a bit, while David
being labeled something so innocent as "messenger" is a bit generous.
David can't envision a scenario where using one of the major libraries
makes sense whereas I'm quite certain there are scenarios where it makes
sense and others where it isn't so wise. We appear to be equally baffled
by the other's conclusion. There doesn't seem to be much common ground
to discuss further.
Andrew Poulos
> On 2/22/2010 3:40 PM, Andrew Poulos wrote:
>> On 23/02/2010 10:12 AM, S.T. wrote:
>>> 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.
>>
>
> Thank goodness I'm a part-owner (though not majority) and not all that
> easy to get rid of. I'm not discussing a client here -- I might not be
> so cavalier about my decision to write off mobile for the time being
> were it for a client who's business I did not know inside out. Hell,
> were it for a client I could milk more billable hours to ensure mobile
> bliss, regardless of mobile's actual value to that business.
You think that caring about mobile devices is equivalent to defrauding
your clients???
> Look, I could put up a mobile-friendly version of the site in a matter
> of days. At present there is little to no value. You don't have to
> believe me, but at least believe I'm working off more data than my gut
> instinct and simply maintain I'm interpreting the data wrong.
>
> Fact is my resources are better served elsewhere, though admittedly
> participating in endless loop arguments on cljs might suggest otherwise.
Fact is, I couldn't hire you simply because you don't care about a
growing sector of the market.
>>> 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.
>
> I'd say "attacking" is overstating my demeanor just a bit, while David
> being labelled something so innocent as "messenger" is a bit generous.
Ok, if your prefer, "you appear to continue to fail to address the valid
objective criticisms that have been raised".
> David can't envision a scenario where using one of the major libraries
Yes of course, its David's fault that he publicises faults he finds in
GP libraries.
> makes sense whereas I'm quite certain there are scenarios where it makes
I guess if you can offload the responsibility for things not working
(eg. lack of support for mobile devices, or XHTML support) then you're
lucky.
> sense and others where it isn't so wise. We appear to be equally baffled
> by the other's conclusion. There doesn't seem to be much common ground
> to discuss further.
I doubt anyone wants a discussion per se. I want an argument where one
side presents a premise drawn on various facts (which David has done)
and the other side counters the premise with facts of their own (which
no one appears to have done). Not talking about whether calling David a
"messenger" is generous.
Andrew Poulos
S.T.
> On 23/02/2010 11:29 AM, S.T. wrote:
>> Thank goodness I'm a part-owner (though not majority) and not all that
>> easy to get rid of. I'm not discussing a client here -- I might not be
>> so cavalier about my decision to write off mobile for the time being
>> were it for a client who's business I did not know inside out. Hell,
>> were it for a client I could milk more billable hours to ensure mobile
>> bliss, regardless of mobile's actual value to that business.
>
> You think that caring about mobile devices is equivalent to defrauding
> your clients???
The fact is for many business' mobile, at present, is about as useful as
a flash-intro page. You know it and I know it. You sell pizzas? OK,
mobile might have some value. You sell chemical analysis of dirt soil
samples for the oil industry? Mobile has absolutely no value whatsoever.
In the future? Perhaps, as who knows for certain. But a client should at
least be told your doing extra work and/or constraining design choices
based on your speculative assessment of the web's future. "Sure, the
layout is pretty lackluster BUT it scales perfectly for 320px browsers
for all that mobile traffic headed your way!!! One site to cover it
all!!" That's not an example of fraud, it's an example of exaggerating
your expertise and, likely, incompetence.
>> Fact is my resources are better served elsewhere, though admittedly
>> participating in endless loop arguments on cljs might suggest otherwise.
>
> Fact is, I couldn't hire you simply because you don't care about a
> growing sector of the market.
Among the list of reasons you couldn't hire me, this one ranks pretty low.
>>
>> I'd say "attacking" is overstating my demeanor just a bit, while David
>> being labelled something so innocent as "messenger" is a bit generous.
>
> Ok, if your prefer, "you appear to continue to fail to address the valid
> objective criticisms that have been raised".
While David may have made some valid points and illustrated some errors
in the past 2.5 years (really? 30 months of yelling about this?)
preaching from his code-perfect pulpit, it's a rare soul that would use
the term "objective" when describing that effort.
>> David can't envision a scenario where using one of the major libraries
>
> Yes of course, its David's fault that he publicises faults he finds in
> GP libraries.
I don't think anyone minds David pointing out flaws. Many find the
analysis useful. Rather, it's the inevitable tantrum added to each
criticism where he derides every developer for not dropping everything
that instant to fix what he's found (or, most often, starting from
scratch) and mocking each user for not immediately abandoning all use of
a library until it meets his threshhold for perfection.
"Publicise" <> http://google.com/search?q=davidmark+site%3Aajaxian.com
>> makes sense whereas I'm quite certain there are scenarios where it makes
>
> I guess if you can offload the responsibility for things not working
> (eg. lack of support for mobile devices, or XHTML support) then you're
> lucky.
I don't know where XHTML came into the conversation. I don't know if the
libraries support it or not as, again, I don't care (I'd have to serve
it up as text/html anyhow). The only possible merit to XHTML is for
machines to more easily read the document -- not too concerned if my
client-side scripting works for a spider.
>> sense and others where it isn't so wise. We appear to be equally baffled
>> by the other's conclusion. There doesn't seem to be much common ground
>> to discuss further.
>
> I doubt anyone wants a discussion per se. I want an argument where one
> side presents a premise drawn on various facts (which David has done)
> and the other side counters the premise with facts of their own (which
> no one appears to have done). Not talking about whether calling David a
> "messenger" is generous.
No one is claiming the libraries are flawless. I don't know what you
(and presumably David) read that suggests otherwise.
David Mark
> On 2/22/2010 7:12 PM, Andrew Poulos wrote:
>> On 23/02/2010 11:29 AM, S.T. wrote:
>>> Thank goodness I'm a part-owner (though not majority) and not all that
>>> easy to get rid of. I'm not discussing a client here -- I might not be
>>> so cavalier about my decision to write off mobile for the time being
>>> were it for a client who's business I did not know inside out. Hell,
>>> were it for a client I could milk more billable hours to ensure mobile
>>> bliss, regardless of mobile's actual value to that business.
>>
>> You think that caring about mobile devices is equivalent to defrauding
>> your clients???
>
> The fact is for many business' mobile, at present, is about as useful as
> a flash-intro page.
That's nonsensical hyperbole.
> You know it and I know it.
That's an assertion you aren't qualified to make.
> You sell pizzas? OK,
> mobile might have some value. You sell chemical analysis of dirt soil
> samples for the oil industry? Mobile has absolutely no value whatsoever.
That's crazy. Virtually everyone carries a mobile browser these days
(and the ones who may be unable to afford such are likely using older
browsers and dial-up at home, which IIRC you don't care about either).
>
> In the future? Perhaps, as who knows for certain.
Mobile browsers are important right now (and have been for years).
> But a client should at
> least be told your doing extra work and/or constraining design choices
> based on your speculative assessment of the web's future.
What extra work? That's the fallacy in this (and similar) arguments.
Doing it right takes no longer than doing it wrong (and doing it wrong
leads to making two sites down the road when one would have done).
> "Sure, the
> layout is pretty lackluster BUT it scales perfectly for 320px browsers
> for all that mobile traffic headed your way!!! One site to cover it
> all!!"
You don't get it at all. Did you look at that example I showed you.
Did you consider it lackluster because it only had two columns? How
many columns do you think are wise? And BTW, it adjusts to one column
in most older mobile devices.
Here it is again:-
Other than it is waiting for a real logo and some real content, what do
you find "lackluster" about that?
Also, if you use fluid layouts, they will scale, regardless of the
number of columns (and more than two is too many anyway).
> That's not an example of fraud, it's an example of exaggerating
> your expertise and, likely, incompetence.
Huh?
>
>>> Fact is my resources are better served elsewhere, though admittedly
>>> participating in endless loop arguments on cljs might suggest otherwise.
>>
>> Fact is, I couldn't hire you simply because you don't care about a
>> growing sector of the market.
>
> Among the list of reasons you couldn't hire me, this one ranks pretty low.
Any time I hear a Web developer telling me they "don't care" about this
browser or that sector, I figure that means they just let those break,
which is completely incompetent. It's not hard to write documents that
work, even in environments that you don't care about. Make no mistake
that your end-users don't know (or care) what you care about. All they
know is whether your sites work. If your scripts blow up during
initialization, there's a good chance that your sites will not work,
perhaps wasting the end-users time (e.g. they fill out a form, hit
submit and nothing happens).
>
>>>
>>> I'd say "attacking" is overstating my demeanor just a bit, while David
>>> being labelled something so innocent as "messenger" is a bit generous.
>>
>> Ok, if your prefer, "you appear to continue to fail to address the valid
>> objective criticisms that have been raised".
>
> While David may have made some valid points and illustrated some errors
> in the past 2.5 years (really? 30 months of yelling about this?)
> preaching from his code-perfect pulpit, it's a rare soul that would use
> the term "objective" when describing that effort.
I never said anything about "perfect code" (mine or otherwise). That's
something that they beetle-browed incompetents toss around, but they
made it up out of thin air.
As for valid points, what are the last five letters in jQuery? What do
queries do? They _read_ (or attempt to read) documents. And what did
they foul up the worst on? There you go. No amount of Matt Kruse (or
the like) dismissing every test case as an attribute (or scenario) they
don't care about is going to change that.
Then there is the ridiculous height/width code, which makes another
important task near impossible. Not just problematic, but virtually
impossible in a cross-browser fashion. That's two and if you have read
my reviews, you know there are boatloads more. Granted, they have fixed
some of them, but where are the thanks for pointing them out? All I
hear is that they don't like my "yelling".
>
>>> David can't envision a scenario where using one of the major libraries
>>
>> Yes of course, its David's fault that he publicises faults he finds in
>> GP libraries.
>
> I don't think anyone minds David pointing out flaws.
Resig - for one - sure seems to. :)
> Many find the
> analysis useful.
Yes, those are called competent developers. Eventually they convince
the incompetents. It's like dropping a boulder into a large pond. The
waves eventually break on all shores.
> Rather, it's the inevitable tantrum added to each
> criticism where he derides every developer for not dropping everything
> that instant to fix what he's found (or, most often, starting from
> scratch) and mocking each user for not immediately abandoning all use of
> a library until it meets his threshhold for perfection.
That's your own interpretation. I've done nothing but try to help the
typical jQuery abuser. I've never blamed the ignorant, but those who
attempt to deceive them.
>
> "Publicise" <> http://google.com/search?q=davidmark+site%3Aajaxian.com
Huh?
>
>>> makes sense whereas I'm quite certain there are scenarios where it makes
>>
>> I guess if you can offload the responsibility for things not working
>> (eg. lack of support for mobile devices, or XHTML support) then you're
>> lucky.
>
> I don't know where XHTML came into the conversation.
Somebody else expressed surprise that jQuery doesn't support XHTML (same
as Resig did when I pointed it out to him years ago). XHTML served as
(and error-corrected to) HTML is not XHTML, but that is beyond the
typical neophyte's understanding.
> I don't know if the
> libraries support it or not as, again, I don't care (I'd have to serve
> it up as text/html anyhow).
They don't and see above. And no, it's not a crime to forget about real
XHTML as it is a dead issue on the Web (and has been for years, save for
parts of the mobile sector).
> The only possible merit to XHTML is for
> machines to more easily read the document -- not too concerned if my
> client-side scripting works for a spider.
The issue is that library projects like jQuery ignorantly claim to
support something they don't.
>
>>> sense and others where it isn't so wise. We appear to be equally baffled
>>> by the other's conclusion. There doesn't seem to be much common ground
>>> to discuss further.
>>
>> I doubt anyone wants a discussion per se. I want an argument where one
>> side presents a premise drawn on various facts (which David has done)
>> and the other side counters the premise with facts of their own (which
>> no one appears to have done). Not talking about whether calling David a
>> "messenger" is generous.
>
> No one is claiming the libraries are flawless. I don't know what you
> (and presumably David) read that suggests otherwise.
>
There's a big difference between flawless and something that falls apart
every six months or so, requiring an incompatible "upgrade", re-testing,
etc. just to support the latest modern browsers (excepting Opera of
course) in their default configurations. It's crazy when you realize
that IE8 will be treated (by them) like Opera 6 in a few years (i.e.
they won't "care" about it). That's not a sound scripting or business
strategy.
And then there's the fact that, even with endless "upgrades", they never
get anything close to right (e.g. attribute handling in IE, which is
hardly a trivial concern for a *query* engine).
S.T.
> You don't get it at all. Did you look at that example I showed you.
> Did you consider it lackluster because it only had two columns? How
> many columns do you think are wise? And BTW, it adjusts to one column
> in most older mobile devices.
>
> Here it is again:-
>
> http://www.hartkelaw.net/
>
> Other than it is waiting for a real logo and some real content, what do
> you find "lackluster" about that?
Seriously? We're seriously off-topic but I'll play.
On an iPhone 3G I have to pinch and pull until I set the just the left
column in the viewport in order to possibly read copy without having to
scroll left-and-right on every line, and at that zoom it's still a
struggle to read... and my eyes aren't that bad yet.
If I then want to use the right-hand navigation I need to scroll over to
the right, where I have to pull to zoom in further to possibly read the
link text which is inexplicably set at 3/4's of browser default, a very
odd design choice for primary navigation. If I want to go back to the
main text it's another scroll and zoom correction.
This is not what I would call a mobile-friendly site. If one is willing
to jump through hoops, it's mobile-accessible. And that's a big "IF".
If mobile is actually relevant, embrace it. Cater to what a mobile user
wants, strip out the extraneous and ensure it's easy at very narrow
widths. That means it's own site:
www.yahoo.com -> m.yahoo.com
www.papajohns.com -> mobile.papajohns.com
www.digg.com -> m.digg.com
If mobile REALLY matters to a business, apps on the various dominant
platforms that solve specific tasks for the mobile user are the way to go.
PS: On a more traditional monitor with the browser maximized, the site's
main text is borderline unreadable. Seriously... hop on a 1600px+ width
monitor, maximize the browser and try and read the privacy policy page.
It's a struggle to pull the eye across ~30 words to the beginning of the
next line. Aim for 12-14 words per column (like Usenet) without forcing
the user to resize his browser to do so.
At least we agree on XHTML.
David Mark
> On 2/23/2010 12:32 PM, David Mark wrote:
>> You don't get it at all. Did you look at that example I showed you.
>> Did you consider it lackluster because it only had two columns? How
>> many columns do you think are wise? And BTW, it adjusts to one column
>> in most older mobile devices.
>>
>> Here it is again:-
>>
>> http://www.hartkelaw.net/
>>
>> Other than it is waiting for a real logo and some real content, what do
>> you find "lackluster" about that?
>
> Seriously? We're seriously off-topic but I'll play.
>
> On an iPhone 3G I have to pinch and pull until I set the just the left
> column in the viewport in order to possibly read copy without having to
> scroll left-and-right on every line, and at that zoom it's still a
> struggle to read... and my eyes aren't that bad yet.
Or you could just close the second column. The fluid layout takes care
of the rest, but I don't remember what the minimum width is set to, so
it may need a slight adjustment to avoid horizontal scrolling in those
devices.
It was written before these full-featured mobile browsers were an issue,
so perhaps I need to make some adjustments to the layout. Still,
there's no way it should require a separate site. I did test it in lots
of phones at the time and the handheld style sheets made it work
perfectly as a single-column layout in every one of them. These were
displays that had no shot at working with multiple columns. Clearly the
game has changed a bit since then and whenever my client gets their
content together I will test on iPhones/iPods/etc and adjust as
necessary (but won't create a whole new site).
>
> If I then want to use the right-hand navigation I need to scroll over to
> the right, where I have to pull to zoom in further to possibly read the
> link text which is inexplicably set at 3/4's of browser default, a very
> odd design choice for primary navigation. If I want to go back to the
> main text it's another scroll and zoom correction.
I agree that 75% is too small. The site has been in a holding pattern
for years. I'm sure I will adjust the grid whenever I get some real
content to put into it. Didn't look particularly bad in anything I
tested two years ago, but I didn't realize I had left the navigation
text so small. Still, adjusting something like that does not require a
second site (in fact 75% on the desktop is not ideal either).
>
> This is not what I would call a mobile-friendly site. If one is willing
> to jump through hoops, it's mobile-accessible. And that's a big "IF".
As mentioned, at the time it was written, it was a _very_ mobile
friendly site (one of the few such examples out there AFAIK). These
newer mobile devices are closer to a desktop experience, so they ignore
handheld style sheets. And I'd venture it is far closer to friendly in
iPhones - for example - than the typical Website. It won't take a whole
new site to bridge the gap, that much is for sure.
>
> If mobile is actually relevant, embrace it. Cater to what a mobile user
> wants, strip out the extraneous and ensure it's easy at very narrow
> widths. That means it's own site:
>
> www.yahoo.com -> m.yahoo.com
> www.papajohns.com -> mobile.papajohns.com
> www.digg.com -> m.digg.com
Or just adjust the font sizes a bit. Making a whole new site seems a
hard way to go. ;)
>
> If mobile REALLY matters to a business, apps on the various dominant
> platforms that solve specific tasks for the mobile user are the way to go.
That's beside the point. They can still hit your Website with the browser.
>
> PS: On a more traditional monitor with the browser maximized, the site's
> main text is borderline unreadable.
I don't consider long lines to be ideal, but I don't think they are at
all unreadable.
> Seriously... hop on a 1600px+ width
> monitor, maximize the browser and try and read the privacy policy page.
> It's a struggle to pull the eye across ~30 words to the beginning of the
> next line. Aim for 12-14 words per column (like Usenet) without forcing
> the user to resize his browser to do so.
Yes, I know, it needs a max-width rule for the paragraphs.
>
> At least we agree on XHTML.
>
It's a dead issue on the Web and has been for years.
Matt Kruse
> That's crazy. Virtually everyone carries a mobile browser these days
Where is your evidence? I would guess that the number of people who
access the web via mobile device is in the single-digit percentages.
> Mobile browsers are important right now (and have been for years).
They are somewhat important, to some people. Certainly not a priority
for most. Yet.
Matt Kruse
Matt Kruse
> I want an argument where one
> side presents a premise drawn on various facts (which David has done)
> and the other side counters the premise with facts of their own (which
> no one appears to have done).
Done many, many times. And unilaterally, unjustifiably dismissed every
time by DM.
DM has answers for people who fit exactly within the constraints that
he places on how software should be written. Unfortunately, most of
the development world finds themselves in very different situations,
where his answers don't fit. And then he screams louder and stomps his
feet because no one will listen to him.
He reminds me of the linux zealots who just can't understand how
_anyone_ could continue using Windows, who constantly reminds everyone
how broken Windows is, who blogs about its problems and errors, and
who designs the coolest, most awesome software for linux users but
doesn't understand why it hasn't revolutionized the world yet. The
fact is, most people use Windows. And if you don't understand why, and
you refuse to understand why, and you are incapable of understanding
all the factors that go into the decision, and you stubbornly insist
that everyone is wrong and should switch to linux immediately, then
you're going to continue preaching your sermon to an empty church. And
you're going to continue having little if any impact on the world
around you. Which is exactly where DM finds himself. And yet he still
can't quite figure out why.
Question: If DM has the answer that most people should be looking for,
why aren't most people following his suggestions?
Answer: Because he doesn't understand what most people are looking
for, and doesn't have a real answer for those people anyway.
IMO,
Matt Kruse
David Mark
> On Feb 23, 2:32 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> That's crazy. Virtually everyone carries a mobile browser these days
>
> Where is your evidence? I would guess that the number of people who
> access the web via mobile device is in the single-digit percentages.
We had this discussion years ago. Virtually everybody has a phone.
Virtually all phones have browsers (and have for years). So re-read
what I said as you seem to be responding to something other point.
And so what if only single digit percentages use the browsers regularly?
And that's just a guess on your part anyway.
>
>> Mobile browsers are important right now (and have been for years).
>
> They are somewhat important, to some people. Certainly not a priority
> for most. Yet.
>
But, as usual, you don't get it. Your site doesn't have to be
_unusable_ (as many are) in any browser (tiny or not). If you use
jQuery, many mobile devices will refuse to load the page as the assets
are too large (at least that was my experience with them a couple of
years back). The latest and greatest mobile devices (e.g. iPhones)
won't _cache_ jQuery, which is a self-imposed disaster, particularly
when you know you are only utilizing a tiny percentage of the script.
And then there is the fact that most mobile browsers are limited in
their capabilities, so you have to use progressive enhancement, which
jQuery makes impossible by "smoothing over" the important details about
the environment (i.e. providing a static API that blows up in
environments that it isn't capable of handling).
And, as for the "yet" bit. Do you plan to go back and re-write every
site you ever made whenever you feel like mobile "matters?" Seems like
a short-sighted approach and will be very hard on your clients' wallets.
Matt Kruse
> > Where is your evidence? I would guess that the number of people who
> > access the web via mobile device is in the single-digit percentages.
> We had this discussion years ago. Virtually everybody has a phone.
Disagree
> Virtually all phones have browsers (and have for years).
Disagree
> So re-read
> what I said as you seem to be responding to something other point.
I'm responding to your exaggeration: "Virtually everyone carries a
mobile browser these days".
> And so what if only single digit percentages use the browsers regularly?
> And that's just a guess on your part anyway.
Indeed. It might be high.
> >> Mobile browsers are important right now (and have been for years).
> > They are somewhat important, to some people. Certainly not a priority
> > for most. Yet.
> And, as for the "yet" bit. Do you plan to go back and re-write every
> site you ever made whenever you feel like mobile "matters?"
Probably, because I think desktop browsers and mobile browsers justify
two different approaches to presenting the content, and m.mysite.com
is a smart move for now.
Also, since most sites won't be concerned about mobile traffic right
now, it's best for most of them to not worry about it in the near
future until things settle down a bit and the direction and technology
of the mobile web is more solid. Investing now simply won't pay off
for most companies, IMO.
Matt Kruse
David Mark
> On Feb 22, 9:12 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
>> I want an argument where one
>> side presents a premise drawn on various facts (which David has done)
>> and the other side counters the premise with facts of their own (which
>> no one appears to have done).
>
> Done many, many times. And unilaterally, unjustifiably dismissed every
> time by DM.
No, that's the opposite of what occurred. Every time I point out one of
jQuery's many flaws, you claim it isn't something you care about. What
are the last five letters in jQuery, again? If it can't _read_
dcouments straight, it is a failure. It doesn't matter if you "don't
care" about attribute X or Y (or heights, widths, etc.) Virtually none
of the mentioned shortcomings are documented either, so how would you
know what you are supposed to "care" about? :)
Did you care about ActiveX being disabled in corporate environments
before I pointed out that jQuery would unceremoniously blow up in such
cases or were you oblivious like the jQuery developers? Yeah, they
eventually fixed it (after I beat them over the head with it for
_years_), but think of how many scattered versions of jQuery there are
out there right now (many of which exhibit this fatal flaw). Maybe if
you had listened instead of dismissing everything as "edge cases",
things wouldn't be such a mess (after all, Resig and co. listen to you
at least some of the time).
>
> DM has answers for people who fit exactly within the constraints that
> he places on how software should be written.
That's ridiculous. If you can't measure an element's dimensions or read
its attributes with any reasonable reliability, you can't possibly have
a firm DOM scripting foundation. When has such folly ever worked (for
any sort of software). It's like a calculator that sometimes gives the
wrong answers (and degrades over time without constant, expensive
maintenance until all of the answers are wrong). Endless rewrites are
not a good strategy for the Web (for reasons that I hope are obvious by
now).
> Unfortunately, most of
> the development world finds themselves in very different situations,
> where his answers don't fit.
That's pure lunacy. Often I'm the guy they call to clean up their
messes (and the cleanup techniques haven't changed much over the years).
If you would just learn instead of fixating on the messenger, you would
understand.
> And then he screams louder and stomps his
> feet because no one will listen to him.
I'd say that nobody is listening to _you_ at this point (and I'm
definitely a different story).
>
> He reminds me of the linux zealots who just can't understand how
> _anyone_ could continue using Windows, who constantly reminds everyone
> how broken Windows is, who blogs about its problems and errors, and
> who designs the coolest, most awesome software for linux users but
> doesn't understand why it hasn't revolutionized the world yet. The
> fact is, most people use Windows. And if you don't understand why, and
> you refuse to understand why, and you are incapable of understanding
> all the factors that go into the decision, and you stubbornly insist
> that everyone is wrong and should switch to linux immediately, then
> you're going to continue preaching your sermon to an empty church.
All irrelevant apples and oranges (as usual). Where's your brain?
> And
> you're going to continue having little if any impact on the world
> around you. Which is exactly where DM finds himself. And yet he still
> can't quite figure out why.
That's also ridiculous. I've had far more impact on your "real world"
than you care to admit. Who is it that keeps getting things fixed in
jQuery (for example?) Sure as hell not you. In fact, you have tried to
parrot my ideas to jQuery from time to time and are usually shouted
down. We've seen it over and over, so why continue to delude yourself?
>
> Question: If DM has the answer that most people should be looking for,
> why aren't most people following his suggestions?
But they do (albeit years later in most cases). You are just being
disingenuous (also as usual).
>
> Answer: Because he doesn't understand what most people are looking
> for, and doesn't have a real answer for those people anyway.
>
You are not one to comment on understanding; that's for sure. ;)
David Mark
> On Feb 23, 4:49 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> Where is your evidence? I would guess that the number of people who
>>> access the web via mobile device is in the single-digit percentages.
>> We had this discussion years ago. Virtually everybody has a phone.
>
> Disagree
You are just indefatigably disagreeable. I can't help you there.
>
>> Virtually all phones have browsers (and have for years).
>
> Disagree
Same. Even throw-away phones have had browsers since the middle part of
the last decade. Where have you been?
>
>> So re-read
>> what I said as you seem to be responding to something other point.
>
> I'm responding to your exaggeration: "Virtually everyone carries a
> mobile browser these days".
>
>> And so what if only single digit percentages use the browsers regularly?
>> And that's just a guess on your part anyway.
>
> Indeed. It might be high.
Or low. So why throw out made-up statistics?
>
>>>> Mobile browsers are important right now (and have been for years).
>>> They are somewhat important, to some people. Certainly not a priority
>>> for most. Yet.
>> And, as for the "yet" bit. Do you plan to go back and re-write every
>> site you ever made whenever you feel like mobile "matters?"
>
> Probably, because I think desktop browsers and mobile browsers justify
> two different approaches to presenting the content, and m.mysite.com
> is a smart move for now.
No, it is actually _less_ smart today as the two are obviously
converging. And I didn't have problems with most of the older phones
either.
>
> Also, since most sites won't be concerned about mobile traffic right
> now, it's best for most of them to not worry about it in the near
> future until things settle down a bit and the direction and technology
> of the mobile web is more solid. Investing now simply won't pay off
> for most companies, IMO.
>
Investing? Two sites are more expensive than one. ;) Furthermore, one
site that (sort of) works on the desktop, but blows up in mobile devices
is certainly a bad idea.
David Mark
[...]
>
> He reminds me of the linux zealots who just can't understand how
> _anyone_ could continue using Windows, who constantly reminds everyone
> how broken Windows is, who blogs about its problems and errors, and
> who designs the coolest, most awesome software for linux users but
> doesn't understand why it hasn't revolutionized the world yet. The
> fact is, most people use Windows.
And, though irrelevant to browser scripting, perhaps you missed the
success of the new Macs. Put a hell of dent in Windows, didn't they?
And what do they run? ;)
Garrett Smith
> 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.
>
What it means for something to work is that that thing fulfills a
contract of functioning in the way it has been specified to function.
If JQuery is expected to be a "cross browser, CSS3 Compliant" selector
engine, as the website states, then jQuery does not work.
JQuery is not a "CSS3 Compliant" selector engine.
Other claims on jQuery homepage include: "fast and concise" and
"lightweight footprint". When compared to something like Dojo, those
claims may seem correct, but then almost anything is lightweight
compared to Dojo except maybe Ext-js (YUI 3 bulking, too).
The other things on the jQuery homepage include graphics, lists of
well-known companies using jQuery, lists of books on jQuery. Seminars on
learning jQuery. All of these things contribute to appeal to popularity,
but cannot be used as stipulations for defining "works".
If, however, by "works", you mean that you used it did what you wanted,
then we have a different definition of "works".
[...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
Matt Kruse
> What it means for something to work is that that thing fulfills a
> contract of functioning in the way it has been specified to function.
Very little - if any - software "fulfills a contract of functioning"
100% of the time, without problems. I use many pieces of software
every day that surely have countless unresolved bugs. Yet they still
provide much value to me. I'd say they "work" as long as those
problems do not cause a problem for me, despite their existence.
In that vain, jQuery "works" because it does not cause a problem for
most users, despite its flaws. It works. Perfectly? No. But it works.
The idealistic, unachievable goal of software development is bug-free
perfection. No piece of software - including jQuery - should be judged
by that measure. Instead, you have to look at the big picture and many
factors, of which technical robustness if just one.
Matt Kruse
David Mark
> On Feb 23, 6:33 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> What it means for something to work is that that thing fulfills a
>> contract of functioning in the way it has been specified to function.
>
> Very little - if any - software "fulfills a contract of functioning"
> 100% of the time, without problems.
Now ain't that the truth. Particularly browser scripting libraries,
which are pretty much crap shoots.
> I use many pieces of software
> every day that surely have countless unresolved bugs. Yet they still
> provide much value to me.
So what? It's stupid to stick with something you _know_ is broken when
better alternatives have existed for _years_.
> I'd say they "work" as long as those
> problems do not cause a problem for me, despite their existence.
But you are programming for the public, not yourself.
>
> In that vain, jQuery "works" because it does not cause a problem for
> most users, despite its flaws. It works. Perfectly? No. But it works.
Most users?! How do you figure that? You've been in their forums.
>
> The idealistic, unachievable goal of software development is bug-free
> perfection.
You are just babbling (as usual).
> No piece of software - including jQuery - should be judged
> by that measure.
Perfect is clearly out of the realm of possibility for that thing,
despite the fact that it's just a silly script. It's not even _close_
to perfect after all of these years because they designed something they
had no idea how to build.
> Instead, you have to look at the big picture and many
> factors, of which technical robustness if just one.
Babbling. You practically begged me to post a better library than
jQuery years ago and here you are still clinging to and apologizing for
jQuery. And you have tried to tell them over and over about various
"badly broken" (your words) methods and they didn't even understand that
there was a problem (let alone fix them). Still, here you are
apologizing further. How goofy is that?
Every app, book and online example out there uses the "badly broken"
attr method. Nobody seems to be able to define what it is _supposed_ to
do, let alone what it does in reality (which changes randomly from one
release to the next). The queries aren't compatible with other
libraries, the specs or the newly-added QSA layer. It's pure madness to
use something that fouled up on a Website. I know, you think that
saving a few lines of code here or there matters, but how so when you
have to add thousands of lines of demonstrably dubious code to achieve
these "savings?"
And, again, you admittedly can't even upgrade the piece of junk. Why
you would be happy with 1.2x in an IE6-only environment is beyond me as
I've demonstrated how screwed up that version is in IE6. Be fair, all
of them are screwed up in IE6, but the older ones are far worse.
Matt Kruse
> > I use many pieces of software
> > every day that surely have countless unresolved bugs. Yet they still
> > provide much value to me.
> So what? It's stupid to stick with something you _know_ is broken when
> better alternatives have existed for _years_.
Your logic is flawed. I know technically better alternatives exist
than Windows, yet I still use it. Again, the point you never seem to
acknowledge - there are more factors than just the technical quality
of a solution. You continually choose to ignore that.
> You are just babbling (as usual).
This is how you dismiss any statement you don't like.
Matt Kruse
David Mark
> On Feb 23, 9:18 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> I use many pieces of software
>>> every day that surely have countless unresolved bugs. Yet they still
>>> provide much value to me.
>> So what? It's stupid to stick with something you _know_ is broken when
>> better alternatives have existed for _years_.
>
> Your logic is flawed. I know technically better alternatives exist
> than Windows, yet I still use it.
Your focus is blurry. We are talking about browser scripting libraries,
specifically jQuery. You have been waffling for years about it. It's
broken, it's not, etc. The end result is you still defend this silly
script, which is getting worse every day. You do realize that the whole
"Sizzle" thing is a fraud, right? It's a superficial speed boost at the
expense of (even more) inconsistent behavior. Meanwhile, gEBI, gEBTN,
etc. are virtually 100% reliable cross-browser (even in off-brands,
older versions of the majors, mobile UA's, etc.) It's madness to
continue on the jQuery course at this point (as, in reality, has been
for years).
> Again, the point you never seem to
> acknowledge - there are more factors than just the technical quality
> of a solution. You continually choose to ignore that.
Not when it comes to a silly (and fairly trivial) script that is little
more than an awkward QSA wrapper at this point. And, of course, in
browsers without QSA, it works slightly differently. Consistency was
supposed to be the selling point of this thing, remember? Well, and
"conciseness" which is ludicrous as it is a 70K hit to start with. And
speed, which we know is a joke at this point. What's left to cling to?
A brand name?
>
>> You are just babbling (as usual).
>
> This is how you dismiss any statement you don't like.
>
No, babbling is babbling (and that's seemingly all you are good for).
Matt Kruse
> Every time I point out one of
> jQuery's many flaws, you claim it isn't something you care about.
Not quite, but it would be fair if I did.
It's similar to you pointing out that my car will blow up if I push it
to 120mph on a Sunday during a full moon. That's interesting, but if I
know that I will never do that, then it's not a convincing argument
for me to stop driving it.
> Did you care about ActiveX being disabled in corporate environments
> before I pointed out that jQuery would unceremoniously blow up in such
> cases
No
> or were you oblivious like the jQuery developers? Yeah, they
> eventually fixed it (after I beat them over the head with it for
> _years_)
Actually, I politely pointed it out to them and it was fixed the same
day. I got results, you didn't.
> That's ridiculous. If you can't measure an element's dimensions or read
> its attributes with any reasonable reliability, you can't possibly have
> a firm DOM scripting foundation.
You read like a wikipedia article on logical fallacies.
> That's also ridiculous. I've had far more impact on your "real world"
> than you care to admit. Who is it that keeps getting things fixed in
> jQuery (for example?) Sure as hell not you. In fact, you have tried to
> parrot my ideas to jQuery from time to time and are usually shouted
> down. We've seen it over and over, so why continue to delude yourself?
jQuery forum archives surely point to the opposite.
You know what would be interesting, DM? If you wrote up a convincing
article detailing the reasons why a developer should use My Library
instead of jQuery, and the process by which they should do so. You
could target it at business web app developers, for example. Be sure
to cover all the factors that would matter to such a user of jQuery,
not just technical points about attributes and dimensions. That
writeup might actually be useful.
Do I expect you to actually do anything like that? Umm, no. Of course
not.
Matt Kruse
David Mark
> On Feb 23, 5:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Every time I point out one of
>> jQuery's many flaws, you claim it isn't something you care about.
>
> Not quite, but it would be fair if I did.
You don't care that a query-based DOM scripting library can't query
straight? Then I guess you don't care about cross-browser (or even
cross-IE!) consistency. That's an odd stance.
>
> It's similar to you pointing out that my car will blow up if I push it
> to 120mph on a Sunday during a full moon. That's interesting, but if I
> know that I will never do that, then it's not a convincing argument
> for me to stop driving it.
Another ridiculous comparison. When very basic queries fail to achieve
consistent results, even in the very latest browsers, it's time to admit
defeat (though it is clear you never will).
>
>> Did you care about ActiveX being disabled in corporate environments
>> before I pointed out that jQuery would unceremoniously blow up in such
>> cases
>
> No
But anyone aspiring to publish documents to the _Web_ better care about it.
>
>> or were you oblivious like the jQuery developers? Yeah, they
>> eventually fixed it (after I beat them over the head with it for
>> _years_)
>
> Actually, I politely pointed it out to them and it was fixed the same
> day. I got results, you didn't.
No, you would never have even _known_ about it if I hadn't pointed it
out over and over as a ridiculous oversight. Cause and effect.
>
>> That's ridiculous. If you can't measure an element's dimensions or read
>> its attributes with any reasonable reliability, you can't possibly have
>> a firm DOM scripting foundation.
>
> You read like a wikipedia article on logical fallacies.
And how do such articles read? You really are king of inappropriate
(and often incomprehensible) similes.
>
>> That's also ridiculous. I've had far more impact on your "real world"
>> than you care to admit. Who is it that keeps getting things fixed in
>> jQuery (for example?) Sure as hell not you. In fact, you have tried to
>> parrot my ideas to jQuery from time to time and are usually shouted
>> down. We've seen it over and over, so why continue to delude yourself?
>
> jQuery forum archives surely point to the opposite.
You say that assuming I won't bother to post links to your futile
attempts to communicate my ideas (the selected option "issue" in Webkit
comes to mind). And how about that 100+ post thread about attr? That
went nowhere (and it was a full two years after I first raised the issue
with Resig). They are clearly not capable of writing a cross-browser
script and you are clearly ineffectual at enlightening them. Perhaps
you are too polite to be effective? Personally, I wouldn't bother with
them at this point.
>
> You know what would be interesting, DM?
Gee, what MK?
> If you wrote up a convincing
> article detailing the reasons why a developer should use My Library
> instead of jQuery, and the process by which they should do so.
Why would that interest you? You should know the basic reasons by now.
> You
> could target it at business web app developers, for example. Be sure
> to cover all the factors that would matter to such a user of jQuery,
> not just technical points about attributes and dimensions. That
> writeup might actually be useful.
It's been done to death (sans any mention of My Library). And I grow
weary of you dismissing attribute issues as attributes are the basic
building blocks of elements, which add up to documents, which are then
queried (often by attributes). How you can ignore the fact that you
can't get/set dimensions of elements (or documents or windows)
consistently with this magic 70K+ blob of JS is also beyond belief.
What does it do right again?
>
> Do I expect you to actually do anything like that? Umm, no. Of course
> not.
You should have all of the information you need at this point. And what
sort of a disingenuous crank would say something like that after I
published a 10000+ example (in part due to their incessant badgering)
and enough reasons to switch to it to choke a newsgroup. :)
David Mark
10000+ lines in one example, not 10000+ examples. :)
Andrew Poulos
> On Feb 23, 5:03 pm, David Mark<dmark.cins...@gmail.com> wrote:
>> Every time I point out one of
>> jQuery's many flaws, you claim it isn't something you care about.
>
> Not quite, but it would be fair if I did.
>
> It's similar to you pointing out that my car will blow up if I push it
> to 120mph on a Sunday during a full moon. That's interesting, but if I
> know that I will never do that, then it's not a convincing argument
> for me to stop driving it.
How do you know? That is, you can't know you'll *never* drive over
120mph. And would you be happy if you knew the public were driving cars
with such a fatal flaw?
>> Did you care about ActiveX being disabled in corporate environments
>> before I pointed out that jQuery would unceremoniously blow up in such
>> cases
>
> No
>
>> or were you oblivious like the jQuery developers? Yeah, they
>> eventually fixed it (after I beat them over the head with it for
>> _years_)
>
> Actually, I politely pointed it out to them and it was fixed the same
> day. I got results, you didn't.
You have to give them feedback on their terms or else they don't accept
it? If I matter-of-factly pointed out a bug would they ignore it/me???
>> That's ridiculous. If you can't measure an element's dimensions or read
>> its attributes with any reasonable reliability, you can't possibly have
>> a firm DOM scripting foundation.
>
> You read like a wikipedia article on logical fallacies.
Still the logic seem robust whereas yours seems lacking.
>> That's also ridiculous. I've had far more impact on your "real world"
>> than you care to admit. Who is it that keeps getting things fixed in
>> jQuery (for example?) Sure as hell not you. In fact, you have tried to
>> parrot my ideas to jQuery from time to time and are usually shouted
>> down. We've seen it over and over, so why continue to delude yourself?
>
> jQuery forum archives surely point to the opposite.
>
> You know what would be interesting, DM? If you wrote up a convincing
> article detailing the reasons why a developer should use My Library
> instead of jQuery, and the process by which they should do so. You
> could target it at business web app developers, for example. Be sure
> to cover all the factors that would matter to such a user of jQuery,
> not just technical points about attributes and dimensions. That
> writeup might actually be useful.
>
> Do I expect you to actually do anything like that? Umm, no. Of course
> not.
And if a convincing article were written would you simply ignore it?
Andrew Poulos
David Mark
> On 24/02/2010 3:35 PM, Matt Kruse wrote:
>> On Feb 23, 5:03 pm, David Mark<dmark.cins...@gmail.com> wrote:
>>> Every time I point out one of
>>> jQuery's many flaws, you claim it isn't something you care about.
>>
>> Not quite, but it would be fair if I did.
>>
>> It's similar to you pointing out that my car will blow up if I push it
>> to 120mph on a Sunday during a full moon. That's interesting, but if I
>> know that I will never do that, then it's not a convincing argument
>> for me to stop driving it.
>
> How do you know? That is, you can't know you'll *never* drive over
> 120mph. And would you be happy if you knew the public were driving cars
> with such a fatal flaw?
Yeah, not to mention that his comparison is way off.
>
>>> Did you care about ActiveX being disabled in corporate environments
>>> before I pointed out that jQuery would unceremoniously blow up in such
>>> cases
>>
>> No
>>
>>> or were you oblivious like the jQuery developers? Yeah, they
>>> eventually fixed it (after I beat them over the head with it for
>>> _years_)
>>
>> Actually, I politely pointed it out to them and it was fixed the same
>> day. I got results, you didn't.
>
> You have to give them feedback on their terms or else they don't accept
> it? If I matter-of-factly pointed out a bug would they ignore it/me???
Probably. More like they would rubber stamp it with "would you be
willing to file a ticket on that?" They are very bitchy about bug
reports as they seem to see most of them as nit-picking their "robust"
library and tarnishing their "genius" credentials.
>
>>> That's ridiculous. If you can't measure an element's dimensions or read
>>> its attributes with any reasonable reliability, you can't possibly have
>>> a firm DOM scripting foundation.
>>
>> You read like a wikipedia article on logical fallacies.
>
> Still the logic seem robust whereas yours seems lacking.
Lacking is putting it mildly. I'd say virtually non-existent. :)
>
>>> That's also ridiculous. I've had far more impact on your "real world"
>>> than you care to admit. Who is it that keeps getting things fixed in
>>> jQuery (for example?) Sure as hell not you. In fact, you have tried to
>>> parrot my ideas to jQuery from time to time and are usually shouted
>>> down. We've seen it over and over, so why continue to delude yourself?
>>
>> jQuery forum archives surely point to the opposite.
>>
>> You know what would be interesting, DM? If you wrote up a convincing
>> article detailing the reasons why a developer should use My Library
>> instead of jQuery, and the process by which they should do so. You
>> could target it at business web app developers, for example. Be sure
>> to cover all the factors that would matter to such a user of jQuery,
>> not just technical points about attributes and dimensions. That
>> writeup might actually be useful.
>>
>> Do I expect you to actually do anything like that? Umm, no. Of course
>> not.
>
> And if a convincing article were written would you simply ignore it?
If his pattern of behavior holds...
Garrett Smith
> On Feb 23, 6:33 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> What it means for something to work is that that thing fulfills a
>> contract of functioning in the way it has been specified to function.
>
> Very little - if any - software "fulfills a contract of functioning"
> 100% of the time, without problems. I use many pieces of software
> every day that surely have countless unresolved bugs. Yet they still
> provide much value to me. I'd say they "work" as long as those
> problems do not cause a problem for me, despite their existence.
>
Me too.
Internet Explorer, for example, I use for testing.
Internet Explorer a major, popular web browser. It is more popular than
any other browser out there. Internet Explorer works for millions of
other users.
Internet Explorer has a long, troubled history of not fulfilling the
contract to follow web standards. Microsoft has simultaneously stated
that they are committed to supporting standards while showing the
opposite (words and actions don't match).
For example, take "Internet Explorer 6 and Standards"
http://msdn.microsoft.com/en-us/library/bb263979%28VS.85%29.aspx
| Microsoft believes very strongly in Internet standards and the
| standards process, and is committed to implementing appropriate
| standards when driven by customer demand. However, standards
| compliance is part of a larger effort that includes many
| constituencies. By innovating, and driving customer requirements into
| Internet Explorer and then into the standards groups, we'll make the
| Internet a richer platform for all users.
Which goes to great length to communicate to the reader that they are
committed, but they concluding with weasel words about a "larger effort"
(the "big picture" as some might call it).
Is Internet Explorer 6 slow and bugyy? Yes. It was slow and buggy and
did not support many standards and failed to meet the expectations for
many developers (including an angry me) on its date of release. Are
better alternatives available? Provided a definition of "better"
includes mention of things like security, support of standards,
performance, frequency of bug fixes (or time to fix a bug), then yes,
better alternatives exist.
> In that vain, jQuery "works" because it does not cause a problem for
> most users, despite its flaws. It works. Perfectly? No. But it works.
>
The problem is not jQuery, but the actual thing that the customer has
presented. jQuery not causing errors on a page that it is included on is
not very much to ask, and if it failed to do that, then it would be
considered horribly broken (did this happen in 1.3 release?)
Do we have an example of problem applicaiton comparing solutions giving
a solution using jQuery versus one that uses something else?
We have discussions of solution comparisons that here on this NG on a
daily basis, but not one of an entire application or "the big picture".
Sometimes, in those discussion of solutions, jQuery comes up. When that
happens, when was jquery shown to be comparitively good in terms of
speed/efficiency, readability, or reliance on stable abstractions?
If the reasoning is: "I used jQuery" and "it worked", and therefore
"jquery works", then there may be disjunction error between cause and
effect on the part of the person claiming "works".
If the outcome of using jQuery is that "it works", then the outcome of
what jQuery did to enable that outcome needs to be looked at. If the
outcome complies with web standards CSS, HTML, EcmaScript, and a11y
standards like 508 or WCAG and does not violate good OOP and API design
conventions and patterns, and the use of jQuery enabled code that was
cleaner, clearer, and more efficient than otherwise would been possible,
then it could be said to work well.
If, however, the outcome is your typical web 2.0 site, full of errors,
not cross browser, doesn't work with JS disabled, uses `javascript:`
psuedo-protocol, uses tight coupling API strategies and falls apart at
the slightest change requirement, uses browser detection, then "works"
needs a new definition. For example "works" could be defined as: JQuery
works to help the developer get a job and earn some money by producing
average web sites. In that sense, anything that itself does not produce
errors or crashes can be said to work and thing doesn't have to be jQuery.
> The idealistic, unachievable goal of software development is bug-free
> perfection. No piece of software - including jQuery - should be judged
> by that measure. Instead, you have to look at the big picture and many
> factors, of which technical robustness if just one.
>
What other factors and how does each rank in the big picture? Surely you
cannot mean API design. What factors in, as you see it? Ubiquity?
Matt Kruse
> On 24/02/2010 3:35 PM, Matt Kruse wrote:
> > It's similar to you pointing out that my car will blow up if I push it
> > to 120mph on a Sunday during a full moon. That's interesting, but if I
> > know that I will never do that, then it's not a convincing argument
> > for me to stop driving it.
> How do you know? That is, you can't know you'll *never* drive over
> 120mph. And would you be happy if you knew the public were driving cars
> with such a fatal flaw?
The example was used to demonstrate the premise: Just because
something has a flaw in one situation does not invalidate its use in
_all_ situations.
This is to counter David's premise, which apparently is: If a product
has significant flaws in one area, then it should never be used.
Clearly, his logic does not hold true for many other situations or
even software products.
So I agree with his assertion that there are flaws in jQuery. That's
obvious. What I do not agree with is drawing the conclusion that
therefore jQuery should never be used by anyone in any situation. It
does not follow. If he were to apply this reasoning (or lack thereof)
to other software, he would find that he could use no software at all.
Even his own.
> > Actually, I politely pointed it out to them and it was fixed the same
> > day. I got results, you didn't.
> You have to give them feedback on their terms or else they don't accept
> it?
No, you have to approach it in a reasonable way. Which is pretty basic
for dealing with people. This is not David's strong point.
> >> That's ridiculous. If you can't measure an element's dimensions or read
> >> its attributes with any reasonable reliability, you can't possibly have
> >> a firm DOM scripting foundation.
> > You read like a wikipedia article on logical fallacies.
> Still the logic seem robust whereas yours seems lacking.
It seems to me to be so clearly the opposite. David makes observations
and draws unjustified conclusions based on premises that he is
unwilling to equally apply to other situations. That points to clear
bias against jQuery (duh), and weakens his arguments. I'm looking for
reasoned, logical arguments. Not arguments full of obvious logical
fallacies.
> > You know what would be interesting, DM? If you wrote up a convincing
> > article detailing the reasons why a developer should use My Library
> > instead of jQuery, and the process by which they should do so. [...]
> And if a convincing article were written would you simply ignore it?
No. I may disagree with its conclusions, but it would be a fantastic
asset to developers evaluating javascript solutions. It also might
challenge DM to consider more factors than he typically focuses on,
and form a more reasoned and convincing argument than his usual finger-
pointing and whining.
DM starts out with valid observations. Most of them not really unique.
Such as:
1) jQuery is built on an API that is misguided, limiting, and error-
prone
2) jQuery has historically used and defended browser sniffing, and
only recently became aware of better alternatives
3) jQuery does not handle attributes correctly in some situations
4) jQuery is not robust in dealing with width/height calculations
5) jQuery does not enable progressive enhancement, despite its claims
6) jQuery changes its API randomly and frequently, and new versions
are not always backwards-compatible
7) jQuery is not modular, so upgrading to fix a bug in one area while
maintaining the code in another area for backwards-compatibility is
not possible
8) jQuery is unsuited for mobile browsers
9) jQuery has a limited list of supported browsers, with no graceful
degradation
10) jQuery uses a test-driven development approach that leads to
conclusions that "seem to work" instead of robust, researched
algorithms that will "always work".
I'm sure there are others I'm not thinking of right now.
Now, David throws these arguments out there, and with no more
reasoning or explanation, declares jQuery to be junk that should not
be used by anyone in any situation, calls John Resig inept, and
repeatedly insults anyone who uses jQuery or defends its use.
To me, the step from those observations to the conclusion that jQuery
should never be used is not a logical or reasonable step. Those are
purely technical points. They may lead to conclusions like "jQuery
will require X amount of ongoing testing and maintenance if used in an
application" or "jQuery will break in situation Y, which most
applications will find unacceptable."
If he were to take those arguments, and combine them with other
business factors, technical factors, and "people" factors, he may be
able to make a good case for moving from jQuery to My Library or some
other approach. He may be convincing to some people, and may give them
a real reason and strategy for moving away from jQuery. Or for others,
perhaps his conclusions will not be convincing because their factors
are unique or differently weighted.
Perhaps, as I've seen a number of times, only libraries that are on
the vendor's "approved" list may be used in a webapp. jQuery is on
there, My Library is not. Getting My Library on the list is not
practical for the project. Therefore, any arguments for this approach
are simply not applicable, and David's argument is not valid in this
situation. Things like this really happen, and his all-or-nothing
approach simply falls apart in such situations. He has no solution
unless it is ideal. And most of the development world is not working
with an ideal environment.
If nothing else, it would be a reasonable way to promote his position
and help people arrive at their own conclusions that may result in
better products being created, whether with jQuery or not.
Matt Kruse
Scott Sauyet
> 5) jQuery does not enable progressive enhancement, despite its claims
In what way? The other arguments I recognize and give some credence
to, but I've never seen this one.
-- Scott
S.T.
> Is Internet Explorer 6 slow and bugyy? Yes. It was slow and buggy and
> did not support many standards and failed to meet the expectations for
> many developers (including an angry me) on its date of release. Are
> better alternatives available? Provided a definition of "better"
> includes mention of things like security, support of standards,
> performance, frequency of bug fixes (or time to fix a bug), then yes,
> better alternatives exist.
>
I think a better analogy might be MS Word. It has a lot of
functionality, same good -- some not. Ignore the cost of Word and
alternatives for the analogy here.
You can publish a web page with Word and the end result is not so
pleasant. Bloated code and the end result won't even display correctly
in some environments.
You can create full-color newsletters with Word, but it's less than
ideal and there are much better programs to do such tasks. You can do
it, but the end result will be greatest quality. If it's something you
need to do often you might (depending on your circumstances) be
better-served acquiring and learning a different program better suited
to the job.
The overwhelming majority of Word users create documents, mailing
labels, letters, fax cover sheets, form letters, etc. In this capacity
it's an exceptional program. There's a lot of formatting functionality
that is very easily accessible. Integrating a data source for labels,
form letters, etc is trivial for virtually any user. It just works.
There are alternative word processors (analogy: MooTools, YUI, etc),
some of which are also do a good job of same basic Word functionality.
None really do it better, just in a slightly different manner. Word has
a bit of an edge given scores of templates, a hell of a lot of
documentation already floating around and and the occasional feature the
others lack. But the alternatives also have the occasional unique
function and will be the right fit for some.
You could also go grab something like InDesign (analogy: native
Javascript). Its more than a word processor, though it can be used as
one. That'll do a spectacular job creating high end newsletters, but
it's substantially more effort to learn. InDesign can create letters
with a bit more effort than Word and the end result is actually ever so
slightly better. InDesign can also do things like mailing labels and
form letters, and the end result will be just as good as Word's, but
it's really an unholy pain in the ass do these tasks with InDesign.
There's a word processing base that primarily makes letters, labels and
form. It's a pretty large user base actually. For them Word is ideal.
Word lets them make their letters and labels quicker than any
alternative, just as well in 99% of cases. If they need to make a fancy
newsletter they can do an average job with Word relatively fast, or
trudge through InDesign and slowly make a better version. None of these
users have signed an exclusive agreement to use Word.
If they want to publish HTML with their word processor and want a decent
end result they're gonna have to avoid Word entirely. A few will naively
or lazily still use Word for HTML, and the word processing purists will
freak out and use that webpage as evidence why Word should be destroyed.
But in the end, few of this base will ever need to publish HTML so
Word's questionable HTML publishing capabilities are effectively a
non-issue.
Some know how to use both InDesign and Word. They'll use Word for where
it excels to accomplish a task quickly and InDesign if the job calls for
more power or 99% as good won't cut it.
Word is a flawed program. It's improved it's weaknesses quite a bit from
Office 97 to Office 2007, but there's still some flaws and it simply is
not well suited for some tasks (namely, publishing HTML).
Word's continued popularity does not derive from it's weaknesses. It's
popularity stems from where it shines and what it's audience primarily
uses it for. Few of it's users care that it can publish HTML even though
MS is quick to advertise it does so. Some know it doesn't publish HTML
well, so don't know. Very few care either way, as they don't publish
HTML with Word.
Nowadays there's a new word processor claimed by it's author to be the
only viable word processor in existence. It's in an alpha state with no
real documentation. The author claims it's just as good as Word and
alternatives for letters, labels, etc. Its interface will be just as
easy to use as Word and the alternatives (which have been refined over
years) PLUS it'll publish HTML perfectly. The claim is all the features
of InDesign but with the familiarity and ease of the current crop of
word processors.
The author likes to run around to the MS forums, and any other word
processor forums while he's at it, ranting about how great the new word
processor is (will be?). The word processor user base is understandably
skeptical and, in many cases, don't care as they don't use their word
processor to publish HTML or design fancy newsletters. Mostly they're
tired of hearing, literally, years of blather about how they should
scrap Word for an unknown future word processor, or swap to InDesign
instead, to solve the HTML publishing weakness in Word that they're not
experiencing and are unlikely to in the future.
Andrew Poulos
> On 2/23/2010 10:03 PM, Garrett Smith wrote:
>> did not support many standards and failed to meet the expectations for
>> many developers (including an angry me) on its date of release. Are
>> better alternatives available? Provided a definition of "better"
>> includes mention of things like security, support of standards,
>> performance, frequency of bug fixes (or time to fix a bug), then yes,
>> better alternatives exist.
>>
>
> I think a better analogy might be MS Word. It has a lot of
> functionality, same good -- some not. Ignore the cost of Word and
> alternatives for the analogy here.
What about this:
A pharmaceutical product, let's call it "jay" is developed for pregnant
women who suffer "morning sickness".
Jay is well promoted and so is used by many doctors in the treatment of
their patients.
Many patients record excellent results i.e. jay just *works*.
After about a year a research doctor points out a casual link between
jay and tragic birth defects.
The pharmaceutical company lambaste him and his research.
Subsequently other doctors conduct their own research and jay is
eventually withdrawn from sale.
Andrew Poulos
Garrett Smith
> On 25/02/2010 5:58 AM, S.T. wrote:
>> On 2/23/2010 10:03 PM, Garrett Smith wrote:
>>> Is Internet Explorer 6 slow and buggy? Yes. It was slow and buggy and
>>> did not support many standards and failed to meet the expectations for
>>> many developers (including an angry me) on its date of release. Are
>>> better alternatives available? Provided a definition of "better"
>>> includes mention of things like security, support of standards,
>>> performance, frequency of bug fixes (or time to fix a bug), then yes,
>>> better alternatives exist.
>>>
>>
>> I think a better analogy might be MS Word. It has a lot of
>> functionality, same good -- some not. Ignore the cost of Word and
>> alternatives for the analogy here.
>
> What about this:
>
[...]
There are so many bs drugs that get hyped that you didn't have to make
one up.
For example:
"Nolvadex", drug name Tamoxifen Citrate, was developed as a SERM used to
fight estrogen-responsive cancer (breast cancer, in particular). It goes
on the market. Years later, a strong correlation to Nolvadex users and
uterine cancer is discovered.
Does Nolvadex work? Sure, for many doctors, it works great and although
it may be banned in other countries (for the obvious reason that it
*causes* cancer), it is prescribed by doctors in the USA.
In order to assess quality of solutions, real comparisons and
cost-benefit analysis needs to be made. A real cost benefit analysis
includes efficiency of outcome, flexibility of solution, long tern
consequences.
Hand-waving the big picture is not going to cut it; not here.
S.T.
> A pharmaceutical product, let's call it "jay" is developed for pregnant
> women who suffer "morning sickness".
> Jay is well promoted and so is used by many doctors in the treatment of
> their patients.
> Many patients record excellent results i.e. jay just *works*.
> After about a year a research doctor points out a casual link between
> jay and tragic birth defects.
> The pharmaceutical company lambaste him and his research.
> Subsequently other doctors conduct their own research and jay is
> eventually withdrawn from sale.
errrr.... yes Andrew, it is EXACTLY like that. I'd venture that's the
best scripting error to permanent human suffering analogy I've ever seen.
Gotta run and check the jQuery Bug Tracker - suddenly nervous a
miscalculating width() function could cause the user's monitor to
explode and send shards of glass into their eyes. Bad for business.
Matt Kruse
> In order to assess quality of solutions, real comparisons and
> cost-benefit analysis needs to be made. A real cost benefit analysis
> includes efficiency of outcome, flexibility of solution, long tern
> consequences.
Indeed... consider chemotherapy. It is known to have all kinds of
(potentially fatal) side-effects. And yet quite often, it is the best
known choice because the alternative of _not_ doing chemo is even
worse.
Chemo has been shown to be effective and useful. It has been shown to
be very damaging. There are other cancer treatments available that
some claim are better, but chemo is still used.
These analogies just make it obvious to me that:
1) Just because something is imperfect does not mean it's NOT the best
solution or that it SHOULD be avoided.
2) Just because something appears to work doesn't mean it IS the best
solution or that it SHOULDN'T avoided.
3) A real analysis that considers all the factors and weighs them
appropriately is required to come to any meaningful conclusion.
4) Analogies suck.
Matt Kruse
Garrett Smith
> On Feb 24, 4:08 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> In order to assess quality of solutions, real comparisons and
>> cost-benefit analysis needs to be made. A real cost benefit analysis
>> includes efficiency of outcome, flexibility of solution, long tern
>> consequences.
>
>
> 3) A real analysis that considers all the factors and weighs them
> appropriately is required to come to any meaningful conclusion.
>
> 4) Analogies suck.
>
Hey you started it with the generalization comparisons to buggy software
that you use every day.
So you want to get back on topic and discuss application problem
solutions then? OK, I'm following.
David Mark
> On Feb 23, 11:24 pm, Andrew Poulos <ap_p...@hotmail.com> wrote:
>> On 24/02/2010 3:35 PM, Matt Kruse wrote:
>>> It's similar to you pointing out that my car will blow up if I push it
>>> to 120mph on a Sunday during a full moon. That's interesting, but if I
>>> know that I will never do that, then it's not a convincing argument
>>> for me to stop driving it.
>> How do you know? That is, you can't know you'll *never* drive over
>> 120mph. And would you be happy if you knew the public were driving cars
>> with such a fatal flaw?
>
> The example was used to demonstrate the premise: Just because
> something has a flaw in one situation does not invalidate its use in
> _all_ situations.
> This is to counter David's premise, which apparently is: If a product
> has significant flaws in one area, then it should never be used.
>
> Clearly, his logic does not hold true for many other situations or
> even software products.
But we are talking about dubious scripts, not real software.
>
> So I agree with his assertion that there are flaws in jQuery. That's
> obvious. What I do not agree with is drawing the conclusion that
> therefore jQuery should never be used by anyone in any situation.
It sure as hell shouldn't be used on the _Web_ (for reasons that should
be obvious by now).
> It
> does not follow. If he were to apply this reasoning (or lack thereof)
> to other software, he would find that he could use no software at all.
> Even his own.
See above. Dubious scripts are not real software. You can simply
choose not to use scripts that are known to be broken in - for example - IE.
>
>>> Actually, I politely pointed it out to them and it was fixed the same
>>> day. I got results, you didn't.
>> You have to give them feedback on their terms or else they don't accept
>> it?
>
> No, you have to approach it in a reasonable way. Which is pretty basic
> for dealing with people. This is not David's strong point.
You don't know me.
>
>>>> That's ridiculous. If you can't measure an element's dimensions or read
>>>> its attributes with any reasonable reliability, you can't possibly have
>>>> a firm DOM scripting foundation.
>>> You read like a wikipedia article on logical fallacies.
>> Still the logic seem robust whereas yours seems lacking.
>
> It seems to me to be so clearly the opposite. David makes observations
> and draws unjustified conclusions based on premises that he is
> unwilling to equally apply to other situations. That points to clear
> bias against jQuery (duh), and weakens his arguments. I'm looking for
> reasoned, logical arguments. Not arguments full of obvious logical
> fallacies.
Speaking of fallacies, jQuery is hardly the only one I have reviewed and
(justifiably) criticized.
>
>>> You know what would be interesting, DM? If you wrote up a convincing
>>> article detailing the reasons why a developer should use My Library
>>> instead of jQuery, and the process by which they should do so. [...]
>> And if a convincing article were written would you simply ignore it?
>
> No. I may disagree with its conclusions, but it would be a fantastic
> asset to developers evaluating javascript solutions. It also might
> challenge DM to consider more factors than he typically focuses on,
> and form a more reasoned and convincing argument than his usual finger-
> pointing and whining.
You are not one to talk about whining. You pitch a bitch every time I
point out another flaw in jQuery, because you were the one defending it
in here all of these years. I can't help it if what I demonstrate makes
you look clueless. :)
>
> DM starts out with valid observations. Most of them not really unique.
> Such as:
>
> 1) jQuery is built on an API that is misguided, limiting, and error-
> prone
And it is. What's your point.
> 2) jQuery has historically used and defended browser sniffing, and
> only recently became aware of better alternatives
Thanks to who?
> 3) jQuery does not handle attributes correctly in some situations
And that's a fatal flaw for a *query* engine that is supposed to make
the DOM differences less noticeable. How can you not get that?
> 4) jQuery is not robust in dealing with width/height calculations
It's completely brain-dead due to the obvious misconceptions of the
authors. And after that 100+ post thread a month or so back, they still
didn't get it. (!) Some people never will get it and those are not the
sort of people you should delegate browser "smoothing" to.
> 5) jQuery does not enable progressive enhancement, despite its claims
Yeah, duh. It can't possibly do that (and neither can the rest of the
"majors") What a ludicrous design for a browser scripting library that
is supposed to be all about progressive enhancement.
> 6) jQuery changes its API randomly and frequently, and new versions
> are not always backwards-compatible
And that keeps people from "keeping up" with their browser sniffing
changes (case in point: you are still stuck with 1.2x).
> 7) jQuery is not modular, so upgrading to fix a bug in one area while
> maintaining the code in another area for backwards-compatibility is
> not possible
Yes, that's very bad too, particularly for Web developers.
> 8) jQuery is unsuited for mobile browsers
Or desktop browsers.
> 9) jQuery has a limited list of supported browsers, with no graceful
> degradation
Hopefully you have convinced _yourself_ that jQuery is a boondogglem by7
writing all of this down. :)
> 10) jQuery uses a test-driven development approach that leads to
> conclusions that "seem to work" instead of robust, researched
> algorithms that will "always work".
You are just parroting everything I have been saying for years. How can
you say and write it but not get it?
>
> I'm sure there are others I'm not thinking of right now.
Yes, like the basic idea that over the last five years, the browsers
have converged and these miserable query-based libraries have stepped in
to provide a maddeningly inconsistent layer on top of them. They are
the problem now, not the solution. Get it?!
>
> Now, David throws these arguments out there, and with no more
> reasoning or explanation, declares jQuery to be junk that should not
> be used by anyone in any situation, calls John Resig inept, and
> repeatedly insults anyone who uses jQuery or defends its use.
I do not repeatedly insult anybody. You are the one who constantly
changes the subject from ideas for people.
>
> To me, the step from those observations to the conclusion that jQuery
> should never be used is not a logical or reasonable step. Those are
> purely technical points. They may lead to conclusions like "jQuery
> will require X amount of ongoing testing and maintenance if used in an
> application" or "jQuery will break in situation Y, which most
> applications will find unacceptable."
Babbling.
>
> If he were to take those arguments, and combine them with other
> business factors, technical factors, and "people" factors, he may be
> able to make a good case for moving from jQuery to My Library or some
> other approach. He may be convincing to some people, and may give them
> a real reason and strategy for moving away from jQuery. Or for others,
> perhaps his conclusions will not be convincing because their factors
> are unique or differently weighted.
There is more than enough information published at this point for
(thoughtful and intelligent) people to draw the basic conclusion and
stop using a script that makes their life much harder than it needs to
be. Hell, most sites would do just fine without any of the Ajax
bullshit. Unfortunately, most Web developers are more concerned with
looking "cool" among their peers than serving their clients responsibly.
That's the bottom line and I can't change that mindset with reasoned
arguments.
>
> Perhaps, as I've seen a number of times, only libraries that are on
> the vendor's "approved" list may be used in a webapp. jQuery is on
> there, My Library is not.
That's due to two factors, time and ignorance. I only recently started
promoting My Library, remember? It will take time to bore through the
accumulated ignorance. The only reason jQuery is "approved" is because
there are lots of ignorant bloggers and authors out there gushing about it.
> Getting My Library on the list is not
> practical for the project. Therefore, any arguments for this approach
> are simply not applicable, and David's argument is not valid in this
> situation. Things like this really happen, and his all-or-nothing
> approach simply falls apart in such situations. He has no solution
> unless it is ideal. And most of the development world is not working
> with an ideal environment.
You are just babbling again. I have a very good solution. Why don't
you work on getting it "approved" in your shop and stop making
ridiculous statements about my "approach".
>
> If nothing else, it would be a reasonable way to promote his position
> and help people arrive at their own conclusions that may result in
> better products being created, whether with jQuery or not.
>
I don't really care what you consider reasonable or not. All you ever
say is generalized (and often insulting) nonsense.
David Mark
To abstract an unknown environment, you need a dynamic API. Think about
it. How do you know if one of jQuery's wonder-methods will work, fail
silently or blow up? The answer is that you don't until you try, which
is too late.
My Library takes care of all of the ugly DOM feature testing under the
hood and exposes _only_ those methods that can work in the current
environment. That way, all you have to do is use a simple gateway at
the top of your application/enhancement. For example:-
var API;
if (API && API.setOpacity && API.attachMousewheelListener) {
// Your fading, mousewheel-dependent app here
}
Now, what happens if you skip the gateway? For most features, in modern
full-featured browsers, nothing at all (e.g. setOpacity is going to be
there). But in lesser browsers, you may get an immediate exception,
which is roughly what you can expect out of jQuery or the like in such
environments. Of course, the others will be slightly worse as they may
get further into your initialization before doing something ill-advised
and may either fail silently or throw exceptions, depending on the
methods' designs.
It's a no-brainer, but it seems to be taking a while to catch on; over
two years now and the other projects are still churning out static (and
intellectually bankrupt) API's. You can't do that on the Web. ;)
David Mark
Don't you understand how very basic the various jQuery issues are? The
fact that they are still tripping over basic IE6 issues in 2010 should
be enough to make you realize it is folly to continue swapping out their
70K blobs of script. Even when handed the answers on a silver platter,
they manage to fumble them away (usually employing the most hare-brained
logic I've ever seen out of supposed programmers).
Basically it is the world's longest public Beta with no end in sight.
Even worse, they keep "deprecating" browsers that are more than a year
or two old because they can't make any "progress" unless they are
dealing with only three or four agents at a time. That's not
cross-browser scripting. It is a "strategy" that has been dismissed as
folly over a decade ago.
If you can't write basic DOM scripts, perhaps you should eschew DOM
scripting and concentrate on HTML and CSS (which is all most sites
really need anyway). Users only notice the Ajax crap when it carps.
Scott Sauyet
> Scott Sauyet wrote:
>> Matt Kruse wrote:
>>> 5) jQuery does not enable progressive enhancement, despite its claims
>
>> In what way? The other arguments I recognize and give some credence
>> to, but I've never seen this one.
>
> To abstract an unknown environment, you need a dynamic API. Think about
> it. How do you know if one of jQuery's wonder-methods will work, fail
> silently or blow up? The answer is that you don't until you try, which
But this is really just saying again that jQuery (and by extension, a
number of the other popular libraries) has a perhaps myopic focus on a
few versions of recent browsers. If you use it outside that narrow
set, who know what havoc it will wreak? But within its "supported"
browsers, is there any reason to say that it's not capable of
progressive enhancement?
I'm also curious about the dynamic API you present. Obviously that's
one clear way to avoid failing calls to API methods. What are the
advantages over the method that provides a static API that in the
absence of browser support reverts to dummy code that does nothing,
returns empty arrays or false results for any of its calls?
-- Scott
David Mark
> On Feb 24, 6:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Scott Sauyet wrote:
>>> Matt Kruse wrote:
>>>> 5) jQuery does not enable progressive enhancement, despite its claims
>>> In what way? The other arguments I recognize and give some credence
>>> to, but I've never seen this one.
>> To abstract an unknown environment, you need a dynamic API. Think about
>> it. How do you know if one of jQuery's wonder-methods will work, fail
>> silently or blow up? The answer is that you don't until you try, which
>> is too late. [ ... [
>
> But this is really just saying again that jQuery (and by extension, a
> number of the other popular libraries) has a perhaps myopic focus on a
> few versions of recent browsers.
Perhaps? That's all they can hope to handle and they more or less admit
it. But that's nothing to shrug off. Just because some clueless
library developers decide they "don't care" about browsers that came out
last year (and this year's browsers will be dismissed next year, of
course), because they really don't know what they are doing with
cross-browser scripting, doesn't mean the public won't get pissed off
when your site breaks in unexpected ways. By and large, they don't know
John Resig and don't care what he thinks about their browsers. ;)
> If you use it outside that narrow
> set, who know what havoc it will wreak?
Exactly. And it is a very _narrow_ set. They can't even handle IE8 in
its default configuration (let alone compatibility mode).
> But within its "supported"
> browsers, is there any reason to say that it's not capable of
> progressive enhancement?
Yes, because they really don't know what they support. They only
recently figured out they needed a try-catch around XHR creation.
Previously it would blow up in certain IE configurations. So for years
they were churning out versions that would fail in many corporate
environments, but were blissfully unaware of the issue.
There are plenty mode. Recently I pointed out that - removeAttr - when
used to remove a COL/ROWSPAN attribute would blow up in _some_ of their
"supported" browsers. Who knows if they tested in just a subset or they
consider that to be an "edge attribute" Who knows? There's sure as
hell nothing in the docs about it. :)
And for years, they ignorantly claimed that their script would work with
XHTML (it won't) and IE quirks mode (not a shot there either). And then
there are queries on XML documents (e.g. XHR results). You guessed it.
They made up stories out of thin air for years and then when it was
pointed out that they were fairy tales, they "punted" (in their forum,
not on the blog or in the docs). You can't trust them, period.
>
> I'm also curious about the dynamic API you present. Obviously that's
> one clear way to avoid failing calls to API methods. What are the
> advantages over the method that provides a static API that in the
> absence of browser support reverts to dummy code that does nothing,
> returns empty arrays or false results for any of its calls?
>
Think about it. How would that work at all? I suppose if it were a
Hello World app... :)
In other words, what would the user see? Some features fail silently,
some blow up, some work, etc. That's no good. :(
toby.o...@gmail.com
Usinging such a static API can keep code from blowing up but it can
also obscure API misuse and cause other problems.
IMO, The key feature of a dynamic API is fine-grained progressive
enhancement, without a need to check the underlying feature support
(e.g. jQuery.support.opacity) required by the API calls used. For
example:
function showEffect(el) {
if (API.effectOne && API.effectTwo && API.effectThree) {
// Super cool effect, supported by few browsers.
} else if (API.effectOne && API.effectFour) {
// Not as cool effect, supported by other browsers.
} else if (API.showEl){
// Barebones effect.
} else {
// Do nothing.
}
}
(Depending on the context in which this function is called, one might
remove the 'else' condition and dynamically add this function itself
by wrapping it in an appropriate if statement.)
With a typical static API, it would be difficult or impossible to use
fine-grained progressive enhancement because the first condition in
the function above would execute with varying results.
A library could provide a static API and provide a separate mechanism
for determining browser support of each function, but I don't know
that that would be advantageous in any way aside from allowing lazily-
written, terser code.
David Mark
> On Feb 25, 7:24 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> On Feb 24, 6:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> I'm also curious about the dynamic API you present. Obviously that's
>> one clear way to avoid failing calls to API methods. What are the
>> advantages over the method that provides a static API that in the
>> absence of browser support reverts to dummy code that does nothing,
>> returns empty arrays or false results for any of its calls?
>
> Usinging such a static API can keep code from blowing up but it can
> also obscure API misuse and cause other problems.
Right. Typically you need to know which functions will work long before
you actually call them.
>
> IMO, The key feature of a dynamic API is fine-grained progressive
> enhancement, without a need to check the underlying feature support
> (e.g. jQuery.support.opacity) required by the API calls used. For
> example:
>
> function showEffect(el) {
> if (API.effectOne && API.effectTwo && API.effectThree) {
> // Super cool effect, supported by few browsers.
> } else if (API.effectOne && API.effectFour) {
> // Not as cool effect, supported by other browsers.
> } else if (API.showEl){
> // Barebones effect.
> } else {
> // Do nothing.
> }
> }
Yes, I prefer one-off's, but that's the basic idea. Who needs
extraneous flags, which may get out of sync without constant vigilance
by the developers (something jQuery is not noted for).
>
> (Depending on the context in which this function is called, one might
> remove the 'else' condition and dynamically add this function itself
> by wrapping it in an appropriate if statement.)
Yes, I didn't quite follow the "do nothing" bit. I prefer not to create
such false fronts as they fool the calling app into thinking there is
something usable there (of course, depending on context, that may not
matter).
>
> With a typical static API, it would be difficult or impossible to use
> fine-grained progressive enhancement because the first condition in
> the function above would execute with varying results.
Yes, you would have no way to know whether it is a win, lose or draw
until it is too late.
>
> A library could provide a static API and provide a separate mechanism
> for determining browser support of each function, but I don't know
> that that would be advantageous in any way aside from allowing lazily-
> written, terser code.
The separate mechanism would get out of sync in short order. Why use
two variables where one will do? And I don't know that it will allow
for more terse code either. One way or the other, apps have to do some
detection up front (which precludes dummy functions that obscure the
needed details) and checking flags or the methods themselves seems to
require the same amount of verbosity.
Of course, most developers just assume everything works and in the three
browsers/configurations they test, it appears to be a good assumption,
so why bother with all of this "complicated" detection? They may not
know programming, but they know what they like! ;)
Peter Michaux
> On Feb 23, 2:32 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > That's crazy. Virtually everyone carries a mobile browser these days
>
> Where is your evidence? I would guess that the number of people who
> access the web via mobile device is in the single-digit percentages.
I don't think that "virtually everyone carries a mobile browser these
days." I don't think that is even close to true.
That said, if mobile devices are a single-digit percentage then that
group can't be thrown out as unworthy. There are quite a few browser
niches that are single-digit percentages and if you add them up and
throw them out you are throwing out a significant percentage.
> > Mobile browsers are important right now (and have been for years).
>
> They are somewhat important, to some people. Certainly not a priority
> for most. Yet.
I agree that mobile may not be essential for everyone yet but now that
I have a cell phone it sure is nice when sites do work.
Peter
David Mark
> On Feb 23, 2:38 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>> On Feb 23, 2:32 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>>> That's crazy. Virtually everyone carries a mobile browser these days
>> Where is your evidence? I would guess that the number of people who
>> access the web via mobile device is in the single-digit percentages.
>
> I don't think that "virtually everyone carries a mobile browser these
> days." I don't think that is even close to true.
Even the poorest of the poor have phones. Even the lamest phones have
browsers, therefore...
>
> That said, if mobile devices are a single-digit percentage then that
> group can't be thrown out as unworthy. There are quite a few browser
> niches that are single-digit percentages and if you add them up and
> throw them out you are throwing out a significant percentage.
Right.
>
>
>>> Mobile browsers are important right now (and have been for years).
>> They are somewhat important, to some people. Certainly not a priority
>> for most. Yet.
>
> I agree that mobile may not be essential for everyone yet but now that
> I have a cell phone it sure is nice when sites do work.
>
Yes, and aggravating when they don't and you can see that it was
strictly due to The Crazies and their arbitrary "decision" making process.
Peter Michaux
> Peter Michaux wrote:
> > I agree that mobile may not be essential for everyone yet but now that
> > I have a cell phone it sure is nice when sites do work.
>
> Yes, and aggravating when they don't and you can see that it was
> strictly due to The Crazies and their arbitrary "decision" making process.
Some web applications benefit greatly from drag-and-drop
functionality. They benefit so greatly and the non-drag-and-drop
version is so bad that the non-drag-and-drop version is never built.
There are some some web applications that you could say *require*
drag-and-drop: games, drawing programs. There is no financial
incentive to building the non-drag-and-drop version. Drag-and-drop in
a web page doesn't seem to work on my iPhone. So it isn't that the
decision makers of the web page were "The Crazies". It is actually the
phone and/or the phone's browser that is not up to the task.
Peter
David Mark
> On Feb 25, 9:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Peter Michaux wrote:
>
>>> I agree that mobile may not be essential for everyone yet but now that
>>> I have a cell phone it sure is nice when sites do work.
>> Yes, and aggravating when they don't and you can see that it was
>> strictly due to The Crazies and their arbitrary "decision" making process.
>
> Some web applications benefit greatly from drag-and-drop
> functionality.
I suppose. But it is rare that DnD would be anything more than a
novelty enhancement for a Website.
> They benefit so greatly and the non-drag-and-drop
> version is so bad that the non-drag-and-drop version is never built.
Okay. That's not a Website then. So the Website that links to it
should use a script-generated link, perhaps even detecting certain
features as well. Problem solved. :)
Scott Sauyet
> Scott Sauyet wrote:
>
>> I'm also curious about the dynamic API you present. Obviously that's
>> one clear way to avoid failing calls to API methods. What are the
>> advantages over the method that provides a static API that in the
>> absence of browser support reverts to dummy code that does nothing,
>> returns empty arrays or false results for any of its calls?
>
> Usinging such a static API can keep code from blowing up but it can
> also obscure API misuse and cause other problems.
It can, and it's also more flexible. But it is less convenient, and
that really is a consideration.
For instance, this is certainly fine for me:
API.roundCorners(myDiv);
And this is overkill:
if (API.roundCorners) {
API.roundCorners(myDiv);
}
Because rounded corners are merely a nice touch, and not something I
care to make a big deal about in my code.
And while there are times I might appreciate this flexibility:
if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none';
}
It's also pretty nice to be able to do this:
API.myCoolFade(myDiv)
and know that the library is internally checking API.canSetOpacity and
whatever other flags it needs, then defaulting to its own
"style.display = 'none'" branch if the effects are not available.
I know that such a technique is less flexible. For instance, I
couldn't choose to do this:
if (API.myCoolFade) {
API.myCoolFade(myDiv);
} else {
var warning = document.createElement("H3");
myDiv.insertBefore(warning, myDiv.firstChild);
for (var i = 0; i < 5; i++) {
setTimeout((function(seconds) {
return function() {
warning.innerHTML = "This div will " +
"self-destruct in " + seconds +
" seconds!";
};
})(5 - i), 1000 * i);
}
setTimeout(function() {
myDiv.style.display = 'none';
}, 5000);
}
but I'm often willing to sacrifice such flexibility for the simplicity
of the static API.
> [ ... ]
> A library could provide a static API and provide a separate mechanism
> for determining browser support of each function, but I don't know
> that that would be advantageous in any way aside from allowing lazily-
> written, terser code.
Of course that last phrase can also be written "simpler, clearer
code". :-)
One technique I've used on several occasions in my own mini-library
code is to add "supported" properties to API functions, which return
values "complete", "degrade", "empty", or false, depending upon
whether the function is completely supported, degrades acceptably,
returns empty objects or arrays, or is totally unsupported, with code
something like this:
API.myCoolFade = API._support((function() {
if (API.opacitySupported) return "complete";
return "degrade";
)(), function(elt) {
if (API.opacitySupported) {
// cool opacity animation here.
} else {
if (elt) elt.style.display = 'none';
}
});
The _support function simply adds the 'supported' property to the
function supplied as the second parameter, with the value supplied in
the first parameter, and returns this enhanced function.
It can then be used simply, if I don't care:
API.roundCorner(myDiv);
Or I can test if I like:
if (API.myCoolFade.supported) {
API.myCoolFade(myDiv);
} else {
myDiv.style.display = 'none'
}
Or if I really want my own alternate degrading technique, I can check
the value of supported:
if (API.myCoolFade.supported == "complete") {
API.myCoolFade(myDiv);
} else if (API.myCoolFade.supported == "degrade") {
// My hand-rolled alternate hide technique here.
} else {
myDiv.style.display = 'none'
}
It has worked for me, but I haven't had to use it much, because it's
never been for large public APIs. It was exactly this sort of pseudo-
fade that motivated it, though, and it worked well enough there. For
API methods that returned arrays of nodes, usually there is complete
support across browsers, but when there isn't, the "supported"
property tells me that the function will at least return me an array I
could continue to process, even if it's empty, which often simplified
further coding.
In any case, I've never tried to code in the dynamic API style for
library code. Are there good examples of libraries that do it? I
understand My Library does; are there other publicly available
examples?
-- Scott
David Mark
> toby.o...@gmail.com wrote:
>> Scott Sauyet wrote:
>>
>>> I'm also curious about the dynamic API you present. Obviously that's
>>> one clear way to avoid failing calls to API methods. What are the
>>> advantages over the method that provides a static API that in the
>>> absence of browser support reverts to dummy code that does nothing,
>>> returns empty arrays or false results for any of its calls?
>> Usinging such a static API can keep code from blowing up but it can
>> also obscure API misuse and cause other problems.
>
> It can, and it's also more flexible. But it is less convenient, and
> that really is a consideration.
>
> For instance, this is certainly fine for me:
>
> API.roundCorners(myDiv);
>
> And this is overkill:
>
> if (API.roundCorners) {
> API.roundCorners(myDiv);
> }
No, you do _not_ do it that way. You do a one-time check at the start
for required methods.
>
> Because rounded corners are merely a nice touch, and not something I
> care to make a big deal about in my code.
>
> And while there are times I might appreciate this flexibility:
>
> if (API.myCoolFade) {
> API.myCoolFade(myDiv);
> } else {
> myDiv.style.display = 'none';
> }
>
> It's also pretty nice to be able to do this:
>
> API.myCoolFade(myDiv)
Not at all nice when it blows up or fails silently. ;)
>
> and know that the library is internally checking API.canSetOpacity and
> whatever other flags it needs, then defaulting to its own
> "style.display = 'none'" branch if the effects are not available.
Too much bloat and inefficiency in the internal code.
>
> I know that such a technique is less flexible. For instance, I
> couldn't choose to do this:
>
> if (API.myCoolFade) {
> API.myCoolFade(myDiv);
> } else {
> var warning = document.createElement("H3");
> myDiv.insertBefore(warning, myDiv.firstChild);
> for (var i = 0; i < 5; i++) {
> setTimeout((function(seconds) {
> return function() {
> warning.innerHTML = "This div will " +
> "self-destruct in " + seconds +
> " seconds!";
> };
> })(5 - i), 1000 * i);
> }
> setTimeout(function() {
> myDiv.style.display = 'none';
> }, 5000);
> }
>
> but I'm often willing to sacrifice such flexibility for the simplicity
> of the static API.
But a static API can't abstract a an unknown environment in any sort of
efficient and flexible manner.
>
>> [ ... ]
>> A library could provide a static API and provide a separate mechanism
>> for determining browser support of each function, but I don't know
>> that that would be advantageous in any way aside from allowing lazily-
>> written, terser code.
>
> Of course that last phrase can also be written "simpler, clearer
> code". :-)
>
> One technique I've used on several occasions in my own mini-library
> code is to add "supported" properties to API functions, which return
> values "complete", "degrade", "empty", or false, depending upon
> whether the function is completely supported, degrades acceptably,
> returns empty objects or arrays, or is totally unsupported, with code
> something like this:
Okay, but I don't see why you would need more than a boolean (e.g. works
or not).
>
> API.myCoolFade = API._support((function() {
> if (API.opacitySupported) return "complete";
> return "degrade";
> )(), function(elt) {
> if (API.opacitySupported) {
> // cool opacity animation here.
> } else {
> if (elt) elt.style.display = 'none';
> }
> });
See what I mean about bloat? Imagine an API with thousands of methods
doing something like this for each one. It wouldn't be feasible on the Web.
>
> The _support function simply adds the 'supported' property to the
> function supplied as the second parameter, with the value supplied in
> the first parameter, and returns this enhanced function.
>
> It can then be used simply, if I don't care:
>
> API.roundCorner(myDiv);
>
> Or I can test if I like:
>
> if (API.myCoolFade.supported) {
> API.myCoolFade(myDiv);
> } else {
> myDiv.style.display = 'none'
> }
>
> Or if I really want my own alternate degrading technique, I can check
> the value of supported:
>
> if (API.myCoolFade.supported == "complete") {
> API.myCoolFade(myDiv);
> } else if (API.myCoolFade.supported == "degrade") {
> // My hand-rolled alternate hide technique here.
> } else {
> myDiv.style.display = 'none'
> }
But this is not efficient. A one-off gateway at the start is all you
need. Checking these things each time will bog down your app.
>
> It has worked for me, but I haven't had to use it much, because it's
> never been for large public APIs. It was exactly this sort of pseudo-
> fade that motivated it, though, and it worked well enough there. For
> API methods that returned arrays of nodes, usually there is complete
> support across browsers, but when there isn't, the "supported"
> property tells me that the function will at least return me an array I
> could continue to process, even if it's empty, which often simplified
> further coding.
Yes, for a small Intranet app, you could certainly get by with the above
(depending on its performance requirements of course).
>
> In any case, I've never tried to code in the dynamic API style for
> library code. Are there good examples of libraries that do it? I
> understand My Library does; are there other publicly available
> examples?
>
Not that I know of. :)
Garrett Smith
> On Feb 25, 9:31 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Peter Michaux wrote:
>
> Some web applications benefit greatly from drag-and-drop
> functionality. They benefit so greatly and the non-drag-and-drop
> version is so bad that the non-drag-and-drop version is never built.
> There are some some web applications that you could say *require*
> drag-and-drop: games, drawing programs. There is no financial
> incentive to building the non-drag-and-drop version. Drag-and-drop in
> a web page doesn't seem to work on my iPhone. So it isn't that the
> decision makers of the web page were "The Crazies". It is actually the
> phone and/or the phone's browser that is not up to the task.
>
Drag'n'drop in iPhone requires a lot of extra effort. Yes the makers of
the iPhone were not up to much tasks other than marketing.
Try changing an iPhone's battery, for example.
Peter Michaux
> Drag'n'drop in iPhone requires a lot of extra effort.
How would drag and drop even work in iPhone's Safari browser? It seems
that gestures are already so heavily used there aren't many gestures
available for drag and drop functionality.
> Yes the makers of
> the iPhone were not up to much tasks other than marketing.
That statement doesn't mean much.
> Try changing an iPhone's battery, for example.
I can see Apple's argument that a user-changable battery requires more
casing/size and so is not desirable. I should, however, be able to
stop at a local Apple store and have the battery changed in a couple
minutes.
Peter
David Mark
> On Feb 27, 12:15 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
>> Drag'n'drop in iPhone requires a lot of extra effort.
>
> How would drag and drop even work in iPhone's Safari browser? It seems
> that gestures are already so heavily used there aren't many gestures
> available for drag and drop functionality.
Ham-fisted. If you can't detect mousemove, bail on DnD. Simple as
that. Trying to bastardize gestures to to DnD is er Crazy. :)
Garrett Smith
> On Feb 27, 12:15 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
>> Drag'n'drop in iPhone requires a lot of extra effort.
>
> How would drag and drop even work in iPhone's Safari browser? It seems
> that gestures are already so heavily used there aren't many gestures
> available for drag and drop functionality.
>
Touch-move-scrolls-the-viewport interferes touch move actions being
mapped to mousemove. So how do you make drag'n'drop work on iPhone?
To address this situation, Apple created a Touch Events API.
To use the Touch Events API for your typical drag'n'drop application,
register touch events "touchstart", "touchmove", and "touchend".
The the data need for the drag and drop event (pageX, etc) is not on the
event arg. Instead, it is found on from a Touch object on a TouchList
object. The TouchList object is found by eventArg.touches and the Touch
object is eventArg.touches[i].
In the touchmove event handler, call preventDefault to stop the browser
from scrolling the document around.
To unit test, Apple created the 18 parameter variable method
createTouchEvent.
Three of the 18 parameter variables to createTouchEvent are TouchList
objects. A TouchList object is created using document.createTouchList
and requires at least one Touch object.
A Touch object is created using document.createTouch.
I dislike the existence of proprietary APIs. This particular API is
significantly painful to use and test, so even if it were a standard
proposal, it has significant problems. The 18 parameter variables are
nearly impossible to remember and are irrelevant for most applications.
You'll also notice that scrolling works differently on iPhone. CSS
overflow auto and scroll values do not work.
I hold copyright to my counterproposal, which has been published on this
NG.
Most of the time the program can just allow single touch drag/drop, and
anything else might be just discarded. The "anything else" would be
user's palm touching the screen, or an attempt to do multi-finger drags.
If you'd like to see an example of some code, I can post a link.
>
>> Yes the makers of
>> the iPhone were not up to much tasks other than marketing.
>
> That statement doesn't mean much.
>
I guess I used the wrong word "maker" there.
The people who are actually *making* the iPhone (Chinese workers)
probably could not use there entire year salary to purchase one.
>
>> Try changing an iPhone's battery, for example.
>
> I can see Apple's argument that a user-changable battery requires more
> casing/size and so is not desirable. I should, however, be able to
> stop at a local Apple store and have the battery changed in a couple
> minutes.
>
Is that what Apple argued? I've got to see that. Where is it?
Garrett Smith
> Peter Michaux wrote:
>> On Feb 27, 12:15 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>
[...]
> The people who are actually *making* the iPhone (Chinese workers)
> probably could not use there entire year salary to purchase one.
>
s/there/their
Peter Michaux
I don't have a link but when the non-changable battery was first used
in the MacBook Pro the argument was that by saving the casing on the
battery and the housing where the battery mounts, they could instead
make the battery bigger for the same/similar weight and size.
Peter
Jorge
> (...)
> I hold copyright to my counterproposal, which has been published on this
Jeez, what a douchebag.
> Try changing an iPhone's battery, for example.
http://www.apple.com/support/iphone/service/battery/
--
Jorge.
David Mark
> On Feb 27, 11:52 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> (...)
>> I hold copyright to my counterproposal, which has been published on this
>> NG. (...)
>
> Jeez, what a douchebag.
>
LOL. Internet tough-guy, huh? Not to mention freeloader. Perhaps you
think intellectual property is an antiquated notion? I know that other
have-nots share that view and it is obvious why that is the case. You
just can't have everything handed to you for free, Internet or no Internet.
Get better Jorge!
Garrett Smith
the topic of "Touch and Gesture Events" Kari Hitola posted some wrong
information. He made statements that were false or incorrect. The
statements that were /provably/ false I provided one test case and a
link (to correct information). For other statements, IIRC, I questioned
him, but then got a notice that my "posting privilege had been suspended
for two weeks." All of my posts have been blocked since then. I have
tried to post even this month, IIRC. I can post to neither
public-script-coord, nor www-dom, nor public-webapps. I can still post
to www-style. I can't figure the rationale for picking those three
lists, so I can only assume it was blind anger and stupidity and they
overlooked www-style.
I stand by what I wrote and do not apologize for it. To the best of my
ability, I will continue question what I believe to be a misguided API
design.
The reason for Kari Hitola's posting, AISI, was to justify Nokia's copy
of Apple's API, post hoc.
If the w3c wants to block out my ideas from their lists, that's their
loss. I believe my idea is good and simple.
Those same W3C individuals might like the idea if they wrote it
themselves. They may do just that, but the idea is so simple that they
will probably expand on it and make it larger and more complicated.
David Mark
Yes, I *hate* officious moderators. Near as I can tell, as soon as more
than one person cries for a ban, they do it. It's idiotic behavior as
they are really supposed to be manual Spam filters (and nothing more).
I can only imagine what these weenies are like in real life.
Dojo just installed a moderator on their new jQuery-powered forum,
apparently because they felt I was tarnishing their "sterling" legacy by
pointing out gaping holes in their foundation (that I had pointed out
months earlier, apparently to no avail or even understanding). Granted,
one idiot kept posting the same bad joke after each one like some sort
of bot, but I don't think that's what triggered the moderation. Now
there are some losers for you. Can't rebut anything logically, don't
understand how to fix anything (and therefore are constantly fucking up
royally), so they cry for bans and/or moderation (happened on their last
mailing list too) rather trying to understand what all (or any) of the
criticism is actually about.
And the most ironic, inexplicable bit is that I was originally _asked_
to pound some sense into them (and their code) by the project _owners_.
It's really beyond bizarre. At one point, one of those owners started
chiming in with some of the bitchiest, most ignorant bullshit I have
ever heard (and as you can imagine, that's up against some pretty stiff
competition).
I suppose there is a book chapter in it, but nobody would believe such a
far-fetched scenario and, at this point, I don't think there's enough
interest in that project to justify it anyway. I think they've finally
burned their last bridge to competence (and the relevance that could
come with it), because I have absolutely had it with them. I keep
trying to lead them to water and they keep opting for the spiked
Kool-aid instead (and shrieking up a storm in the process). :(
For instance, the one-liner "global" eval method is obviously broken and
no matter how many times I tell them how to fix it, it remains as is. I
suspect it is because nobody in the project is confident enough to
change anything in the core (in their mind it "just works", so the best
bet is to leave it alone). Then there are the synchronous Ajax
requests, the miles of browser sniffs, CSS parse hacks, and the classic
"overloading", even using typeof xyz == 'array' (though I think they did
_finally_ change that last one). And as there are about a thousand
files involved (quantity over quality of course), the snail's pace of
the epiphanies dawning is fatal to the effort. Like I have time to
repeat the same points to them a hundred times (getting splitting
headaches from the shrill bleating that seems to accompany each for my
trouble). There's too much to fix, too little time and too many
neophytes trying to prop themselves up as experts to make any real headway.
>
> I stand by what I wrote and do not apologize for it. To the best of my
> ability, I will continue question what I believe to be a misguided API
> design.
>
> The reason for Kari Hitola's posting, AISI, was to justify Nokia's copy
> of Apple's API, post hoc.
>
> If the w3c wants to block out my ideas from their lists, that's their
> loss. I believe my idea is good and simple.
>
> Those same W3C individuals might like the idea if they wrote it
> themselves.
Yes, that keeps happening with the Dojo contributors too. I handed them
most of the answers on a silver platter, but they are full of excuses as
to why they would rather stick with what they have (or, as in the case
of the loader, they run off to write their own botched imitation). I
suppose I could understand if they were experiencing some modicum of
success, but I keep seeing complaints about the same old issues (often
things I fixed in my branch last summer). And just who is using their
stuff on the Web anyway? It's like they are developing with blinders
on. They want to shield themselves from criticism so they can "get back
to having fun again." What a fucking waste. :(
Also, I just noticed, their moderation mechanism must be broken as I
keep getting messages that my last post is "pending", yet it is clearly
there for all to see. Good thing too as it has some very useful
information in it (and isn't critical of Dojo specifically). But I've
informed the higher-ups that it will be my last post there as I won't
submit input to have it sit around waiting for some beetle-browed nitwit
to dismiss as "not fun." I mean, who are they to judge the merits of
points that they clearly don't understand?
As an aside, the aforementioned jQuery-ified forum loads _forever_ in
Opera 10, with the stop/reload button flashing like a strobe light
(epileptic or easily annoyed Opera users should steer clear). FF
politely says it is loading forever in the status bar. And I see random
server side exception vomiting from time to time as well. They can't
seem to do _anything_ right, but somehow they see it all as par for the
course, just gettin' stuff done, etc. and anyone who points out their
follies is a jerk for embarrassing them. I guess if you are never
successful, you can't recognize even the most obvious signs of failure. :(
Peter Michaux
> Dojo just installed a moderator on their new jQuery-powered forum,
What?!
Peter
David Mark
well. Yeah, I know. Their Web developers just like gettin' stuff done,
even when it is obviously destroying whatever shred of credibility they
have left. I can't explain it. I'm tired of thinking about as it gives
me headaches. :(
Scott Sauyet
> Scott Sauyet wrote:
>> For instance, this is certainly fine for me:
>> API.roundCorners(myDiv);
>>
>> And this is overkill:
>>
>> if (API.roundCorners) {
>> API.roundCorners(myDiv);
>> }
>
> No, you do _not_ do it that way. You do a one-time check at the start
> for required methods.
Do you centralize all code that might need rounded corners, then? If
so, how do you deal with dynamic changes to the DOM? Or do you store
a variable with the result of API,roundCorners? If it's that, how
much savings do you really get?
>> And while there are times I might appreciate this flexibility:
>>
>> if (API.myCoolFade) {
>> API.myCoolFade(myDiv);
>> } else {
>> myDiv.style.display = 'none';
>> }
>
>> It's also pretty nice to be able to do this:
>>
>> API.myCoolFade(myDiv)
>
> Not at all nice when it blows up or fails silently. ;)
Of course, but my whole post was about ways to make a static API
available that doesn't blow up or fail silently even in the absence of
features we would like.
>> and know that the library is internally checking API.canSetOpacity and
>> whatever other flags it needs, then defaulting to its own
>> "style.display = 'none'" branch if the effects are not available.
>
> Too much bloat and inefficiency in the internal code.
Unless I actually can note performance issues, I'm much more concerned
with clean APIs that are as easy to use as possible than I am about
bloat in the library code.
But if performance is a concern, this can be done efficiently. It can
still be an up-front check:
API.myCoolFade = (API.opacitySupported)
? function(elt) {
// cool opacity animation here.
}
: function(elt) {
if (elt) elt.style.display = 'none';
}
>> I know that such a technique is less flexible. For instance, I
>> couldn't choose to do this:
>> <snip>
>> but I'm often willing to sacrifice such flexibility for the simplicity
>> of the static API.
>
> But a static API can't abstract a an unknown environment in any sort of
> efficient and flexible manner.
I certainly agree that a dynamic API can be more flexible; that's
practically tautological. I'm not sure I agree about the efficiency
question. To me the main question is whether the behavior of the
static API can degrade in a reasonable manner in environment that
don't support its full functionality.
>> One technique I've used on several occasions in my own mini-library
>> code is to add "supported" properties to API functions, which return
>> values "complete", "degrade", "empty", or false, depending upon
>> whether the function is completely supported, degrades acceptably,
>> returns empty objects or arrays, or is totally unsupported, with code
>> something like this:
>
> Okay, but I don't see why you would need more than a boolean (e.g. works
> or not).
I've done that.too. It works fine. The trouble is then if there is a
simpler supported version of the functionality with fewer bells and
whistles that I can fall back on. It's nice to have the super-cool
fade fall back on a simple hide in the absence of the necessary
environmental features. Then I simply don't have to think about it
usually.
>> API.myCoolFade = API._support((function() {
>> if (API.opacitySupported) return "complete";
>> return "degrade";
>> )(), function(elt) {
>> if (API.opacitySupported) {
>> // cool opacity animation here.
>> } else {
>> if (elt) elt.style.display = 'none';
>> }
>> });
>
> See what I mean about bloat? Imagine an API with thousands of methods
> doing something like this for each one. It wouldn't be feasible on the Web.
Well an API with thousands of methods would scare me much more than
this code. Even jQuery's large API has fewer than 250 methods in it.
>> It has worked for me, but I haven't had to use it much, because it's
>> never been for large public APIs. It was exactly this sort of pseudo-
>> fade that motivated it, though, and it worked well enough there. For
>> API methods that returned arrays of nodes, usually there is complete
>> support across browsers, but when there isn't, the "supported"
>> property tells me that the function will at least return me an array I
>> could continue to process, even if it's empty, which often simplified
>> further coding.
>
> Yes, for a small Intranet app, you could certainly get by with the above
> (depending on its performance requirements of course).
Why don't you think this would scale to the multiple environments of
the Internet?
>> In any case, I've never tried to code in the dynamic API style for
>> library code. Are there good examples of libraries that do it? I
>> understand My Library does; are there other publicly available
>> examples?
>
> Not that I know of. :)
So it looks like you have some selling to do! :-)
-- Scott
David Mark
> David Mark wrote:
>> Scott Sauyet wrote:
>>> For instance, this is certainly fine for me:
> ?>
>>> API.roundCorners(myDiv);
>>>
>>> And this is overkill:
>>>
>>> if (API.roundCorners) {
>>> API.roundCorners(myDiv);
>>> }
>> No, you do _not_ do it that way. You do a one-time check at the start
>> for required methods.
>
> Do you centralize all code that might need rounded corners, then?
I don't think this is a good example feature as it is hard to imagine
code that hinges on rounded-corners. But yes, depending on the
complexity of the applications, you may need to break it up into
sections and use a different gateway for each section.
> If
> so, how do you deal with dynamic changes to the DOM? Or do you store
> a variable with the result of API,roundCorners? If it's that, how
> much savings do you really get?
I don't follow. The gateways prevent entry to sections that would rely
on that feature.
>
>
>>> And while there are times I might appreciate this flexibility:
>>>
>>> if (API.myCoolFade) {
>>> API.myCoolFade(myDiv);
>>> } else {
>>> myDiv.style.display = 'none';
>>> }
>>> It's also pretty nice to be able to do this:
>>>
>>> API.myCoolFade(myDiv)
>> Not at all nice when it blows up or fails silently. ;)
>
> Of course, but my whole post was about ways to make a static API
> available that doesn't blow up or fail silently even in the absence of
> features we would like.
Well, you can't really abstract a random environment with a static API
unless you are willing to allow some functions to fail silently (which
can work in some cases).
>
>
>>> and know that the library is internally checking API.canSetOpacity and
>>> whatever other flags it needs, then defaulting to its own
>>> "style.display = 'none'" branch if the effects are not available.
>> Too much bloat and inefficiency in the internal code.
>
> Unless I actually can note performance issues, I'm much more concerned
> with clean APIs that are as easy to use as possible than I am about
> bloat in the library code.
You can't get much cleaner than the method I describe. If the feature
is there, it is expected to work (and vice-versa), so all you have to do
is write an appropriate gateway (or gateways) for your app. As for the
API itself, the described technique lends itself well to one-off method
function creation, which leads to a clean and efficient set of methods.
>
> But if performance is a concern, this can be done efficiently. It can
> still be an up-front check:
>
> API.myCoolFade = (API.opacitySupported)
> ? function(elt) {
> // cool opacity animation here.
> }
> : function(elt) {
> if (elt) elt.style.display = 'none';
> }
But now you have an extraneous flag for each dynamically created
function. Why not just use the functions themselves as the flags? Then
there is nothing to get out of sync.
>
>
>>> I know that such a technique is less flexible. For instance, I
>>> couldn't choose to do this:
>>> <snip>
>>> but I'm often willing to sacrifice such flexibility for the simplicity
>>> of the static API.
>> But a static API can't abstract a an unknown environment in any sort of
>> efficient and flexible manner.
>
> I certainly agree that a dynamic API can be more flexible; that's
> practically tautological. I'm not sure I agree about the efficiency
> question. To me the main question is whether the behavior of the
> static API can degrade in a reasonable manner in environment that
> don't support its full functionality.
It is more efficient because neither the app nor the API functions have
to continually check for features or waste time calling code that falls
through silently.
>
>
>>> One technique I've used on several occasions in my own mini-library
>>> code is to add "supported" properties to API functions, which return
>>> values "complete", "degrade", "empty", or false, depending upon
>>> whether the function is completely supported, degrades acceptably,
>>> returns empty objects or arrays, or is totally unsupported, with code
>>> something like this:
>> Okay, but I don't see why you would need more than a boolean (e.g. works
>> or not).
>
> I've done that.too. It works fine. The trouble is then if there is a
> simpler supported version of the functionality with fewer bells and
> whistles that I can fall back on. It's nice to have the super-cool
> fade fall back on a simple hide in the absence of the necessary
> environmental features. Then I simply don't have to think about it
> usually.
Sure, do that at the application level. If the fade effect is there,
define a hide/show function that uses it. Otherwise use the stock
hide/show function.
if (API.effects && API.effects.fade) {
myCoolShowFunction = function() { ... };
} else {
myCoolShowFunction = API.showElement;
}
Note that this is a generic example. It is not specific (but is
similar) to My Library, which actually does something like this
internally. As a matter of fact, as it sits, My Library's show/hide
functionality is less than ideal as it actually does ignore effects
options on hide/show when effects are impossible. But when only
_specific_ effects are unavailable (e.g. fade), it is up to the
applications to avoid passing those effects functions in the options.
That's something I need to rearrange down the road. For now the
incongruity is simply documented. There actually is a flag on the
affected methods indicating whether the hide/show operation will be
immediate or progressive (the latter indicating that a callback can be
used). Affected methods include setElementHtml, changeImage, as well as
showElement and a few others that can optionally use effects and/or a
callback.
The effects stuff is a bad example though as effects in general will
virtually always be possible (all they need is CSS support and
setInterval). The fade effect may be unavailable in some ancient and/or
limited browsers, but that would be rare compared to something like XHR.
And it is hard to imagine an application that would actually _need_
effects at all, so other than checking for specific effects like fade,
it is fine for most applications to remain oblivious to their presence
or absence.
Of course, when using the OO interface, it is as simple as:-
var E;
if (E && E.prototype.fadeIn) {
// OO application that _must_ be able to fade in elements
}
>
>
>>> API.myCoolFade = API._support((function() {
>>> if (API.opacitySupported) return "complete";
>>> return "degrade";
>>> )(), function(elt) {
>>> if (API.opacitySupported) {
>>> // cool opacity animation here.
>>> } else {
>>> if (elt) elt.style.display = 'none';
>>> }
>>> });
>> See what I mean about bloat? Imagine an API with thousands of methods
>> doing something like this for each one. It wouldn't be feasible on the Web.
>
> Well an API with thousands of methods would scare me much more than
> this code. Even jQuery's large API has fewer than 250 methods in it.
Large is relative. jQuery isn't much more than a haphazard query engine
with a few basic (and broken) DOM wrappers thrown in. Where they are
starting to bloat is the ill-advised "Live" feature, which attempts to
bottle event delegation (again it is about marketing rather than
providing a sound API). Also, they combine getters and setters, which
reduces the number of methods, but makes application code virtually
unreadable (you must count the number of arguments passed to
differentiate between get and set operations).
>
>
>>> It has worked for me, but I haven't had to use it much, because it's
>>> never been for large public APIs. It was exactly this sort of pseudo-
>>> fade that motivated it, though, and it worked well enough there. For
>>> API methods that returned arrays of nodes, usually there is complete
>>> support across browsers, but when there isn't, the "supported"
>>> property tells me that the function will at least return me an array I
>>> could continue to process, even if it's empty, which often simplified
>>> further coding.
>> Yes, for a small Intranet app, you could certainly get by with the above
>> (depending on its performance requirements of course).
>
> Why don't you think this would scale to the multiple environments of
> the Internet?
In short, too many flag checks in the application code. Virtually
everything would require such checks as nothing is assured on the
Internet. It's much simpler (and more efficient) to detect methods of
the API up front and be done with it.
>
>
>>> In any case, I've never tried to code in the dynamic API style for
>>> library code. Are there good examples of libraries that do it? I
>>> understand My Library does; are there other publicly available
>>> examples?
>> Not that I know of. :)
>
> So it looks like you have some selling to do! :-)
>
You mean as far as examples of people using My Library. There are
several people building applications with it that I know of (and likely
many more that I don't know of), but it is only a couple of months in.
I think that if I continue to improve the documentation and wrap up the
last of the CSS3 selectors that everyone seems to expect these days, it
will sell itself. If something like jQuery can become wildly popular,
despite outrageous shortcomings and inefficiencies, I think it is only a
matter of time for mine to do the same.
I'm not much for selling though. As I've said repeatedly, the best bet
is to avoid general-purpose libraries altogether. But I suppose if you
are already sold on the strategy, mine has a lot of positives that
aren't found in any of the others (starting with the dynamic API and
ending with the support that I provide). Also, there is the fact that
none of the others can do much of anything without browser sniffing (in
one form or another). All but jQuery (which uses bad object inferences
and bogus feature testing) are still fixated on the UA string, which is
clearly a fatal flaw (and has been for a decade). They don't see it as
fatal as to them it is sane to swap out a huge script every time a new
browser comes out (and to ignore all that came before). But the
end-users won't buy (or even understand) that when their favorite sites
break (they'll just get new favorites).
David Mark
[...]
> Note that this is a generic example. It is not specific (but is
> similar) to My Library, which actually does something like this
> internally. As a matter of fact, as it sits, My Library's show/hide
> functionality is less than ideal as it actually does ignore effects
> options on hide/show when effects are impossible. But when only
> _specific_ effects are unavailable (e.g. fade), it is up to the
> applications to avoid passing those effects functions in the options.
> That's something I need to rearrange down the road. For now the
> incongruity is simply documented. There actually is a flag on the
> affected methods indicating whether the hide/show operation will be
> immediate or progressive (the latter indicating that a callback can be
> used). Affected methods include setElementHtml, changeImage, as well as
> showElement and a few others that can optionally use effects and/or a
> callback.
>
Actually, checking my documentation, I made that sound more complicated
than it is, at least for showElement. Unless you consider environments
that are lacking setInterval, the ability to do progressive hide/show is
known at _build_ time (as it should be) as the showElement method itself
would be pruned in environments lacking CSS support. As noted in the
docs, this is not the case for setElementHtml and a few others, which is
something I do need to address. You should be able to determine the
capabilities of these methods at build time (at least as far as the
callback goes) and not have to check the (async) flag property at call time.
Scott Sauyet
> Scott Sauyet wrote:
>> David Mark wrote:
>>> Scott Sauyet wrote:
>>>> For instance, this is certainly fine for me:
>>>>
>
>>>> And this is overkill:
>
>>>> if (API.roundCorners) {
>>>> API.roundCorners(myDiv);
>>>> }
>>> No, you do _not_ do it that way. You do a one-time check at the start
>>> for required methods.
>
>> Do you centralize all code that might need rounded corners, then?
>
> I don't think this is a good example feature as it is hard to imagine
> code that hinges on rounded-corners. But yes, depending on the
> complexity of the applications, you may need to break it up into
> sections and use a different gateway for each section.
I'm not feeling very well and don't have the energy to respond to this
whole interesting post, but I do want to follow up on this point.
I'm not sure how you combine your gateways. If you have multiple
features being used for one block of code, it's of course
straightforward to do this:
var myForm = /* ... */,
myElt = /* ... */,
myContainer = /* ... */;
if (API.attachEvent &&API.validateForm && API.xhr &&
API.cloneElt && API.appendElt && API.roundCorners) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
API.roundCorders(newElt);
},
error: function(msg) {/* ... */}
})
}
});
}
But to my eyes there's something wrong with this code. I really want
to run everything else even if rounded corners are not supported.
That's just a nice tweak. Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed, but you seem to be saying that these should all go at a
very high level. What am I missing?
-- Scott
David Mark
Join the club on not feeling well. Briefly, you aren't missing
anything. There are exceptions to every rule.
Ivan S
Well, I suppose one could call "API.roundCorners" function (and do
feature test) at the time of creating element (var myElt = /* ... */
<- here, I suppose), so that "API.cloneElement" would return element
that already has rounded element (or not, if feature is not
available).
This approach seems better to me, since there is separation of concern
(Ajax - styling).
Any thoughts about this? :)
RobG
> 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
For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8). It wouldn't run
any of the tests at all. For the slickspeed tests, the only libraries
that completed any were jQuery 1.2 and YUI 2.7, which managed to
complete most of them. None of the others could complete any test, all
ending with 'error returned'.
The taskspeed tests at dojotookit.org would not run at all.
For the dojo slickpeed tests, jQuery 1.2.6, YUI 2.5.2 and Dojo 1.1.1
did reasonably well.
I won't be keeping this browser around for long, about to upgrade it
to Mac OS 10.4. I tried IE 5.2 but as expected, nothing ran at all.
--
Rob
David Mark
> On Feb 19, 6:43 am, David Mark <dmark.cins...@gmail.com> 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
>
> For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8). It wouldn't run
> any of the tests at all.
Yes, same for IE < 6. The testing framework itself isn't up to the
task. :(
> For the slickspeed tests, the only libraries
> that completed any were jQuery 1.2 and YUI 2.7, which managed to
> complete most of them. None of the others could complete any test, all
> ending with 'error returned'.
The query features are almost certainly pruned in that browser and
obviously the SlickSpeed framework doesn't perform any feature detection
on the API (e.g. checking to see if the $ function is available). I'd
be curious to know if $ (or API.getEBCS) is actually present in that
browser (in which case there is an undiscovered hole in the internal
feature detection).
>
> The taskspeed tests at dojotookit.org would not run at all.
>
> For the dojo slickpeed tests, jQuery 1.2.6, YUI 2.5.2 and Dojo 1.1.1
> did reasonably well.
If they didn't pass (or fail in my case) _all_ of them then they didn't
do their jobs, allowing the calling app to get inconsistent results.
>
> I won't be keeping this browser around for long, about to upgrade it
> to Mac OS 10.4. I tried IE 5.2 but as expected, nothing ran at all.
>
The testing framework itself bombs on that browser. I was able to run
it in IE5.5 though (and virtually all of the squares were blacked out
but the last two columns, which were perfect). :)
Scott Sauyet
> Scott Sauyet wrote:
>> I'm not feeling very well and don't have the energy to respond to this
>> whole interesting post, but I do want to follow up on this point.
>
>> I'm not sure how you combine your gateways. If you have multiple
>> features being used for one block of code, it's of course
>> straightforward to do this:
>
>> http://groups.google.com/group/comp.lang.javascript/msg/3399fd2174a4ac98 ]
>
>> But to my eyes there's something wrong with this code. I really want
>> to run everything else even if rounded corners are not supported.
>> That's just a nice tweak. Of course it's easy enough to remove the
>> initial API.roundCorners check and add it around the one line where
>> it's needed, but you seem to be saying that these should all go at a
>> very high level. What am I missing?
>
> Join the club on not feeling well. Briefly, you aren't missing
> anything. There are exceptions to every rule.
Hope you're feeling better today.
Okay, I think that clears up my confusion. I'm mixed about the
dynamic API; I can certainly see some benefits, but I'm not sold on
the additional complexities. I'm going to have to think about this
some more.
-- Scott
Ivan S
Now I see I've made a mistake (and was unclear about what I was
thinking). It's not "has rounded element" but "has rounded corners".
Sorry about that, I haven't drank my first coffee at the time I was
writing post, so my brain wasn't functional. :)
If this:
"Of course it's easy enough to remove the
initial API.roundCorners check and add it around the one line where
it's needed"
does mean adding test like this (as I understood):
var myForm = /* ... */,
myElt = /* ... */,
myContainer = /* ... */;
if (API.attachEvent && API.validateForm && API.xhr &&
API.cloneElt && API.appendElt) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
if (API.roundCorners) API.roundCorders(newElt);
},
error: function(msg) {/* ... */}
})
}
});
}
Maybe, something like this would be little better:
var myForm = /* ... */,
myContainer = /* ... */;
var myElt = /*...*/;
if (API.roundCorners) {
API.roundCorners(myElt);
}
if (API.attachEvent &&API.validateForm && API.xhr &&
API.cloneElt && API.appendElt) {
API.attachEvent(myForm, "submit", function(evt) {
if (API.validateForm(myForm) {
API.xhr({
method: "POST",
url: myForm.action,
success: function(data) {
var newElt = API.cloneElement(myElt);
// update newElt using data;
API.appendElt(myContainer, newElt);
},
error: function(msg) {/* ... */}
})
}
});
}
This way Ajax functionality isn't "polluted" with styling
functionality.
***
This isn't so much important, but me personally would make some kind
of separation between "this" and "that" functionality.
I'm no JS expert, so I don't know is this good approach (in some other
languages it is). Any thoughts, this time? :)
Scott Sauyet
> Ivan S wrote:
>> Well, I suppose one could call "API.roundCorners" function (and do
>> feature test) at the time of creating element (var myElt = /* ... */
>> <- here, I suppose), so that "API.cloneElement" would return element
>> that already has rounded element (or not, if feature is not
>> available).
>
>> This approach seems better to me, since there is separation of concern
>> (Ajax - styling).
>
>> Any thoughts about this? :)
>
> Now I see I've made a mistake (and was unclear about what I was
> thinking). It's not "has rounded element" but "has rounded corners".
> Sorry about that, I haven't drank my first coffee at the time I was
> writing post, so my brain wasn't functional. :)
>
> If this:
>
> "Of course it's easy enough to remove the
> initial API.roundCorners check and add it around the one line where
> it's needed"
>
> does mean adding test like this (as I understood):
> if (API.attachEvent && API.validateForm && API.xhr &&
> API.cloneElt && API.appendElt) {
> var newElt = API.cloneElement(myElt);
> if (API.roundCorners) API.roundCorders(newElt);
> }
>
> Maybe, something like this would be little better:
>
> if (API.roundCorners) {
> API.roundCorners(myElt);
> }
>
> if (API.attachEvent &&API.validateForm && API.xhr &&
> API.cloneElt && API.appendElt) {
> var newElt = API.cloneElement(myElt);
> }
>
> This way Ajax functionality isn't "polluted" with styling
> functionality.
Yes, if the rounded corners implementation is such that cloning the
relevant element copies along with it any scaffolding used for the
rounding, this would work. There are probably implementations which
wrap the target element in additional styled DIVs, and such
implementation wouldn't allow this technique.
But remember that this was just an example. David is suggesting that
a few high-level gatekeeper tests can be done on dynamic library
methods and then all code guarded by those gatekeepers could be
expected to function properly. While that works, the lack of
granularity bothers me, and I was trying to show a straightforward
example of where that would fall down. Rounded corners is one of my
favorite examples of this sort of thing. It's nice to have; designers
love it. But I refuse to add the necessary scaffolding to page
markup. I will do it in JS, but if it's not supported, they have to
live with square boxes! Entangling this nice-to-have feature with
more important ones, especially to turn them all off as a group, is
unacceptable.
David's response is fine: Sometimes you need more than just the high-
level gatekeepers.
I'd love to see largish examples of code written with this dynamic API/
gatekeeper method. It's simple enough for small things, but it's not
at all clear to me how it would scale.
-- Scott
Ivan S
Thanks for your answer. :)
> I'd love to see largish examples of code written with this dynamic API/
> gatekeeper method. It's simple enough for small things, but it's not
> at all clear to me how it would scale.
I like David's idea to abstract several functionality, something like
this:
if (API.attachEvent && API.validateForm && API.xhr && API.cloneElt &&
API.appendElt) {
if (API.roundCorners) {
API.myAjax = function() {
// // Ajax functionality with "round corners"
}
}
else {
API.myAjax = function() {
// Ajax functionality without "round corners"
}
}
}
This way API.myAjax can be called without worrying about having "round
corners" functionality or not. It looks nice (at least to me), but one
thing bugs me. If I have "n" (n - natural number greater than one)
functions that I want to abstract, I would have to make every possible
combination from "n" of them. Right?
That can be quite a work if "n" is large number. Is there any better
approach (question is for everyone :) )? Maybe object-oriented
approach would be better in cases like this?
David Mark
> On Feb 19, 6:43 am, David Mark <dmark.cins...@gmail.com> 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
>
> For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8).
Confirmed that Safari 1.2 is fine for My Library and the rest bombed on
at least one test (and you can't be a little bit pregnant). I didn't
see the results myself, but if history is any indicator, the "at least
one" report likely translates to "many".
Now that I notice you were talking of Safari 1.0.3 and not 1.2, I am
almost certain that the query features (among others) are pruned, so
SlickSpeed is just blundering by trying to call a $ function that isn't
there.
I suspect I will go ahead and fix up these frameworks now that I am
hosting them on my site. First thing I want is for TaskSpeed to run in
IE5.0 (it does actually work in 5.5, for mine only though) and make it
detect when the API features it needs are absent. Same for SlickSpeed
as one of the first lines in slickspeed.js throws an exception.
//base test functions
function forEach(iterable, fn, bind){
for (var i = 0, j = iterable.length; i < j; i++) fn.call(bind,
iterable[i], i, iterable);
};
Like they really needed to use call. :(
But I need to make it do some rudimentary feature detection and skip and
mark columns that have degraded gracefully (won't happen West of the
last two at the moment, but perhaps in the future). IIRC, queries
degrade at version 6 in Opera, version 4 in NN and either 5.0 or 4 in
IE. Probably Safari 1.1 or 1.0 is the end of the line for them as well.
I'll find out. For those who don't understand the point of all of
this, read up on it the test-related discussion in my forum. If, after
that, you still don't get why I test "ancient" browsers, you probably
never will. :)
The CSS for these things is a mess too (what a shock) and I have some
ideas for styling columns that have at least one failure, cells that
total those disallowed columns, etc. It really needs to have _expected_
results as well. It seems silly that the SlickSpeed test must rely on
disagreements to determine there is a counting problem (what if they are
all wrong?) Other than "*", which can be affected by DOM
implementations and a couple of the more esoteric and less than formally
specified (and/or non-standard) selectors, the answers are not really
open to interpretation. With expected results, it will be possible to
mark wrong answers, rather than obscuring the results for the whole row.
Dr J R Stockton
<hmneeb$qin$1...@news.eternal-september.org>, Wed, 3 Mar 2010 23:51:06,
David Mark <dmark....@gmail.com> posted
> ...
>I
> ...
You write a lot about something called "My Library", a term for which
Google finds 19,600,000 results.
Would it not be helpful to put, say, <http://www.cinsoft.net/mylib.html>
in signatures to your articles?
That introductory page does not say what language the library is written
in.
The link on that page to this newsgroup points to Google. However, this
is a Usenet newsgroup, and it would be good to have a link to
<news:comp.lang.javascript> before the Google one. A Web browser
should call up the user's newsreader software, if any, from that link.
There appears to be only one instance of the word "date" in that domain,
and that is on a page seemingly intended for readers of Spanish :-) .
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.07 MIME
Prof Timo Salmi's Usenet Q&A <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqn.zip>
TS FAQs via : http://www.uwasa.fi/~ts/http/ : tsfaq.html quote margin &c.
Jorge
wrote:
>
> There appears to be only one instance of the word "date" in that domain,
> and that is on a page seemingly intended for readers of Spanish :-)
Y ja, y ja, y ja. Feestro, te bi a partí el diodenor por mochu elo :-)
--
Jorge.