Prototype - Good/Bad/Why?

[timothytoe]

have you worked out which post you are
replying to yet?

No, could you please help me with that?

 

[timothytoe]

Who wants to be coddled in a technical discussion group?

Not I. If only there were some possible middle ground between coddling
and eviscerating.

 

[Peter Michaux]

Perhaps the library writers could be more easily convinced to see
things the correct way if insults were not the default form of
greeting on clj.

I agree. The critics could word their criticism in a more friendly way
but perhaps that would remove the sense of conviction they feel. The
criticized could also simply ignore the emotionally charged language
and take the criticism as for what it is: a statement about a piece of
code. It takes both sides to fuel the flames. It is so simple to get
along with folks in this group that I'm amazed those claiming social
graces cannot do it. Odd, eh?

Peter

 

[Richard Cornford]

No, could you please help me with that?

OK. You are using Google groups so you start off with a huge disadvantage
because all of its defaults are now geared toward Google's own web forums
rather than Usenet. Web forums tend to be linear and all new posts are
effectively just appended to a list. Usenet is 'threaded', which means that
discussions are tree-like in form. A discussion starts with a posted message
(know as the OP (for Original Post, though OP is also used to refer to the
Original Poster (the individual who makes the original post))), any number
of people may reply that OP and each reply can be subject to other replies,
thus each reply to the OP potentially becomes a branch in the tree structure
of the thread (though it may end up being a leaf if it does not get
responded to).

Most of the people who regularly use the group are doing so through
dedicated news servers (provided by their ISPs or as commercial service by
third parties (the days of free public news servers seem to have gone)) and
are using 'newsreader' software that is geared to presenting Usenet in its
threaded form.

This is not to say that Google groups interface cannot show Usenet in its
threaded form. Go to a discussion listing and click on the word 'Options' at
the right end of the grey bar that contains the subject to expand some
'links' that provide display options. One of those options is labelled "View
as tree", and clicking it shows Google's best effort at a tree display of
the thread. That should make things clearer.

It is also a good idea to also use the 'fixed font' option because ascii art
and various common text highlighting strategies rely upon the reader using a
fixed width font, as otherwise there is no telling how wide the reader's
characters (especially spaces) are. Also, avoid using tabs to indent code
(use (possibly multiple) spaces instead) because the display capabilities
and defaults of newsreaders when handling tabs varies enormously.

If you want to see the mechanism behind Usenet threading use the "more
options" 'link' at the top of each message and click the "Show original"
option. This shows the individual message with its headers (though google
always mangle everything that looks like an e-mail address). Not that each
message has a Message-ID header that uniquely identifies the message, and a
References header that describes its context in the tree of the thread by
listing the chain of Message-ID from the original post at the beginning to
the message that the current message is responding to at the end.

While you are there note that a Content-Type header should exist and specify
"text/plain". Usenet is normally (and comp.lang.javascript always) a plain
text medium (no HTML posts, mixed content posts or attachments here). That
explains why you don't need PRE elements in order to retain text formatting,
and why <i>xxx</i> doesn't work. There are Usenet conventions for
*emphasis*, _underline_ and /stress/ in plain text messages.

While you are in the 'options' at the top of each message, to the far left
is a 'Reply' option that has historically been the most effective at
providing the previous message body in a quoted form and replying
effectively to the specific message. There have been many (often extended)
periods when the similar link at the bottom of the message has either failed
to reply to the specific message or not provide the previous message in
quoted form. Remember that Google's javascript developers (and particularly
the ones working on google groups) are quite astoundingly bad, so you can
consider yourself lucky if anything works properly/consistently over any
period of time. Despite that you will be held responsible for what you post,
so keep your eyes open for when google f**k-up, because they will (and
blaming them will not get you very far).

In that context, be particularly cautions of google's habit of inserting
statements like "Show quoted text" into the material they present as a
'quote' of the pervasions message. The accuracy of any quotes you post are
your responsibility. You may edit the irrelevant/superfluous (appropriately
marking such edits so there is no doubt about what you have done) but you
must not change the wording of whatever you do quite and you certainly must
not add anything because that would be (literally or by implication) putting
words into other people's moths and be disingenuous at the very least.
Remember, it is no good blaming google, you are 100% responsible for
everything _you_ post.

