Why should I eschew prototype.js?

[Dr J R Stockton]

In comp.lang.javascript message <8db60425-1b85-42ae-8744-d522680d9b2a@s1
2g2000prg.googlegroups.com>, Fri, 16 Nov 2007 12:19:49,
"(e-mail address removed)" <[email protected]> posted:

Lines: 253

I think the idea here is looking at the code is a good idea.

There will always be bugs. (browsers are a good example) Some bugs you
can live with, others are too unacceptable.

Mistakes and misconceptions are different.

Looking at code can show how the author thinks. Mistakes are one
thing, but when a script is written with misconceptions, well, it kind
of makes you look sideways at the script.

Please trim your quotes. See FAQ 2.3.

 

[Richard Cornford]

In this very thread in fact.

If you are talking about "s0lnic" then you should note that he has
hardly made a dozen posts in the last 3 month and the only code he has
posted featured the usual cross-browser error and needed to be corrected
before it was fit for its proposed purpose.

I appreciate it.


Why has a library not been written this way?

In what way? Such that the code used conforms to language's
specification and does not rely on inconsistent implementation details?
Lots of libraries have been written in that way. For example I have not
yet noticed anything in dojo that relies upon language extensions or
non-standard implementation features. Granted the evidence that dojo's
authors don't understand the code they are writing suggests that that
is itself probably best attributed to coincidence, but still it is the
case.

Obviously it's not your responsibility to do it, or to even
know the reason why it hasn't been done thus far,

Except it has been done, and is probably the norm, even in otherwise
very dubious library code.

but if so many people are in error, and it causes you
any distress,

What makes you think it causes me any distress? I am massively cynical,
so a world where idleness, ignorance, ineptitude and incompetence are
endemic is reassuring (almost comforting).

it would behoove you to write one, or at
least begin one.

One what? A general-purpose library? Doesn't that imply a
presupposition that a general-purpose library would be
something that would be useful to have? If that a-priori
assumption is not itself valid then creating such an object
could be a bad idea and I could be entirely justified in
not spending my time pursuing folly.

Perhaps set up a project? Clearly you care a lot about
this subject, and have invested much time in it. This
is just another avenue by which you can participate in
-- and even shape -- the future of how javascript is used.

Why do I need another avenue to shape the future of how javascript is
used?

So this is the browser's problem.

No, it is the programmer's responsibility. The responsibility of the
browsers is no more than to correctly implement the standards that they
claim to implement. Whatever they do beyond that is up to them.

They are too permissive.

It does appear that web browsers being permissive leads to problems when
people try to learn programming entirely by trial and error in a
restricted set of browsers and then try to move on to cross-browser
scripting.

But if you think about it, if 90%
of people do something one way, and that way doesn't conform
to "the standard" (in this case, ECMA), doesn't the
way most people do it BECOME the standard?

But what then 'becomes the standard'? The code I highlighted is amenable
to three different interpretations in web browser environments, and
actually behaves radically differently in the two most popular browsers.
Is that either JavaScript's or JScript's interpretation that 'becomes
the standard', or do you mean that it becomes the standard to be writing
code that behaves differently in each and every browser it encounters?
We tried that and it did not work, which is why the standardisation of
the language (and the DOM) was started.

One of the main reasons that it is currently possible for the uses of
javascript to be taking the directions they are taking is that
ECMAScript has been stable since the turn of the century and so its
implementations have become very complete and stable.

It may be horrific in its
implementation, syntax, whatever, but so is HTTP.

What is wrong with HTTP? It does precisely what it was designed to do,
and does it very well. Of course you start to see issues as soon as you
attempt to use HTTP for something other than what it was designed for,
but that is hardly surprising or unusual.

So you either adapt
and use it, or try to make change.


Again, this may be the browser's fault then.

No, it is the programmer's fault.

Bear in mind that browser developers do have to cater to
existing web pages, and have all sorts of testing to try
to ensure that nothing breaks in future versions. I
highly doubt that just because a page doesn't conform to
ECMA standards, the browser developers will say "screw
that web page, if they don't follow ECMA they don't get
a proper rendering in our browser."

