By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,864 Members | 1,727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,864 IT Pros & Developers. It's quick & easy.

prototype.js criticism

P: n/a
Hi,

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/arc...2/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);
}
};

function $() {
var elements = new Array();

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.stop = function(event) {
if (event.preventDefault) {
event.preventDefault();
event.stopPropagation();
} else {
event.returnValue = false;
event.cancelBubble = true;
}
};

Event.observers = false;

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);
}
};

Event.unloadCache = function() {
if (!Event.observers) return;
for (var i = 0; i < Event.observers.length; i++) {
Event.stopObserving.apply(this, Event.observers[i]);
Event.observers[i][0] = null;
}
Event.observers = false;
};

Event.observe = function(element, name, observer, useCapture) {
var element = $(element);
useCapture = useCapture || false;

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

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

Event.stopObserving = function(element, name, observer, useCapture) {
var element = $(element);
useCapture = useCapture || false;

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);
}
};

/* prevent memory leaks in IE */
Event.observe(window, 'unload', Event.unloadCache, false);

Mar 20 '06 #1
Share this Question
Share on Google+
12 Replies


P: n/a
pe**********@gmail.com said the following on 3/20/2006 2:26 AM:
Hi,

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.
eval is popular also :) But, as you said, popularity doesn't make
something good.
2) People who use it are advised to "get a minimal clue". (Paraphrased.
Search archives "prototype.js minimal".)
The only person I recall using that phrase is Thomas and I won't comment
on that part of it.
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.


First, I am not a big fan of libraries to start with. They have there
place but I don't care for them. But the major problem, to me, with
prototype.js is two-fold:

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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 20 '06 #2

P: n/a
pe**********@gmail.com wrote:
It turns out that for my application I was
able to take only about 90 lines of prototype.js's 1800 lines.


And that right there is one of the big criticisms of prototype.js.

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.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Mar 20 '06 #3

P: n/a
pe**********@gmail.com wrote:
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".


Search the archives.
HTH

PointedEars
Mar 20 '06 #4

P: n/a
Matt Kruse wrote:
pe**********@gmail.com wrote:
It turns out that for my application I was
able to take only about 90 lines of prototype.js's 1800 lines.
And that right there is one of the big criticisms of prototype.js.

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


That is one point.
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.


That is not a point at all for me. On closer observation, you will
recognize that I use and provide many script libraries myself. I will
probably use and provide a script library for XMLHTTP requests in the
near future.
PointedEars
Mar 20 '06 #5

P: n/a
pe**********@gmail.com writes:
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.
Some people seem to need to vent their opinions in public. Without
further arguments, it's just noise, since it doesn't help you evaluate
whether the expressed opinion is one you can agree with, or just
unfounded rambling.
2) People who use it are advised to "get a minimal clue". (Paraphrased.
Search archives "prototype.js minimal".)
See 1.
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.
See 1.
I have used the prototype.js library a bit with a mixed experience. .... What do you like or dislike about prototype.js? Any reasons why
prototype.js is "junk"?


I haven't even used it, so I am not in a position to unqualified call
it junk. I have my reasons for not using it, which might be misguided
ones, but I have yet to see something contradict them :)

- 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/WhyIDontUseThePrototypejsJavaScriptLibrary.aspx>
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.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 20 '06 #6

P: n/a
Thomas 'PointedEars' Lahn wrote:
I will
probably use and provide a script library for XMLHTTP requests in the
near future.


Why? One of the 10,000 out there already didn't quite do what you want? :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Mar 20 '06 #7

P: n/a
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
I will probably use and provide a script library for XMLHTTP requests in
the near future.


Why? One of the 10,000 out there already didn't quite do what you want? :)


Probably not. I have yet to review Sarissa, though.
PointedEars
Mar 20 '06 #8

P: n/a
Thomas 'PointedEars' Lahn wrote:
Why? One of the 10,000 out there already didn't quite do what you
want? :)

Probably not. I have yet to review Sarissa, though.


What is it that you want, exactly?
My lib does purely js-side stuff. I'd be curious to know what it doesn't do
that you'd be looking for.

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!

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Mar 20 '06 #9

P: n/a
Matt Kruse wrote:
Thomas 'PointedEars' Lahn wrote:
Why? One of the 10,000 out there already didn't quite do what you
want? :)

Probably not. I have yet to review Sarissa, though.


What is it that you want, exactly?
My lib does purely js-side stuff. I'd be curious to know what it doesn't
do that you'd be looking for.


I have not reviewed your library either, since I have no need for XMLHTTP
requests for the time being. If I discover something in the process that
is not possible when using your library, rest assured you will be the first
one to know.
PointedEars
Mar 20 '06 #10

P: n/a
pe**********@gmail.com said on 20/03/2006 5:26 PM AEST:
Hi,

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

2) People who use it are advised to "get a minimal clue". (Paraphrased.
Search archives "prototype.js minimal".)
That is one opinion, only got 2 hits when searched. Even 'prototype.js
junk' only got 3 unique hits.

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.


A thorough evaluation of 1700 lines of code with 230 (or so) functions
would take quite some time. The main issues are the size of the
library, difficulty of abstracting parts of it to reduce bloat, changes
to in-built objects and obfuscation - what does $('blah') mean to the
uninitiated?

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.
--
Rob
Mar 21 '06 #11

P: n/a
RobG wrote:
pe**********@gmail.com said on 20/03/2006 5:26 PM AEST:
[Why is Prototype.js considered junk?]

[...]
The main issues are [...] obfuscation - what does $('blah') mean to the
uninitiated?

Some methods/function appear to offer very little, e.g. $() doesn't do
any feature detection or offer any fall back for older browsers. [...]


The `$' identifier being used for not machine-generated code is also
disregarding ECMAScript Ed. 3 identifier recommendations, as Richard
pointed out shortly ago.
PointedEars
Mar 21 '06 #12

P: n/a
Hi 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.

Peter

Mar 21 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.