There is a conventional/traditional form for Usenet posts. You can find out
more about this through the group's FAQ (hint: it is in the faq notes). We
expect to see that form followed here. The reasoning goes; A well
formed/complete Usenet post requires a little discipline, while browser
scripting requires a lot of discipline, so an individual who cannot
demonstrate the former is going to be a hopeless case with regard to the
latter. That may seem harsh and a little arbitrary but experience has not
invalidated it.

Richard.

 

[timothytoe]

OK. You are using Google groups so you start off with a huge disadvantage
because all of its defaults are now geared toward Google's own web forums
rather than Usenet. Web forums tend to be linear and all new posts are
effectively just appended to a list. Usenet is 'threaded', which means that
discussions are tree-like in form. A discussion starts with a posted message
(know as the OP (for Original Post, though OP is also used to refer to the
Original Poster (the individual who makes the original post))), any number
of people may reply that OP and each reply can be subject to other replies,
thus each reply to the OP potentially becomes a branch in the tree structure
of the thread (though it may end up being a leaf if it does not get
responded to).

Most of the people who regularly use the group are doing so through
dedicated news servers (provided by their ISPs or as commercial service by
third parties (the days of free public news servers seem to have gone)) and
are using 'newsreader' software that is geared to presenting Usenet in its
threaded form.

This is not to say that Google groups interface cannot show Usenet in its
threaded form. Go to a discussion listing and click on the word 'Options' at
the right end of the grey bar that contains the subject to expand some
'links' that provide display options. One of those options is labelled "View
as tree", and clicking it shows Google's best effort at a tree display of
the thread. That should make things clearer.

It is also a good idea to also use the 'fixed font' option because ascii art
and various common text highlighting strategies rely upon the reader using a
fixed width font, as otherwise there is no telling how wide the reader's
characters (especially spaces) are. Also, avoid using tabs to indent code
(use (possibly multiple) spaces instead) because the display capabilities
and defaults of newsreaders when handling tabs varies enormously.

If you want to see the mechanism behind Usenet threading use the "more
options" 'link' at the top of each message and click the "Show original"
option. This shows the individual message with its headers (though google
always mangle everything that looks like an e-mail address). Not that each
message has a Message-ID header that uniquely identifies the message, and a
References header that describes its context in the tree of the thread by
listing the chain of Message-ID from the original post at the beginning to
the message that the current message is responding to at the end.

While you are there note that a Content-Type header should exist and specify
"text/plain". Usenet is normally (and comp.lang.javascript always) a plain
text medium (no HTML posts, mixed content posts or attachments here). That
explains why you don't need PRE elements in order to retain text formatting,
and why <i>xxx</i> doesn't work. There are Usenet conventions for
*emphasis*, _underline_ and /stress/ in plain text messages.

While you are in the 'options' at the top of each message, to the far left
is a 'Reply' option that has historically been the most effective at
providing the previous message body in a quoted form and replying
effectively to the specific message. There have been many (often extended)
periods when the similar link at the bottom of the message has either failed
to reply to the specific message or not provide the previous message in
quoted form. Remember that Google's javascript developers (and particularly
the ones working on google groups) are quite astoundingly bad, so you can
consider yourself lucky if anything works properly/consistently over any
period of time. Despite that you will be held responsible for what you post,
so keep your eyes open for when google f**k-up, because they will (and
blaming them will not get you very far).

In that context, be particularly cautions of google's habit of inserting
statements like "Show quoted text" into the material they present as a
'quote' of the pervasions message. The accuracy of any quotes you post are
your responsibility. You may edit the irrelevant/superfluous (appropriately
marking such edits so there is no doubt about what you have done) but you
must not change the wording of whatever you do quite and you certainly must
not add anything because that would be (literally or by implication) putting
words into other people's moths and be disingenuous at the very least.
Remember, it is no good blaming google, you are 100% responsible for
everything _you_ post.

There is a conventional/traditional form for Usenet posts. You can find out
more about this through the group's FAQ (hint: it is in the faq notes). We
expect to see that form followed here. The reasoning goes; A well
formed/complete Usenet post requires a little discipline, while browser
scripting requires a lot of discipline, so an individual who cannot
demonstrate the former is going to be a hopeless case with regard to the
latter. That may seem harsh and a little arbitrary but experience has not
invalidated it.