ECMAScript conformance has nothing what so ever to do with rendering.

Whether the Prototype.js code conforms to the ECMA standard or not was
not the issue. The issue is that the code does not actually do what its
author clearly thinks it does, and what it does do is not even the same
in the two most common browsers. Re-writing it as ECMA 262 conforming
code only acts to avoid that issue, as the code will then do the one
thing it is programmed to do, and do that same thing on (at absolute
minimum) all the browsers that Prototype.js is interested in.

It would also be possible to re-write the code so that it acted in a way
that made sense in terms of how it would be interpreted under
JavaScript(tm) and JScript, where you would short-circuit the
heavyweight - if - test on finding that the - each - function was
defined prior to the test (i.e. wherever the test was futile). The
result would not be any more cross-browser but at least it would show an
author actually programming the library instead of being at the mercy of
misconceptions and coincidence.

This may work if the percentage of "bad" web pages were
vanishingly small, but hey, this is the real world where people are
stupid and market share is of vital importance to a browser's
continued existence.

Market share has nothing to do with the existence or viability of web
browsers. Recently the growth area in web browsers has been browsers for
embedded devices (usually mobile phones), and that is simply because
that is virtually the only market where money is exchanged for web
browsers (even if indirectly). Unlike the desktop browser market where
if the user doesn't get the browser for free they go and get one form
someone else. The embedded browsers don't have much market share (yet),
but they do have the potential to fund their own development, return a
profit, and continue to exist for that reason.

I'm not saying I'm encouraging bad coding, or
stupidity, but I'm being a realist.

You are not being a realist. You are assuming that you have enough
information to make informed judgments about a subject while admitting
near total ignorance of the technologies involved. A realistic position
would be to recognise that you are probably not yet qualified to judge.

Once all market share is captured, THEN you can begin to
gradually enforce whichever standards are the best. But
until then, it's a free-for-all.

<snip>

No web project is ever created without it's having some purpose. That
is, there is always someone who wants something from it. That
'something' may be profit/turnover, publicity, goodwill, specific
functionality, etc. (or some combination of those sorts of things). The
'professional' web developer's responsibility should be to maximise the
project's ability to achieve that 'something'. That is not a
"free-for-all", it is a knowledge driven process with a context specific
pre-defined direction.

I truly do appreciate your perspective. I did a little
research on you, and you appear to be a very intelligent
individual, although (and I don't mean to be destructively
critical) a bit of an idealist/ purist--which the world
does need, but isn't the way the world works.

The way the world works at the moment has the demand for my (client-side
scripting) skills exceeding their supply. Which leaves me
(idealist/purist or not) selling in a seller's market and quite happy
with the outcome. And the direction javascript use has taken makes me
think that that situation is not going to change in the near future.

When my boss comes to me and says, "Can we do this thing ... ?" (as he
usually does at lest a couple of times a week) I can answer "yes", "yes,
but ..." or "no" and be pretty sure that when I say "yes" I can deliver,
when I say "yes, but ..." I am accurately enumerating the pertinent
caveats, and that when I say "no" he is not going to be able to find
anyone else who can deliver what I cannot. This while the vast bulk of
the 'competition' are operating at a level of knowledge and
understanding that is below those of the authors of the libraries that
they have learnt to be dependent upon. While the authors of those
libraries don't actually know enough to be programming with javascript.


Can you judge the 'harm'? A while ago I was directed to a web page where
a web developer was proudly explaining how he had used a particular
rapid development process/system to create an e-commerce site, and how
easy/profitable it had been for him. He was very satisfied with the
outcome, and though his clients were also very happy with the outcome.

However, when I viewed the site using IE 6 I found that the shopping
cart did not work at all, which is pretty fatal for an e-commerce site.
Looking at the source for the site it immediately became obvious that my
problem was because of the specific configuration of my IE 6, but
simultaneously I observed that the code would only 'work' with 3 or 4
'major' desktop browsers in their default configurations.

