Why not prototype.js?

[Chad Burggraf]

Hi all,

I'm brand new to this newsgroup. I've been reading the FAQ's and some
other documentation submitted by regulars of the group (such as
"Javascript Best Practices" at
http://www.javascripttoolbox.com/bestpractices/#prototype) and am
discovering that there is general distaste for prototype.js.

In my first post to this group I recommended a fix that happened to use
some functions from the prototype.js library. I may now be regretting
that post, however I would like to understand people's discontent first.

The main issues people have seem to be with the lack of author-provided
documentation and the extension of Object.prototype.

First, I've found the source to be very readable. The wiki has provided
answers to anything else I've needed. It'd maybe be nice to have some
more formal documentation, but is that a reason not to use it?

Second, the concept of extending any object's prototype is one of the
main beauties of the language! And I'm sorry, but adding two functions
to Object (and hence everything derived from Object) doesn't seem a very
big deal to me.

I actually don't feel defensive about prototype.js or any library or way
of doing something. I'm mostly just curious about this impression that
I've gotten. Please don't let me start a war, simple insight into your
reasoning would suffice.

Cheers
Chad

 

[Peter Michaux]

Hi Chad,

I'm brand new to this newsgroup. I've been reading the FAQ's and some
other documentation submitted by regulars of the group (such as
"Javascript Best Practices" at
http://www.javascripttoolbox.com/bestpractices/#prototype)

The first four out of five points on Matt's website are no longer valid
or strong enough to include as criticism, in my opinion. There is
official Prototype.js support but not from the author. The community
seems to be more serious about documentation. They don't augment
Object.prototype anymore and I don't think Prototype.js forces
class-based OOP but that would be an acceptable feature and part of the
package if someone wants to use Prototype.js. I've emailed Matt twice
about this but he must not be interested in updating that document.
There are plenty of criticisms of Prototype still available.

In my first post to this group I recommended a fix that happened to use
some functions from the prototype.js library. I may now be regretting
that post, however I would like to understand people's discontent first.

The code quality is low is the biggest complaint. On the rails-spinoffs
mailing list it was recently discussed that in a couple places in
Prototype.js the order that properties are added to an object matters
when those properties are read back out.

<URL:
http://groups.google.com/group/rubyonrails-spinoffs/msg/37644786727dd7ac>

This is just one example and people respond by saying "submit a patch"
but if this level of code quality is throughout the library I think it
is an indicator to look elsewhere for JavaScript. Also patches have a
history of sitting on the Rails trac for a very long time although this
may have changed slightly in recent times.

Another big complaint it the lack of need for sugar which requires a
large file download and an extra layer of learning for developers
joining a project using Prototype.js. JavaScript is already a capable
language. It isn't low level like writing in Assembly. Sure JavaScript
may not be the language of choice of many developers but it is the
language in browsers so go with the flow and just program JavaScript
Why add a very slow layer of sugar on top?

Second, the concept of extending any object's prototype is one of the
main beauties of the language! And I'm sorry, but adding two functions
to Object (and hence everything derived from Object) doesn't seem a very
big deal to me.

The newer releases of Prototype.js do not augment Object.prototype.
Doing so breaks for-in loops

<URL: http://erik.eae.net/archives/2005/06/06/22.13.54/>

Peter

 

[ron.h.hall]

Hi Chad,


or strong enough to include as criticism, in my opinion.

And the third point on Matt's website has never been valid. Citing an
abject failure on the part of a language as a reason not to use any
form of mitigation is, in my opinion, at best, bizarre. That said, I
know little if anything about prototype.js, and as such this represents
nothing in regard to recommendation.

.../rh

 

[Randy Webb]

(e-mail address removed) said the following on 12/31/2006 11:11 PM:

And the third point on Matt's website has never been valid.

<quote>
It modifies Object.prototype, so all objects contain additional
properties. This causes problems when iterating through object properties
</quote>

What part of that "has never been valid"? Everything in that paragraph
is true.

Citing an abject failure on the part of a language as a reason not to use any
form of mitigation is, in my opinion, at best, bizarre.

The failure isn't due to anything in the language though, the failure
comes about when prototype.js modified Object.prototype. Now granted,
that isn't true anymore, but to say it has never been true is, well, false.

 

[RobG]

Hi all,

I'm brand new to this newsgroup. I've been reading the FAQ's and some
other documentation submitted by regulars of the group (such as
"Javascript Best Practices" at
http://www.javascripttoolbox.com/bestpractices/#prototype) and am
discovering that there is general distaste for prototype.js.

Prototype.js is written solely to make life easier for programmers, it
doesn't add anything for users, therefore it should be judeged on its
technical merit.

My primary dislikes are that it doesn't seem to care about performance
- there are places where you'd think it was written deliberately to be
slow - and it requires you to learn an almost entirely different way of
programming.

There are a few things to like, but not enough for me to make it
worthwhile using.

[...]

The main issues people have seem to be with the lack of author-provided
documentation

As Peter said, the Rails community is fixing that, though strictly it
still isn't from the author so while moot, the point is still valid. A
more valid point is that there is no comprehensive programmers guide to
tell you where the gotchas are, e.g.

1. The getInputs method sometimes it returns an Array, other times a
NodeList.
2. The 'visible' method only tells you if an element's style attribute
is 'display:none', not whether the element is actually visible or not.
3. In places there are serial calls to $() that have a marked effect
on performance.
4. Form.Element.Methods.serialize uses getElementsByTagName to get
elements from within a form, results are arranged in an order that is
almost certainly different from the actual HTML order. It has been
used by some to create and submit form-less forms, thought that won't
work in version 1.5 which continues to use getElementsByTagName, but
only within the scope of a form element.

There are many others.

and the extension of Object.prototype.

Version 1.5 doesn't extent Object anymore, probably because now
Prototype.js itself uses for..in and realised what a pain it is.

First, I've found the source to be very readable. The wiki has provided
answers to anything else I've needed. It'd maybe be nice to have some
more formal documentation, but is that a reason not to use it?

*A* reason, though not not sufficient on its own.

Second, the concept of extending any object's prototype is one of the
main beauties of the language! And I'm sorry, but adding two functions
to Object (and hence everything derived from Object) doesn't seem a very
big deal to me.

The point isn't that you should *never* extend built-in objects, but
that you shouldn't do it globally in a library without serious
consideration of the consequences. One of the consequences for
Prototype.js (which continues to extend other built-in and host
objects) is that it increases the likelihood that it won't play well
with other libraries.

I actually don't feel defensive about prototype.js or any library or way
of doing something. I'm mostly just curious about this impression that
I've gotten. Please don't let me start a war, simple insight into your
reasoning would suffice.

I think some of the animosity is caused by suggesting Prototype.js as a
solution to what may well be a simple scripting error or
misunderstanding. Such suggestions don't solve the real problem.

 

[Chad Burggraf]

All -

I appreciate the responses. There definitely are many quirks and bugs in
Prototype.js, and I would agree that this is an important reason not to
use it. The version sitting on the few production sites I've built with
it does extend Object.prototype, but like I said before I don't really
have a problem with that.

As far as code quality: my biggest complaint is that Prototype seems
obsessed with Ruby. I don't really understand the need to make
JavaScript, which has a very widely-understood C-like syntax, feel more
like Ruby. On the other hand, adding extensions like Enumeration for
short collections and Function.bind for readable closures has been a
godsend for me. Actually, those are the main two reasons I use the
library (and of course syntax shortcuts, although they would be very
simple to create on my own).

It is large, and some parts of it are slow. I suppose I could hack some
of the concepts apart and grow my own library from the pieces I use most
often, but I'm trying to be more library-friendly. I like the idea of it
being well-tested (even if it's not compared to a library like YUI) and
consistent.

Anyway, thanks again for being kind and insightful.

Cheers
Chad

 

[ron.h.hall]

(e-mail address removed) said the following on 12/31/2006 11:11 PM:

It modifies Object.prototype, so all objects contain additional
properties. This causes problems when iterating through object properties
</quote>

What part of that "has never been valid"? Everything in that paragraph
is true.

You've taken me too literally. The "valid" referred to use as a reason
not to do something, as intended to be implied by the sentence that
followed (Not that my use of the English language doesn't warrant
improvement).

The failure isn't due to anything in the language though, the failure
comes about when prototype.js modified Object.prototype. Now granted,
that isn't true anymore, but to say it has never been true is, well, false.

And there we differ. What you're saying is that a fundamental feature
of the language should not be used, at least not in global scope,
because it results in a problem which largely is one of inconvenience,
whereby for(...in...) loops require a filter to weed out undesirable
inheritance.

Is there really any difference in programming for the environment in
this way, versus using object detection to obtain and ensure
functionality in a multi-browser world? Regardless, if the language had
permitted some discretion with regard to enumerability of properties,
an Object prototype could be installed and used without causing any
interference with for(...in...), any more than toString does.

The for(...in...) problem (inconvenience) is often cited as the reason
not to use Object.prototype. However, the potential for property name
conflict, is really the more serious matter, in my view. But there are
also ways within the language of minimizing or eliminating that,
depending on how far one is willing to go.

The recommendation not to use Object.prototype is likely a good one, in
general. Nonetheless, I don't think it should be held out as a "never
do this" commandment.

../rh

 

[Randy Webb]

(e-mail address removed) said the following on 1/1/2007 2:38 PM:

You've taken me too literally. The "valid" referred to use as a reason
not to do something, as intended to be implied by the sentence that
followed (Not that my use of the English language doesn't warrant
improvement).

Yes, I misunderstood what you were saying and I actually agree with what
you are saying (that I misunderstood to start with). The
misunderstanding on my part comes from reading too many of JRS' posts
where you have to read every single word very literal or he becomes
pedantic and tells you to learn to read plain English.

And there we differ. What you're saying is that a fundamental feature
of the language should not be used, at least not in global scope,
because it results in a problem which largely is one of inconvenience,
whereby for(...in...) loops require a filter to weed out undesirable
inheritance.

I have never had a problem with for(...in...) but I don't use it very
often and I think I have extended the prototype one time in almost 10
years of JS Coding so I wouldn't have a problem with it.

The recommendation not to use Object.prototype is likely a good one, in
general. Nonetheless, I don't think it should be held out as a "never
do this" commandment.

I have stopped saying "Don't use prototype" and have adopted the "Use
whatever you want". My major problem with prototype.js is people use it
(which is a choice they made) but when they have problems with it
instead of going to the author (or a group dedicated to prototype
issues) they come here and want the people here to debug prototype.

 

[Matt Kruse]

The first four out of five points on Matt's website are no longer
valid or strong enough to include as criticism, in my opinion. There
is official Prototype.js support but not from the author.

That, IMO, is still a problem.

The community seems to be more serious about documentation.

Why would the author of a popular library not take the time to write some
documentation?

They don't
augment Object.prototype anymore

Many people still use previous versions of prototype, and previous versions
are often bundled with other libraries/scripts.

and I don't think Prototype.js forces
class-based OOP but that would be an acceptable feature and part of
the package if someone wants to use Prototype.js.

"Force" is probably a bad word. It encourages an OO approach that kind of
bastardizes the js language. This causes new js developers who get exposed
to prototype early on to be unable to write "plain vanilla" js without the
framework provided by prototype.

I've emailed Matt
twice about this but he must not be interested in updating that
document.

It's been partially updated in my local copy. I've got a lot of other things
to do.

There are plenty of criticisms of Prototype still available.

I'm always open to more points being raised, or if enough of a defense is
raised, removing that point from the Best Practices document entirely.