Richard.

Ah, I see. Some of you are still reading on Usenet. I've not done it
that way for a few years. I understand the confusion now. Makes
perfect sense. Thanks.

 

[RobG]

On Feb 16, 5:55 pm, "Richard Cornford" <[email protected]>
wrote: [...]

Richard.

Ah, I see. Some of you are still reading on Usenet. I've not done it
that way for a few years. I understand the confusion now. Makes
perfect sense. Thanks.

Other things that Google Groups (GG) does badly are:

1. Not automatically trim signatures

2. Remove the trailing space from "-- " which signifies
the start of a signature so that news readers can't find the
signature either.

I use a minimal signature when posting via GG to help attenuate issues
arising from that.

 

[Richard Cornford]

On Feb 16, 5:55 pm, Richard Cornford wrote:

Ah, I see.

"Said the blind man ... "

Some of you are still reading on Usenet.

If you are reading this then you are reading Usenet. There is no "some"
about it.

I've not done it that way for a few years. I understand
the confusion now. Makes perfect sense. Thanks.

Your are not scoring that well yet.

"Could do better" ;-)

Richard.
--
"Since the use of JavaScript in nonbrowser settings (e.g., server-side
JavaScript) is still rather experimental, the feature set of JavaScript is
still very browser-centric. Thus, the features available in JavaScript are
very closely tied to how browsers evolve and which features they (or their
users) deem as the most important." - John Resig: Pro JavaScript Techniques.
2006

 

[Richard Cornford]

Until a clj Nazi codes a "correct" library with the capabilities
of jQuery or Prototype or YUI, those libraries will be continue
to be used to make websites. And probably to an acccelerating
degree.

I agree that browser-sniffing is about as appealing as
anus-sniffing, but programmers in the real-world sometimes need
to actually get things done. A smart programmer (as opposed to
a perfection-seeking zealot} will go with the flow and be able
to throw together a website quickly as a result.

If you go back 5 or 6 years there is (or was) a "real world" practice that
had pretty much all of the characteristics that we see paraded before us in
favour of the otherwise objectively and demonstrably bad library code.

That practice was using the - eval - function to retrieve object references
using runtime assembles string representations of dot notation property
accessors. It had everything you might want; there were literally millions
of examples in use on the Internet, including on all of the sites of all of
the often-listed "major players" and in the majority of the 'popular
libraries' of the time. It worked, it got the job done and it allowed people
with a limited understanding of javascript to throw together web sites that
they would not have been able to create otherwise. (Indeed in relation to
browser sniffing it also has the advantages of a formal technical
justification and actually being reliable). It worked just fine then, it
works today, and it is going to still work tomorrow.

It is gone now. You don't see it being done in anything but the very oldest
code, and you don't see anyone recommending it as a practice any more. Why
is that? Could it be that somewhere there were people who could recognise a
bad idea when they observed it? People who were not interested in following
the crowd or accepting the "a million monkeys can't be wrong" argument.
Perfectionist zealots who kept on saying "this is stupidly inefficient",
"this is totally unnecessary" and "you should be doing this instead" until
eventually enough people understood the folly sufficiently for its
prorogation to cease and for the practice to die out.

Did you go and look at the "Why should I eschew prototype.js?" thread I
referred to? Did you see the code I highlighted there demonstrating that the
author of the (at the time) latest version of Prototype.js did not
understand how the code he was writing worked, and had ended up with
something that, where it worked at all, worked only by coincidence? It is
not a subjective question, and it is not a matter of opinion, it is in the
code for all to see; Prototype.js was written by people who don't understand
javascript. They don't understand its theory and they don't comprehend its
reality. Now if, knowing that, someone still thinks it is going to be a good
idea to use Prototype.js then more fool them, I cannot stop them. But that
is not a reason for me to stop telling it like it is.

Have you looked at the John Resig material I have been quoting today? Have
you seen the common theme?

Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way
for programmers to ensure future work.

Professionalism? Did you actually ask the client how they feel about your
design strategy?