There is a lot of nonsense talked about 'target audiences' when trying
to justify only supporting limited sets of (default configurations of)
browsers. It is a notion that starts with odd assertion that there is a
strong relationship between groupings of individuals and the web
browsers they use such that a 'target audience' implies some specific
set of web browser will be used by that audience (as opposed to
admitting the reality where anyone could be using just about any
(non-archaic) browser at all and that it is only a trivial coincidence
that the majority of them will be using the 'most common' browsers). The
'target audience' excuse also suffers from web 'statistics' problem,
where HTTP is inherently resistant to accurate browser usage statistics
gathering and most statistics gathering techniques are incapable if
distinguishing 'minor' browsers from 'major' browsers.

On the other hand the notion of 'target audiences' did have something to
contribute to this particular project because the e-commerce site in
question was selling web icon imagery. That means that its 'target
audience' is web developers, web designers and people in related fields.
While generalisations about web browser usage are inherently problematic
it certainly is the case that this particular target audience is the
target audience that is _most_ likely to be using non-standard web
browsers and web browsers in non-default configurations (because they
are the single group of users most likely to know about a wide range of
browser, have attitudes towards the browsers they use, and be confident
about configuring those browsers in precisely the way that suites them).

This means that from the point of view of the e-commerce site's client
the web developer's 'decision' to create something that only worked with
default configurations of 3 or 4 browsers was potentially harmful. It
effectively throttled potential turnover at the design stage. Of course
they don't appreciate that as if they had been in a position to make
that sort of judgement they would not have needed to employ someone else
to create the site for them. So instead they employed a 'professional'
and trusted that they would not be screwed as a result.

(Remember that this e-commerce site could have been created such that it
could take money off anyone who's browser is capable of making HTTP(S)
connections, displaying HTML pages, showing images and submitting a from
in a POST request (which is pretty much every non-pure text web browser
that has ever existed).)

The ironic aspect of this is that a month or so after this site was
pointed out to me I was in the office on a Saturday afternoon knocking
up some web material for a sails presentation and my boss decided that
he wanted different/better icon graphics. He could not get (hold of) any
of our designers to come in and create the graphics and didn't think he
could afford to leave the task until Monday. So he went to Google,
credit card in hand, to find and purchase some off the shelf graphics.
The very fist site he hit was our e-commerce icon seller above. He liked
one of the sets of icons and so hit the shopping cart to purchase them,
and it did not work for him. It did not work for him because his IE is
not in its default configuration either, but his is not in its default
configuration because our technical department found out that he had let
some spyware get onto his laptop and so leaked a company e-mail address
book (meaning we all got spammed continuously for a couple of months).
So they have clamped down his browser security in the Internet zone and
arranged that he (and I) cannot re-set those settings. The practical
upshot was that my boss's money went to a different seller of web icons.

So given that the original web developer was proud of his creation, and
how easy and profitable it had been (for him), so much so that he
published a web page to boast about his triumph, do you think he
appreciated the harm his design decisions had done? I don't think so,
and if challenged I bet he would make a lot of noise about working in
the 'real world' and play down the impact of his design decisions on his
client's turnover as 'not statistically significant' (without daring to
ask their opinion on the subject).

Again, if they are so trivial, why wouldn't a "good" library
have been written?

For a start; a total disconnection of responsibilities. You just don't
need a 'library' to do trivial things.

But where is your statement of a valid justification for the creation of
a 'library' to start with? Without that we haven't even arrived at this
question.

Wouldn't evolution cause the "good" librarues to bubble up
and become the de facto standard? Wouldn't "bad libraries"
break in future revs, independent browsers, etc, and the "good
libraries" gain mind- and market-share with each manifestation
of the "bad libararies'" failure?

In a world where people don't see demonstrations of a library's author
not knowing the language well enough to actually be programming with it
as sufficient grounds to dismiss the use of that library out of hand it
is quite likely that manifestations of failure would go unnoticed (or be
disregarded).

Richard.

 

[Matt Kruse]

But where is your statement of a valid justification for the creation of
a 'library' to start with? Without that we haven't even arrived at this
question.

