My Library _passes_ TaskSpeed in IE < 7

D

David Mark

Andrew said:
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.
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.
Still the logic seem robust whereas yours seems lacking.

Lacking is putting it mildly. I'd say virtually non-existent. :)
And if a convincing article were written would you simply ignore it?

If his pattern of behavior holds...
 
G

Garrett Smith

Matt said:
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(VS.85).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?
 
M

Matt Kruse

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

Scott Sauyet

Matt said:
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

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

Garrett Smith

Andrew said:
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

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

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
 
G

Garrett Smith

Matt said:
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.
 
D

David Mark

Matt said:
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.
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.
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.
 
D

David Mark

Scott said:
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.

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

David Mark

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

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

Scott Sauyet

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

David Mark

Scott said:
Scott said:
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. :(
 
T

toby.oconnell

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.

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

David Mark

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! ;)
 
P

Peter Michaux

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.

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
 
D

David Mark

Peter said:
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.


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

Peter Michaux

Peter Michaux wrote:

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
 
D

David Mark

Peter said:
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. :)
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,079
Messages
2,570,574
Members
47,207
Latest member
HelenaCani

Latest Threads

Top