Richard.

 

[Peter Michaux]

I agree that browser-sniffing is about as appealing as anus-sniffing,
but programmers in the real-world sometimes need to actually get
things done. A smart programmer (as opposed to a perfection-seeking
zealot} will go with the flow and be able to throw together a website
quickly as a result. Sure, the website will be brittle, and users with
obscure browsers will whine, but that's not a bad way for programmers
to ensure future work.

Or perhaps no work at all.

Peter

 

[David Mark]

If you go back 5 or 6 years there is (or was) a "real world" practice that
had pretty much all of the characteristics that we see paraded before us in
favour of the otherwise objectively and demonstrably bad library code.

That practice was using the - eval - function to retrieve object references
using runtime assembles string representations of dot notation property
accessors. It had everything you might want; there were literally millions
of examples in use on the Internet, including on all of the sites of all of
the often-listed "major players" and in the majority of the 'popular
libraries' of the time. It worked, it got the job done and it allowed people
with a limited understanding of javascript to throw together web sites that
they would not have been able to create otherwise. (Indeed in relation to
browser sniffing it also has the advantages of a formal technical
justification and actually being reliable). It worked just fine then, it
works today, and it is going to still work tomorrow.

That one must have passed me by.

It is gone now. You don't see it being done in anything but the very oldest
code, and you don't see anyone recommending it as a practice any more. Why
is that? Could it be that somewhere there were people who could recognise a
bad idea when they observed it? People who were not interested in following
the crowd or accepting the "a million monkeys can't be wrong" argument.
Perfectionist zealots who kept on saying "this is stupidly inefficient",
"this is totally unnecessary" and "you should be doing this instead" until
eventually enough people understood the folly sufficiently for its
prorogation to cease and for the practice to die out.

Let us hope the same happens to Prototype, jQuery, etc. It looks like
IE8 is going to help out quite a bit in this regard.

Did you go and look at the "Why should I eschew prototype.js?" thread I
referred to? Did you see the code I highlighted there demonstrating that the
author of the (at the time) latest version of Prototype.js did not
understand how the code he was writing worked, and had ended up with
something that, where it worked at all, worked only by coincidence? It is

Yes, the nested function declarations in that example should be enough
to convince people that the million monkeys behind it haven't got a
Shakespeare among them.

You would think that an open source project with so many eyes on it
would be relatively free of such obvious gaffes. Wasn't the number of
watchful contributors involved a recent argument posed in favor of
using jQuery? IIRC, that was right before it came to light that after
two plus years, not one of them had spotted the typeof xyz == 'array'
goof, even after the function in question had been posted (twice) in a
thread involving the original author (who was too busy being snotty to
read is own cited code.) I don't think we heard from him again, until
he dropped by to ineffectually ridicule one of your signatures.

not a subjective question, and it is not a matter of opinion, it is in the

That didn't stop several participants from attempting argue in favor
of the code in question. The fact that they didn't understand the
issues with it provided no barrier to entry for them and the clarity
of your position was ultimately muddied. I figure that many who read
that thread will get lost in the maze of replies and assume that it
really was just a matter of opinion.

code for all to see; Prototype.js was written by people who don't understand
javascript. They don't understand its theory and they don't comprehend its
reality. Now if, knowing that, someone still thinks it is going to be a good
idea to use Prototype.js then more fool them, I cannot stop them. But that
is not a reason for me to stop telling it like it is.