Some arguments in favor of a 'library' are:

1. Normalizing browser behavior, to the greatest extent possible, and
encapsulating the code required to do so into a 'standard' API
relieves the developer of the effort of considering browser quirks
every time code is to be written.

2. The code required to perform some common and repeated javascript
tasks correctly can be long and error-prone. Putting a layer over
commonly-used functionality so access to that functionality is shorter
and more concise leads to clearer code and simplifies development.

3. Not all organizations or development efforts are able to employ
javascript programmers with the level of knowledge required to write
robust, cross-browser code. Having a library of pre-written code by
someone who is much more experienced allows more inexperienced
javascript developers to perform complex tasks and develop
functionality that otherwise could not have realistically been
written.

4. A single library js file can be used on many pages throughout a web
site or webapp, and the reasonable assumption is that browsers will
cache the source. Rather than writing page-specific code (or putting
reusable functions in each page where they are required) that is
downloaded with each request, the caching of the library code can
result in faster pages.

There are caveats, of course. I don't think that using a general-
purpose library is always a good solution. Do you never believe that
it _is_ a good solution?

Under what situations do you think that using a general-purpose
library is a good choice? What kind of functionality would this
library have or not have?

Matt Kruse

 

[Richard Cornford]

Some arguments in favor of a 'library' are:

Arguments in favour of a 'library' are things that can only be achieved
with a library and are in some sense favourable.

1. Normalizing browser behavior, to the greatest extent possible,

That does not require a library. And normalizing browser behaviour to
the greatest extent possible is not a particularly good idea because any
code acting to normalise any browser behaviour that is irrelevant in
context is wistful.

and encapsulating the code required to do so into a 'standard'
API relieves the developer of the effort of considering browser
quirks every time code is to be written.

You can only get a 'standard' API if that API is designed for a worst
case scenario (say, must make provision for operating with multiple
frames/framesets regardless of whether any particular application has
frames or not) and be all encompassing. Otherwise you end up with
multiple APIs, and none of them in a position to be regarded as
'standard'.

A system where multiple smaller scale APIs are aggregated for any given
application would be considerably more efficient, but could not easily
be regarded as 'a library'.

2. The code required to perform some common and repeated
javascript tasks correctly can be long and error-prone.
Putting a layer over commonly-used functionality so access
to that functionality is shorter and more concise leads to
clearer code and simplifies development.

But putting a layer over commonly used complex functionality does not
require a library.

3. Not all organizations or development efforts are able to
employ javascript programmers with the level of knowledge
required to write robust, cross-browser code.

Then maybe they should not be in the business of attempting to write
cross-browser code.

It remains the case that probably the most important aspect of browser
scripting is designing a system that is appropriate for the context of
its use. If an organisation has nobody who capable of cross-browser
scripting how can they be making informed design decisions?

It is also not the case that a library is necessary to allow individuals
to do things that they would not otherwise be capable of. As is
demonstrated by all the copy and paste code collections that exist.

Having a library of pre-written code

A library is not the only means of having access to pre-written code.

by someone who is much more experienced

Yet we find the libraries in use are often written by individuals who
don't know enough be actually be programming in javascript. Which does
not mean that they are not more experienced than these 'inexperienced'
developers, but it does say something about the sorts of outcomes that
can be expected.

allows more inexperienced javascript
developers to perform complex tasks and develop functionality
that otherwise could not have realistically been written.

You mean 'realistically written by them', because if a library could
facilitate its creation in some sense then it must have been writable to
start with. Libraries don't perform magic so anything that could be done
with one could also be done without one.

4. A single library js file can be used on many pages throughout
a web site or webapp, and the reasonable assumption is that
browsers will cache the source.

As may be true for any single javascript file, so not an argument in
favour of libraries, but instead an argument in favour of the considered
deployment of javascript code.

Rather than writing page-specific code (or putting
reusable functions in each page where they are required) that is
downloaded with each request,

The situation is not a choice of using a library or writing page
specific code.

the caching of the library code can result in faster pages.

