I've been reading the recent posts and older archives of
comp.lang.javascript and am surprised by the sentiments expressed about
the prototype.js library for a few reasons:

1) The library has been referred to as "junk" many times which is a
strong opinion against the relatively high popularity of the library. I
know popularity doesn't make something good.

2) People who use it are advised to "get a minimal clue". (Paraphrased.
Search archives "prototype.js minimal".)

3) Those who criticize so strongly must believe they know better but
the posts I saw containing the criticism did not indicate why the
library is so bad.

I have used the prototype.js library a bit with a mixed experience.

I had very little success with the Enumerable iterators. Constant
problems. They make for code that is bulky enough to match the size of
a JavaScript for loop. In Ruby these types of methods are great but I
don't think they work so well in JavaScript the way prototype.js
implements them.

I have enjoyed using the event parts of prototype.js without any
problems or even reading any of the code. It's usually the goal of a
library to make it so the user doesn't have to know the library's
internals. I'll count this as a success for prototype.js. However,
after reading such criticisms I decided to look at the code just in
case I got lucky so far. It turns out that for my application I was
able to take only about 90 lines of prototype.js's 1800 lines. These
lines are below. I've read them now. They seem ok to me. I would like
to know if anyone thinks this is a weak part of the prototype.js
library and why? Particularly comments regarding the browser
incompatibility workarounds as well as overcoming the IE problems of
the "this" keyword and bubbling (discussed on
http://www.quirksmode.org/js/events_advanced.html).

One thing I wish was that prototype.js used a namespace (discussed
http://blog.dreamprojections.com/archive/2004/12/27/450.aspx). This
would mean the code that uses the library would not look quite so cool
since it would not be possible to extend Event, Function, String, etc.

What do you like or dislike about prototype.js? Any reasons why
prototype.js is "junk"?

I think a critical discussion of this library would be very educational
for many people. I know that I am trying to "get a minimal clue".

Thanks,
Peter

// ------------------------------------------------------------

Function.prototype.bindAsEventListener = function(object) {
  var __method = this;
  return function(event) {
    return __method.call(object, event || window.event);
  }

  for (var i = 0; i < arguments.length; i++) {
    var element = arguments[i];
    if (typeof element == 'string')
      element = document.getElementById(element);

    if (arguments.length == 1)
      return element;

    elements.push(element);
  }

  return elements;

Event.element = function(event) {
    return event.target || event.srcElement;

Event._observeAndCache = function(element, name, observer, useCapture)
{
  if (!this.observers) this.observers = new Array();
  if (element.addEventListener) {
    this.observers.push([element, name, observer, useCapture]);
    element.addEventListener(name, observer, useCapture);
  } else if (element.attachEvent) {
    this.observers.push([element, name, observer, useCapture]);
    element.attachEvent('on' + name, observer);
  }

  if (name == 'keypress' &&
      (navigator.appVersion.match(/Konqueror|Safari|KHTML/)
      || element.attachEvent))
    name = 'keydown';

  this._observeAndCache(element, name, observer, useCapture);

  if (name == 'keypress' &&
      (navigator.appVersion.match(/Konqueror|Safari|KHTML/)
      || element.detachEvent))
    name = 'keydown';

  if (element.removeEventListener) {
    element.removeEventListener(name, observer, useCapture);
  } else if (element.detachEvent) {
    element.detachEvent('on' + name, observer);
  }

Lack of feature detection - it assumes a lot about what the UA does or
doesn't support without testing for it.

Lack of technical support - That one is obvious from the amount of posts
seen here asking questions about it. You don't see a lot of questions
about Matt Kruse's libraries here (especially compared to prototype.js)
because Matt supports his libraries.

It is a big monolithic do-everything solve-every-problem approach to
scripting, and in most cases it's over-kill.

In an environment like this group where many 'experts' are of the opinion
that libraries are bad and that everyone should become a javascript expert,
you can imagine why such a big library approach is looked down upon.

HTH

- The most accessible features of the prototype library are shortcut
functions. I can see why people want to abstract away feature detection
and calls like document.getElementById if you use them much, but being
a Java programmer by day, I value readability quite highly. Functions
like $H, $A, and even $ are cute, but only readable by the initiated.
Some of the shortcuts seem to be there just because they can. Compare
 Form.getElements("myform")
to
 document.forms["myform"].elements
Saving seven characters is not excuse enough for changing a known idiom
to a proprietary shorthand.

- Size! I too am against monolithic libraries. If the different features
could be extracted and used independently, you could compile your own
library with just what your site needs. From what little I have seen,
the features of prototype.js are depending on each other so much that
separating them is non-trivial, i.e., not something a simple user can
do.
The size of version 1.4.0 is 47445 bytes. That takes 10+ seconds on
a 28.8K modem, which is far too much.

- The class creation features have confused me before. A lot of action
seems to be happening in a slightly non-standard way, where again only
someone familiar with the framework has any chance of reading the
result. That said, I think the library has simplified somewhat since
then (or people have stopped trying to do everything in a roundabout
way), and the examples I see now are much more readable.

- It extends Array.prototype. That means that you can't do
    for (var i in myArray) { ... }
to iterate over the assigned elements of a sparse array without
getting unexpected indices like "each" and "all". This is simply
bad citizenship, since it can break other Javascript functions
unrelated to prototype. This would be a deal breaker for me.
I'm not alone, shows Google:
 <URL:http://blog.metawrap.com/blog/WhyIDontUseThePrototypejsJavaScriptLibr...>
It appears version 1.4 doesn't extend Object.prototype any more,
which is good, but Array.prototype is still heavily modified.

All in all, it seems to me that prototype.js is maturing and does have
some useful additions, but it tries to be a framework, not a library,
and that hinders readability and maintainability for people not familiar
with it.

I also find that much of the preference for ajax libs comes from personal
style. What seems logical to one person seems awkward to another. When I
wrote mine, I first wrote code to implement a page with ajax functionality.
I wrote the calls how I wanted to use it, then wrote the lib that acted on
the methods. So the interface to the functionality felt right to me. Others
have said the same. But of course, not everyone thinks the same way!

Some methods/function appear to offer very little, e.g. $() doesn't do
any feature detection or offer any fall back for older browsers.  If I
really want a bunch of element references in an array I can write my own
function with very little effort.

The other big problem is that the author publishes it without any
documentation or comments.  No doubt the response is 'the code is the
best documentation' but to me that is laziness or lack of confidence -
the author doesn't want to say what it should do or why it does it for
fear of being wrong or highlighting an error.

Or maybe some Picasso-esque fear of being understood too clearly and
therefore trivialised.  Who knows?

The result is that it is very hard to determine whether it is 'working'
correctly or not, it just does what it does.  The various attempts I've
seen at documenting it (discovered via Google) don't help at all.

Thanks for the insiteful replies. The ideas mentioned here will
definitely help me build a better JavaScript library framework for my
project with small modular chunks that can be read by any JavaScript
programmer. I think I have something very cool cooking for libraries in
general and a user interface widgets library in specific.