And you shouldn't. It isn't just their personal choice. It affects
everyone who browses the Web. It seems like every time I try to
reference anything on the Internet these days, my progress is impeded
by script errors, aborted popup windows, browser freezes, botched
validation logic, malformed layouts (my favorite is the in-page popup
with a single off-screen close button that can't be scrolled to),
inefficient keypress listeners (takes ten years to type ten letters),
broken back buttons, etc., etc. Disabling scripting is almost never
an answer as most of these Ajax nuts are convinced that they don't
need to design for that eventuality. Granted, these issues cannot all
be laid at Prototype's doorstep, but they illustrate the obvious fact
that people who don't understand browser scripting should not be
charged with writing interactive Web pages (or God forbid Web
applications.) Piling on a 100K of incompetently written script does
not help, but typically makes things worse.

Have you looked at the John Resig material I have been quoting today? Have

Yes. LOL. You've got to be cruel to kind.

you seen the common theme?
Ignorance?


Professionalism? Did you actually ask the client how they feel about your
design strategy?

Yeah, right. Assuming a client exists (poor them), I doubt they would
be happy with such a nefarious strategy. And what is this
undercurrent of anger toward people who use "obscure browsers" (read:
handheld devices) or disable scripting? Is everything that goes wrong
with incompetently designed sites the fault of the user? Same for
those who point out problems with the libraries. As much as the
authors and proponents of the major libraries like to talk about
reality, they sure get antsy when someone pokes holes in their
blinders.

Richard.

I assume the "Jim Jey" attribute is a typo, but of course, the
original author of the quote misspelled "Richard Cornford." LOL.

 

[Peter Michaux]

Peter Michaux said the following on 2/16/2008 4:47 PM:



Fine by me. See my other reply. Somebody writes a Prototype entry and
the group wants it in the FAQ, I will add it

How about just a few links to some of these long Prototype threads
rather than trying to get an agreement on an actual critic?

Peter

 

[Peter Michaux]

Peter Michaux said the following on 2/17/2008 1:57 AM:



Adding an entry isn't a big deal. It just a few lines pasted into a
file. The rest is automated. As for whether it should be in there or
not, let me see if I can find the thread where it was talked about last
time.

<FAQENTRY>

What are some of the problems with general purpose javascript libraries?

The consensus of regular posters in comp.lang.javascript hold the view
that most, if not all, general purpose libraries are of a sufficient

"mainstream, downloadable general purpose"?

lack of quality as to make them useless in a cross-browser environment.
These are a few of the discussions that have taken place in the past
about libraries available for general public use:

Prototype.js:
<URL here>
<URL here>
<URL here>

YUI:
<URL here>
<URL here>

Mootools:
<URL here>
<URL here>

Etc..

That is a start.

I think it is close enough to the group regular's general feeling. I
don't particularly agree with the social skills displayed in the
threads to be linked but they sure do express the sentiment of the
most vocal regulars.

I haven't been following your RFC threads lately, anything FAQ related
in them?

I don't think so. Some interesting minutia about cross-browser testing
host objects and the ECMAScript spec. I know you really like that
stuff.

Peter

 

[Peter Michaux]

Peter Michaux said the following on 2/17/2008 2:30 AM:



I think that implies, or might, that non-mainstream libraries don't
suffer many of the problems that mainstream libraries do.

Well, if it isn't right, we can be sure Dr Stockton will mention it to
you soon and frequently.

You going to volunteer to hunt and weed out the threads for links?

I can find some.

You know me too well

I think that Matt's libraries should be included as well if there are
any threads where they are discussed. From what I have seen though, when
Matt finds out about a problem with one of his, he tries to correct it.

Matt did mention in one of the recent, colossal jQuery threads that he
uses jQuery at work and doesn't have much time for his own code
anymore. I don't know if he is keeping up to date.

I don't think Matt's library should be mentioned because it is not a
frequently asked question. Also there is not a consensus that Matt's
library is bad (actually it is probably the contrary) so I wouldn't
want to imply anything about his code.

Peter

 

[Peter Michaux]

Peter Michaux said the following on 2/17/2008 2:30 AM:


Well, if it isn't right, we can be sure Dr Stockton will mention it to
you soon and frequently.



I can find some.

I didn't say I was going to spend my life compiling them all.

These are ones I remember and all involve regulars and the general
opinions in the group. In some of the threads more than one library is
mentioned but I've grouped by the library that took the hardest hit.

Prototype
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/181f03af63cc81c2
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/2072e63631688fc4

jQuery
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/415949d1bcce6e6a

YUI
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/fefce445673d7135
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/37c2a1b93d566b74

Peter

 

[dhtml]

Peter Michaux said the following on 2/17/2008 2:30 AM:


Well, if it isn't right, we can be sure Dr Stockton will mention it to
you soon and frequently.



I can find some.




Matt did mention in one of the recent, colossal jQuery threads that he
uses jQuery at work and doesn't have much time for his own code
anymore. I don't know if he is keeping up to date.

I don't think any library should be endorsed. Or condemned. Matt's
library does not appear to be maintained.

Is there a bug count that, say, Prototype exceeds, yet Javascript
toolbox doesn't?

Which library should I use?

would be a good FAQEntry.

It could cover a range of things from: What are your needs/what are
you trying to accomplish? Or all or none of the following:

Library: jQuery :
overview: <BLAH>
pro: small, simple API
con: oversimplified; code behind methods is complicated, difficult
to test
<UNBIASED EXAMPLE>
known bugs /issues: <UNBIASED EXAMPLE>
highlights:

Then the reader can make his onw decision.

Pick Popular libraries that getasked about frequently. EXT, YUI,

 

[Lasse Reichstein Nielsen]

But why do they get better so slowly when so many people are using
them and apparently reading the code? Browser scripting topics like
feature detection have been known for a long time and there are many
well known tests; however, the mainstream libraries opt for
navigator.userAgent frequently.

According to the author of JQuery there are cases where it's the only
thing that "works". You can't test for rendeing bugs by feature detection.
You can have browsers that implement a feature so badly that you must
avoid it, even if feature detection detects it.

There is no easy way to make two pieces of crap compatible
/L

 

[Lasse Reichstein Nielsen]

No, that is an imagined utopia, where there are only three or four
agents to consider and user agent strings are meaningful.

No, that's the real world, where people don't care if it works in
anything but IE and Mozilla, and are happy if it also works in
Safari, Opera and Konqueror too. That real world, which is nowhere
near the utopia where everybody writes web pages that work in all
browsers.

/L

 

[Richard Cornford]

According to the author of JQuery there are cases where it's
the only thing that "works".

While looking through the source code of various libraries (JQery include) I
keep encountering comments that assert weird and incredible things about web
browsers. Things that I either know to be false or things that, if they were
true, would have been raised here long ago (30,000 posts a year for more
than ten years) and so I would know the truth of. None of these comments
every go into details and most are immediately followed by a crazy user
agent string driven set of branching. My impression is that these are
manifestations of misconceptions in circumstances where the author does not
have the experience or analytical skills to move from observing a symptom in
their code to understanding the real cause and effect relationships behind
it.

Thus when I hear "According to the author of ... " I am going to take that
with a large pinch of salt. It is showing the code that demonstrates a
phenomenon that proves the truth of any such claim (or reveals the
misconceptions behind it).

You can't test for rendeing bugs by feature
detection.

You can't test for all rendering bugs (probably most), but scripts do have
access to some information about the web page as it is actually displayed
and so can apply some testing to that.

You can have browsers that implement a feature so badly
that you must avoid it, even if feature detection detects it.

And you can design to avoid issues. While you were away (and its good to see
you back there were long discussions about an - isFunction - method from
JQuery, which in tern was significant because it was employed by a method in
JQuery that attempted to implement a sort of 'method overloading' where it
was passed host object references in some contexts and user defined function
references in others. The problem came when it encountered the first of the
many browsers where collections are implemented as functions (are callable
and have =- typeof - equal to 'function'). The parade of misconceptions and
assumptions that lead to this position ended in attempts to make an -
isFunction - test that 'did what we want' rather than having any
relationship with any aspect of what a function is or what a function does.
But that was all just (mostly unsuccessful) hacking to get round an
underlying but avoidable design mistake; the 'method overloading' emulation
was not a good idea in the circumstances (and usually isn't). If that
direction had never been taken the browser sniffing in the hacks necessary
to get the - isFunction - test to do what was needed of it would not have
been necessary.

There is no easy way to make two pieces of crap compatible

Yes, but remember that JQuery only works with the default configurations of
3 or 4 browsers.

Richard.

 

[Peter Michaux]

According to the author of JQuery there are cases where it's the only
thing that "works". You can't test for rendeing bugs by feature detection.
You can have browsers that implement a feature so badly that you must
avoid it, even if feature detection detects it.

I think that is a cop out to justify giving up looking for a better
test.

There is no easy way to make two pieces of crap compatible

True. It isn't always easy and we have to do it for many more than
just two!

Peter

 

[John G Harris]

putting
words into other people's moths

<snip>

I like it

John