The caching of any code can result in faster pages. There is nothing
special about files containing 'libraries' that encourages their
caching.

And there are no shortage of examples where people are including entire
libraries in web pages to do ridiculously trivial tasks. Just last week
someone posted a suggestion here that an OP include Prototype.js in a
web page just in order to reference two elements by ID and set their -
style.display - properties. It does not matter how much caching goes on
in that process, the outcome will absolutely not be faster pages.

There are caveats, of course. I don't think that using a
general- purpose library is always a good solution. Do you
never believe that it _is_ a good solution?

A good solution to what? The current set of general purpose libraries
have a perverse attitude towards browser support. Too much for most
Intranet/web applications uses, and too little for public web
applications.

Under what situations do you think that using a
general-purpose library is a good choice?

Whenever such a library exactly matched the application it was to be
put to, with nothing superfluous or wasteful in context.

What kind of functionality would this
library have or not have?

Exactly the functionality necessary for the task.

So your list does not include anything that both requires a library and
is favourable. Thus there is no argument in favour of libraries here.

Richard.

 

[Matt Kruse]

Arguments in favour of a 'library' are things that can only be achieved
with a library and are in some sense favourable.

That is quite a bias to begin with. I see no reason why arguments in
favor of a library must be things that can only be achieved with a
library. Rather, a library is one way to gain the benefits that I
listed. Given a very specific context, a library may or not be the
best choice in a given situation. So I think you're starting out with
a ridiculous set of criteria with which to judge the suitability of a
'library' approach.

I think you should rather consider the possible benefits of a using a
library, then consider the cons, and decide if overall it is a good
choice. If you consider all the factors, I find it hard to believe
that you think using a library is _never_ the best choice.

That does not require a library.

Of course not, but using a library is one way to accomplish the goal.

And normalizing browser behaviour to
the greatest extent possible is not a particularly good idea because any
code acting to normalise any browser behaviour that is irrelevant in
context is wistful.

Why so? If I have an internal webapp used by 10 people on a LAN, do
you really think that an extra 50k of js code on a page is of any
concern to to me? In some contexts, this may be a con. Not in all.

You can only get a 'standard' API if that API is designed for a worst
case scenario

Not at all. "Standard" doesn't have to mean that it covers all cases.
Just that it is the API used regularly in most cases. A "standard" API
can put restrictions on its applicability, as well. There are plenty
of "standard" API's out there that don't handle every possible use
case.

But putting a layer over commonly used complex functionality does not
require a library.

Of course not. But it is one benefit of a library.

Then maybe they should not be in the business of attempting to write
cross-browser code.

The lack of expertise in an area has never been much of a concern for
businesses in the past. It just means you have to be more creative in
solving the problem. If every company needed to be an expert in every
area of work they did, surely there would be few successful companies.
The fact is, sometimes you need to do the best you can with the
resources you have. To expect anything else is truly naive.

A library is not the only means of having access to pre-written code.

Of course not, but it is one approach.

Yet we find the libraries in use are often written by individuals who
don't know enough be actually be programming in javascript.

And yet they do so, and their work is used by thousands of people on
thousands of successful web sites around the world. If they don't know
enough to write javascript, how do you account for their success?
Surely if their work was horrible it would have been exposed by now
and the free market of information would have found a better
replacement, no?

4. A single library js file can be used on many pages throughout
a web site or webapp, and the reasonable assumption is that
browsers will cache the source.

[snip]
And there are no shortage of examples where people are including entire
libraries in web pages to do ridiculously trivial tasks.

Which is part of my argument - if you include jquery.js on every page,
for example, some pages may use it heavily while others use it only
for a line or two. But once it's cached, it doesn't even matter. You
can use it for just 2 lines if you want to on a page without worrying
because it doesn't require a big additional download.

A good solution to what?

Anything. Is there any case you can dream up where you think, for
example, that using YUI or jQuery or Prototype is a good decision? Or
do you think it's always, universally a bad choice?

Whenever such a library exactly matched the application it was to be
put to, with nothing superfluous or wasteful in context.

Why is it important to not have waste?

Matt Kruse

 

[Richard Cornford]

That is quite a bias to begin with. I see no reason why arguments
in favor of a library must be things that can only be achieved
with a library.

Yes, in retrospect that position is too extreme. An argument in favour
of libraries might also be something that is favourable but could be
achieved in a number of ways but where the library was objectively the
best way of achieving it.

Remember the question that drove this branch of the thread. We have a
situation where there is a fair sized group of individuals who have
browser scripting expertise but do not spend their time creating general
purpose javascript libraries, and evidence that the individuals who are
working on general purpose javascript libraries don't know enough to
avoid demonstrating an ignorance of the language they are using. If the
a-priori assumption that creating general purpose libraries is an
optimum strategy is a valid assumption then the status quo warrants some
explanation, as it would be an otherwise unexpected situation. On the
other hand, if the assumption is invalid, so and creating general
purpose libraries is actually a manifestation of a novice mistake, then
the status quo is an understandable (even inevitable) outcome. We were
asked why the current situation pertains, and so a rigorous examination
of the assumption seems like a reasonable step toward answering that
question.

Rather, a library is one way to gain the benefits that I
listed.

If you want to drive a nail into a piece of wood using a rock is one way
of doing so. But being able to do it that way is hardly an argument in
favour of using rocks for the task.

Given a very specific context, a library may or not be
the best choice in a given situation.

And if you only had a rock to drive your nails then using a rock becomes
the best choice for driving nails.

So I think you're starting out with a ridiculous set of
criteria with which to judge the suitability of a
'library' approach.

You still did not present any arguments for libraries being the best way
achieving the things you listed.

I think you should rather consider the possible benefits of a
using a library, then consider the cons, and decide if overall
it is a good choice.

I can consider those things. Achieving optimum outcomes for web projects
though informed design decision making is the panicle of the browser
scripting skill-set. But one of your arguments in favour of libraries is
that they allow individuals who don't have the necessary skills to do
jobs that they re not qualified to for. So how do they then apply the
knowledge they don't have to the decisions they must make?

If you consider all the factors, I find it hard to believe
that you think using a library is _never_ the best choice.

Did I ever say that could never be the case?

That does not require a library.

Of course not, but using a library is one way to accomplish
the goal.

But being one way to do something is not actually an argument in favour
of doing it in that particular way.
^^^^^^^
Should have been "wasteful".

Why so? If I have an internal webapp used by 10 people on a LAN, do
you really think that an extra 50k of js code on a page is of any
concern to to me?

Over the years I have repeatedly been impressed by our capacity for not
being concerned.

So we have an internal web app being used by 10 individuals? How many
browsers does that involve? It must be ten or fewer, and realistically
it is likely to be just one or two, and those will likely be IE 6 or 7
and Firefox or Safari. At which point the need for "normalizing browser
behaviour" has almost despaired. The standard DOM API is going to be
good enough for 95% of what is likely to be needed in context.

In some contexts, this may be a con. Not in all.


Not at all. "Standard" doesn't have to mean that it covers all cases.

To be regarded as "a 'standard' API" there has to be only one, and if
there is only one it has to accommodate all that is asked of it, which
is "Normalizing browser behaviour, to the greatest extent possible" in
this context.

Just that it is the API used regularly in most cases. A
"standard" API can put restrictions on its applicability,
as well. There are plenty of "standard" API's out there
that don't handle every possible use case.

Where an API is not all encompassing it still covers every possible use
case, because their own restrictions define "possible" for them.

You appear to be backing away form "greatest extent possible", where
"greatest extent possible" is the requirement that separates the
alternatives for "normalizing browser behavior" from the general purpose
library approach.

Of course not. But it is one benefit of a library.

You have made no case for that here. The possible advantages of putting
a layer over commonly used complexity are independent of that layer
possibly featuring in a library, and so cannot be "one benefit of a
library".

And we also see plenty of examples where libraries have put layers of
ridiculous complexity over commonly used internal simplicity. Dojo, for
example, has an IFRAME creation method that tests and branches all aver
the place (with a different browser being the - else - case in each
branch) despite there being a 'one code fits all' method of creating and
inserting IFRAMEs that works fine with the 3 or 4 browsers dojo is
interested in. Or that javascript code insertion function from JQuery,
where three possible branches may be taken and the author has not seen
that if the final branch works at all it would work with all the
browsers that have taken either of the other two branches.

Wrapping a layer around internal complexity is one thing, having that
layer needlessly multiply the internal complexity is something else
entirely.

The lack of expertise in an area has never been much of a
concern for businesses in the past.

Bullshit (particularly the "never").

It just means you have to be more creative in
solving the problem.

No amount of creativity is going to turn someone who does not know how
to do it into an architect capable of designing and overseeing the
building of a skyscraper. In reality there are only a very limited
number of fields where you can get away with not knowing what you are
doing, and that still does not make attempting to do so a good idea.

If every company needed to be an expert in every
area of work they did, surely there would be few
successful companies.

Doesn't that pre-suppose that companies that are successful do not have
expertise in the fields where they operate? If your assumption that
"lack of expertise in an area has never been much of a concern for
businesses" is not valid then the existence of successful companies does
not speak for endemic ignorance and incompetence in business.

The fact is, sometimes you need to do the best you
can with the resources you have. To expect anything
else is truly naive.

There is never a choice but do the best you can with the resources
available, except maybe doing less than you could with the resources
available. But in practice systems are usually not so closed that the
resources available are fixed. It is certainly not unreasonable to take
the position that if something cannot be sensibly achieved without
particular resources then it is only rational to acquire those
resources.

Of course not, but it is one approach.

But not the best approach (particularly where the authors of that
re-used code don't know the language they are using to write the code).

And yet they do so,

Yes, the less experienced will make worse mistakes than the more
experienced, even when the 'more experienced' are not really that
experienced.

and their work is used by thousands of people on
thousands of successful web sites around the world.
If they don't know enough to write javascript, how
do you account for their success?

The generally low standard of the completion (or the absence of direct
completion) would be sufficient explanation.

Surely if their work was horrible it would have been
exposed by now and

Do you really regard, for example, Google groups as not having been
exposed by now? We know Google groups is programmed by a mass of
incompetent jellies who are totally out of their depth.

the free market of information would have found a better
replacement, no?

Not necessarily. If there was a better alternative then Google groups
would suffer from it, but who has the long term Usenet archives that
would be necessary to compete?

4. A single library js file can be used on many pages
throughout a web site or webapp, and the reasonable
assumption is that browsers will cache the source.

[snip]
And there are no shortage of examples where people are
including entire libraries in web pages to do ridiculously
trivial tasks.

Which is part of my argument - if you include jquery.js on
every page, for example, some pages may use it heavily while
others use it only for a line or two.

And there you start with an "if". The example I cited did not include
any indication that there were any other pages involved at all, let
alone that they would be likely to be subject to more complex scripted
manipulation.

But once it's cached, it doesn't even matter.
You can use it for just 2 lines if you want to on a
page without worrying because it doesn't require a big
additional download.

Downloading is not the only issue. Once loaded the script code still
needs to be complied into an executable form before it can be used.

Anything. Is there any case you can dream up where you think,
for example, that using YUI or jQuery or Prototype is a good
decision? Or do you think it's always, universally a bad choice?

You are forgetting what YUI is. It is an application framework for a
fairly larger search engine. In the event of working for a fairly large
search engine and needing an application framework it is extremely
likely to be pretty much 100% fit for the task, and so make not using it
an extremely questionable thing to be doing.

Prototype.js, on the other hand, is just a streaming pile of excrement,
and so fundamentally poorly designed that it could never be 'fixed'
(beyond its just being deleted) so there are no circumstances where I
could envision using that.

Why is it important to not have waste?

Download speed, loading and complying speed, runtime execution speed,
reliability relating to complexity, management/maintenance and QA costs
relating to complexity, management/maintenance costs relating to code
bulk. KISS is too good a principle to be abandoned just because it is
one option.

Richard.