Prototype - Good/Bad/Why?

30 views
Skip to first unread message

ashore

unread,
Feb 15, 2008, 4:53:29 PM2/15/08
to
Guys, I see a fair bit of negativity around re subject package. Can
someone share your views, either way?

Thanks,

AS

David Mark

unread,
Feb 15, 2008, 5:36:24 PM2/15/08
to

Prototype - very bad.

It relies on browser sniffing in lieu of proper feature detection and
testing.

It works (sort of) in a limited set of modern browsers.

It is too large and the design isn't modular.

It is horribly inefficient. Even the lowest level code is tangled up
in syntactic sugar.

It augments host objects, most notably in the (unfortunately named) $
function.

It fails to leverage the inherent power of the JS language, instead
trying to force it to work like a class-based language.

Search the group for more details. Alternatively, read the comments
in the Rails Trac or related blogs.

dhtml

unread,
Feb 15, 2008, 9:36:23 PM2/15/08
to

What goes on behind the scenes in Prototype? Some of the syntactic
sugaring is inefficient. It also makes code that uses prototype
require all of prototype, which is now a lot of code. Object Oriented
and non-modular.

The $super approach caused problems with compressors:
http://www5.sys-con.com/read/464826.htm

In fact, YUI compressor has apparently some logic to account for this.
(according to the README).

What do YOU think?

Randy Webb

unread,
Feb 15, 2008, 10:09:23 PM2/15/08
to
ashore said the following on 2/15/2008 4:53 PM:

> Guys, I see a fair bit of negativity around re subject package. Can
> someone share your views, either way?

Richard Cornford said it better than anybody else I have ever seen write
it and Thomas Lahn uses it in a signature:

Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300d...@news.demon.co.uk>

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

David Mark

unread,
Feb 15, 2008, 10:42:47 PM2/15/08
to
On Feb 15, 9:36 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>
> > > Guys, I see a fair bit of negativity around re subject package.  Can
> > > someone share your views, either way?
>
> > > Thanks,
>
> > > AS
>
> > Prototype - very bad.
>
> > It relies on browser sniffing in lieu of proper feature detection and
> > testing.
>
> > It works (sort of) in a limited set of modern browsers.
>
> > It is too large and the design isn't modular.
>
> > It is horribly inefficient.  Even the lowest level code is tangled up
> > in syntactic sugar.
>
> > It augments host objects, most notably in the (unfortunately named) $
> > function.
>
> > It fails to leverage the inherent power of the JS language, instead
> > trying to force it to work like a class-based language.
>
> > Search the group for more details.  Alternatively, read the comments
> > in the Rails Trac or related blogs.
>
> What goes on behind the scenes in Prototype? Some of the syntactic

From what I have read of it, nothing good. Like other (currently)
popular libraries, much of its decision-making is based on browser
sniffing and particularly susceptible to the myriad IE imitators out
there. Treating a non-IE agent as IE is clearly a recipe for
disaster. The authors of such libraries live in a dream world where
such agents don't exist.

I recently stumbled across the change log for the event handling code
and was amused to see that it cannot handle mousewheel events for the
handful of browsers it claims to support without several sniff-and-
branch operations. Such profound incompetence is on display
throughout the code. The accompanying comments to the seemingly
constant changes indicate that the developers haven't got a clue what
they are doing. How long until the maze of browser sniffing logic
outweighs the code that does actual work?

> sugaring is inefficient. It also makes code that uses prototype
> require all of prototype, which is now a lot of code. Object Oriented
> and non-modular.

Exactly. It is all-or-nothing. Developers are advised to choose
nothing.

>
> The $super approach caused problems with compressors:http://www5.sys-con.com/read/464826.htm

I wasn't aware of that one. One of the benefits of not using
Prototype (or the like) is that you don't have to keep up with the bug
reports.

>
> In fact, YUI compressor has apparently some logic to account for this.
> (according to the README).

I highly recommend the YUI "compressor" (misnomer), but certainly not
YUI itself. It is a better script than Prototype, but shares many of
the same problems (e.g. browser sniffing, too much sugar, etc.) Then
there is that ridiculous "namespace."

>
> What do YOU think?

ME? I think I have made that abundantly clear. The only thing worse
than Prototype is jQuery. YUI is slightly better, but still well
south of competent. Using any of these libraries (or God forbid
combinations of them) is a bad idea. The average Web developer can
achieve lousy results on their own, so what is the benefit of adding
100K of third-party incompetence to the mix?

Randy Webb

unread,
Feb 16, 2008, 12:50:44 AM2/16/08
to
David Mark said the following on 2/15/2008 10:42 PM:

<snip>

> The average Web developer can achieve lousy results on
> their own, so what is the benefit of adding 100K of
> third-party incompetence to the mix?

Incompetence and peer pressure. Not knowing better and because
"everybody" is using it.

David Mark

unread,
Feb 16, 2008, 1:17:14 AM2/16/08
to
On Feb 16, 12:50 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
> David Mark said the following on 2/15/2008 10:42 PM:
>
> <snip>
>
> > The average Web developer can achieve lousy results on
> > their own, so what is the benefit of adding 100K of
> > third-party incompetence to the mix?
>
> Incompetence and peer pressure. Not knowing better and because
> "everybody" is using it.
>

It sometimes seems like "everybody" is doing it. What I can't
understand is why huge corporations would put their faith in trash
like Prototripe/Craptaculous (typically to add a few nifty fade
effects.) Can't they afford to pay competent developers? On the
server side, most appear to believe that .NET is the answer. If so,
what was the question?

From what I have read about IE8 (specifically the new versioning meta
tag), all of the libraries that rely on IE-sniffing are in for a rude
awakening. Will the authors finally see the folly of their ways or
will they add more branching based on the content of the meta tag?

Peter Michaux

unread,
Feb 16, 2008, 1:23:34 AM2/16/08
to
On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
> Guys, I see a fair bit of negativity around re subject package. Can
> someone share your views, either way?

<FAQENTRY>

Shouldn't something about Prototype be in the FAQ? It comes up very
frequently.

Peter

David Mark

unread,
Feb 16, 2008, 1:49:55 AM2/16/08
to

I propose a two word entry: mostly harmful.
And for jQuery: completely worthless.

dhtml

unread,
Feb 16, 2008, 7:01:32 AM2/16/08
to
On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 15, 9:36 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
>
>
> > On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>


> I highly recommend the YUI "compressor" (misnomer), but certainly not
> YUI itself.

Me too. But why 'misnomer'? It reduces the file size pretty well.

 It is a better script than Prototype, but shares many of
> the same problems (e.g. browser sniffing, too much sugar, etc.)  Then
> there is that ridiculous "namespace."
>

Namespacing seemed stupid to me, at first. I mean, these aren't
"packages", they're just objects.

In fact, it confused the junior devs. Check out this example:

YAHOO.namespace("YAHOO.mst.scheduler");

YAHOO.mst.scheduler = function() { ... }

It's entirely possible to do this; to reassing a "package" to a
function (or any value, or delete it). It's not safe. But neither are
prototypes.

extend(Sub, Super);
Sub.prototype = { }; // <- Developer Mistake, just reassinged
prototype.

extend(Sub, Super, mixin); // <- corrected.

On the other hand, enforcing namespacing has made my code more
modular. Keeping the global namespace clean is just a small benefit.

If I didn't use packages and a build system, unit testing would be a
lot harder.

Writing a library is a lot of work. I want to write a better one. This
includes:
modular desing.
minimal framework.
building things as simple as possible, but not any simpler.
unit testing.
code review.

Now that last one, I could probably use a lot of help on.

>
>
> > What do YOU think?
>
That was meant for the OP. I'm not sure why this thread was brought up
even. If s/he's really considering Prototype, he could have done a web
search, or searched this group. (but I can't search Groups in FF
again; it's only FF now).


> ME?  I think I have made that abundantly clear.  

You have.


The only thing worse
> than Prototype is jQuery.  YUI is slightly better, but still well
> south of competent.  Using any of these libraries (or God forbid
> combinations of them) is a bad idea.  The average Web developer can
> achieve lousy results on their own, so what is the benefit of adding
> 100K of third-party incompetence to the mix?

Most of the F/E jobs here in the bay area want someone who has one of
the following:
Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
fake it good enough), you can make decent money.

Richard Cornford

unread,
Feb 16, 2008, 9:10:24 AM2/16/08
to
dhtml wrote:
> On Feb 15, 7:42 pm, David Mark wrote:
>> On Feb 15, 9:36 pm, dhtml wrote:
>>> On Feb 15, 2:36 pm, David Mark wrote:
>>>> On Feb 15, 4:53 pm, ashore wrote:
<snip>

> It's entirely possible to do this; to reassing a "package"
> to a function (or any value, or delete it). It's not safe.
> But neither are prototypes.

Javascript is a dynamic language where it is possible to write code that
will 'mess up' pretty much any other code. Nothing is "safe", there are just
varying degrees to which it is easy for programmer to break an existing
system. In the end it is the programmer's responsibility not to be doing
things wrongly, and that is going to be best achieved by understanding the
task in hand, the system it is to be done in/with and the environment(s) in
which it will operate.

<snip>


> On the other hand, enforcing namespacing has made my code
> more modular. Keeping the global namespace clean is just
> a small benefit.

If 'namespacing' were the only way of making code modular then that would
act as a justification for them, but they are not. Which leaves the only
relevant namspace-modularity relationship being a demonstration that they
may be either 'the best method' for achieving modularity or a 'good' method
in some sense or under some circumstances.

<snip>


> Writing a library is a lot of work.
> I want to write a better one.

Remember to decide what precisely your library if for before even starting
to design it. Browser scripting has many contexts of application and trying
to create something that attempts to be all things to all people is pretty
much guaranteed to have a result that falls short of all.

> This includes:
> modular desing.
> minimal framework.
> building things as simple as possible, but not any simpler.
> unit testing.
> code review.
>
> Now that last one, I could probably use a lot of help on.

It is still probably the easiest because all you have to do is post code
here in a readable/understandable form (along with an explanation of what it
is for) and its shortcomings will be pointed out.

My thoughts on the majority of current libraries is that they have been
bought into existence while their authors were experiencing the first flush
of superficial success in browser scripting (the stage where you start to be
able to create things that will work on more than two browsers and then gain
the false impression that you have the problem cracked) and then rushed
before a public hungry for such things. This has the effect of pretty much
freezing the libraries API (and its approach and the implied code authoring
style). The problem being that the authors don't see (because they don't
have the experience to see) that they have made fundamentally flawed design
decisions, and then the freezing of the API that follows from its being used
in the wider world removes any future hope of the overall design being
corrected (even if the authors are willing/ capable of recognising their
mistakes (and the current set seems to include many who have personalities
that are extremely resistant to the very idea that they may have done
anything wrong)).

Generally people who can recognise and learn from their mistakes will do
things better a second time and better yet a third.

<snip>


> Most of the F/E jobs here in the bay area want someone who has
> one of the following:
> Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
> (of fake it good enough), you can make decent money.

This is also the trend in job advertisements in the UK, but not for the jobs
with the "decent money" (though our perceptions of "decent money" may
differ). It probably should not be taken too seriously, as the people doing
the recruiting don't tend to know what they need but have to write
something. It is like all the web development jobs where knowing Dreamweaver
was part of the requirement, regardless of the fact that the odds would be
that someone who knew Dreamweaver well would then not have any actual
technical understanding of web development at all.

Richard.
--
"Even if you're not completely familiar with XML, you will get great
satisfaction knowing that all HTML documents (which are, in the eyes of the
browser, XML documents) have a DOM representation that is ready to use." -
John Resig: Pro JavaScript Techniques. 2006


Richard Cornford

unread,
Feb 16, 2008, 9:10:13 AM2/16/08
to
Randy Webb wrote:
> ashore said the following on 2/15/2008 4:53 PM:
>> Guys, I see a fair bit of negativity around re subject
>> package. Can someone share your views, either way?
>
> Richard Cornford said it better than anybody else I have
> ever seen write it and Thomas Lahn uses it in a signature:
>
> Prototype.js was written by people who don't know javascript
> for people who don't know javascript. People who don't know
> javascript are not the best source of advice on designing
> systems that use javascript.
> -- Richard Cornford, cljs, ...
<snip>

To be fair, I did not write that as a criticism of Prototype.js as such. I
wrote it as a comment on the worth of taking the advice of people who use
Prototype.js (advice which is usually that others should also use
Prototype.js).

Of course the comment was justified, and I certainly demonstrated technical
justification of my "by people who don't know javascript" in the thread with
the subject "Why should I eschew prototype.js?" (which started with
Message-ID: < 1194882268.2...@v3g2000hsg.googlegroups.com >).

Richard.
--
"Since valid HTML is simply a subset of XML, having an efficient way to
parse and browser DOM documents is an absolutely essential for making
JavaScript development easier." - John Resig: Pro JavaScript Techniques.
2006


dhtml

unread,
Feb 16, 2008, 1:18:43 PM2/16/08
to
On Feb 16, 6:10 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> dhtml wrote:
> > On Feb 15, 7:42 pm, David Mark wrote:
> >> On Feb 15, 9:36 pm, dhtml wrote:
> >>> On Feb 15, 2:36 pm, David Mark wrote:
> >>>> On Feb 15, 4:53 pm, ashore wrote:
> <snip>
> > It's entirely possible to do this; to reassing a "package"
> > to a function (or any value, or delete it). It's not safe.
> > But neither are prototypes.
>
> Javascript is a dynamic language where it is possible to write code that
> will 'mess up' pretty much any other code. Nothing is "safe", there are just
> varying degrees to which it is easy for programmer to break an existing
> system. In the end it is the programmer's responsibility not to be doing
> things wrongly, and that is going to be best achieved by understanding the
> task in hand, the system it is to be done in/with and the environment(s) in
> which it will operate.
>
Yep.
[snip]

> <snip>
>
> > On the other hand, enforcing namespacing has made my code
> > more modular. Keeping the global namespace clean is just
> > a small benefit.
>

[sip]

> > code review.
>
> > Now that last one, I could probably use a lot of help on.
>
> It is still probably the easiest because all you have to do is post code
> here in a readable/understandable form (along with an explanation of what it
> is for) and its shortcomings will be pointed out.
>

Thread coming.

> My thoughts on the majority of current libraries is that they have been
> bought into existence while their authors were experiencing the first flush
> of superficial success in browser scripting (the stage where you start to be
> able to create things that will work on more than two browsers and then gain
> the false impression that you have the problem cracked) and then rushed
> before a public hungry for such things.

Well there;s plenty of mistakes to learn from, then.

This has the effect of pretty much
> freezing the libraries API (and its approach and the implied code authoring
> style).

That's what I see with YAHOO. They can't change some broken core parts
of the library, like YAHOO.hasOwnProperty, augmentObject, et c.

With so many dependencies, how can they change?


The problem being that the authors don't see (because they don't
> have the experience to see) that they have made fundamentally flawed design
> decisions, and then the freezing of the API that follows from its being used
> in the wider world removes any future hope of the overall design being
> corrected (even if the authors are willing/ capable of recognising their
> mistakes (and the current set seems to include many who have personalities
> that are extremely resistant to the very idea that they may have done
> anything wrong)).
>
> Generally people who can recognise and learn from their mistakes will do
> things better a second time and better yet a third.
>
> <snip>
>
> > Most of the F/E jobs here in the bay area want someone who has
> > one of the following:
> > Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that
> > (of fake it good enough), you can make decent money.
>
> This is also the trend in job advertisements in the UK, but not for the jobs
> with the "decent money" (though our perceptions of "decent money" may
> differ). It probably should not be taken too seriously, as the people doing
> the recruiting don't tend to know what they need but have to write
> something. It is like all the web development jobs where knowing Dreamweaver
> was part of the requirement, regardless of the fact that the odds would be
> that someone who knew Dreamweaver well would then not have any actual
> technical understanding of web development at all.
>

It's not just recruiters. Not many javascript experts out there.

One case is the company adopts a library. Often, they're B/E devs (or
tech leads w/o F/E experience). They want a library that's easy to
understand and does what they need.

Another case is a F/E dev will promote the library he likes to his
company, or the team will pick a library. As the team grows, they hire
other developers who know the same tools.

Hype can be a big influence.

Contract jobs such as these vay in pay range, depending on desparation
(Urgent: Must get 'Ajax' guru). They pay from USD 40-90+/hr. or 70-150k
+/yr. (in the Bay area).

Garrett

> Richard.

timothytoe

unread,
Feb 16, 2008, 2:29:46 PM2/16/08
to
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. 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.

If my site is cobbled together in jQuery, guess what I'm going to look
for on a FE resume. I need another guy who knows jQuery, so he can
read and debug the crappy code I wrote, and create new crappy code
that I can read and debug. I want someone who knows the jQuery plug-
ins, not some guy that'll come in and write a bunch of new untested
tab systems, tablesorters, Canvas charting systems, modal dialogs, and
tool-tips. If my new programmer quits because he hates the music I
play, or because we have a dangerous-looking homeless guy outside who
regularly threatens his life and throws half-eaten mayonnaise-and-
cheese sandwiches at him every time he walks to his car at night, I'm
going to look for <i>another</i> jQuery programmer to replace him.

And don't underestimate the impact of these libraries on the makers of
browsers. As jQuery shows up in more and more sites, will Microsoft
really want to be seen as releasing an IE8 that is "broken" and
"sucks?" I predict that Microsoft will endeavor to not break jQuery,
Prototype, and YUI sites. Already, people are starting to base their
ideas of "browser speed" on the CSS and XPath selector timings from
various libraries, and upon Javascript performance. It's not just the
speed of layout that counts now. I bet Microsoft will actually
accommodate these libraries so that IE has a little bit less
embarrassing showing in the benchmarks. Do you think it's coincidence
that Microsoft is trying to pass acid tests?

By all means, point out the flaws in the libraries. But if you know
how to write a better library, perhaps spend some of your time
building a better mousetrap and a little less time flapping your
mouthtrap.

It's all changed out from under you. The libraries are THE major force
in Web 2.0 development now. jQuery is in (I believe) Rails now, and
Drupal, and AIR. You may have disdain for them, but it's a quixotic
(and mildly pathetically humorous) jihad you wage against them.

I'm not saying there is not a place for a by-the-books JS programmer
out there--there certainly is. But I think there are already more
places for a library-slinger and every month will bring more. It's
more helpful to council people of how to deal with the libraries than
avoid them.

Lasse Reichstein Nielsen

unread,
Feb 16, 2008, 3:47:30 PM2/16/08
to
timothytoe <timot...@gmail.com> writes:

> It's all changed out from under you. The libraries are THE major force
> in Web 2.0 development now. jQuery is in (I believe) Rails now, and
> Drupal, and AIR. You may have disdain for them, but it's a quixotic
> (and mildly pathetically humorous) jihad you wage against them.

It's expected behavior. DHTML+AJAX is a disruptive technology, and so
are the libraries that enable its use to mortals. The responses to it
fall neatly into the two expected categories: worship and disgust.

Sure, the libraries are not perfect, but they "get the job done" -
delivering results that are "good enough", and that get better with
every iteration.

Personally I would rather use GWT, but I like statically typed
languages :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

timothytoe

unread,
Feb 16, 2008, 3:56:16 PM2/16/08
to
>>It's expected behavior. DHTML+AJAX is a disruptive technology, and so are the libraries that enable its use to mortals. The responses to it fall neatly into the two expected categories: worship and disgust.

I see three: worship, disgust, and pragmatism.

I fall into the third category. I just can't bring myself to be either
worshipful of or disgusted by a tool that people use to get things
done. I reserve my worship for Jimi Hendrix and Picasso and my disgust
for tubgirl and goatse.

Peter Michaux

unread,
Feb 16, 2008, 3:59:06 PM2/16/08
to
On Feb 16, 12:47 pm, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:

> timothytoe <timothy...@gmail.com> writes:
> > It's all changed out from under you. The libraries are THE major force
> > in Web 2.0 development now. jQuery is in (I believe) Rails now, and
> > Drupal, and AIR. You may have disdain for them, but it's a quixotic
> > (and mildly pathetically humorous) jihad you wage against them.
>
> It's expected behavior. DHTML+AJAX is a disruptive technology, and so
> are the libraries that enable its use to mortals. The responses to it
> fall neatly into the two expected categories: worship and disgust.

I think the worshipers are the people who are glad to have someone
else worry about browser bugs. Then they can defer responsibility when
the boss questions about the support complaints.


> Sure, the libraries are not perfect, but they "get the job done" -
> delivering results that are "good enough", and that get better with
> every iteration.

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.

Peter

timothytoe

unread,
Feb 16, 2008, 4:06:40 PM2/16/08
to
>>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.

You'd have to hunt one of them down and make them answer to know, but
my assumption is not yours. You appear to assume that they are simply
sniffing to detect features. I assume they are sniffing to get around
browser JS or CSS bugs, or perhaps in some cases to improve
performance or to reduce the size of their often-transmitted
functions. In other words, they probably have reasons that have to do
with real-world trade-offs.

dhtml

unread,
Feb 16, 2008, 4:19:55 PM2/16/08
to
On Feb 15, 10:23 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>
> > Guys, I see a fair bit of negativity around re subject package. Can
> > someone share your views, either way?
>
> <FAQENTRY>
>

There shuold be an article about javascript API design. It should
ideally include an interview or forward by Brendan (long or brief).
This could be discussed by library authors and users of libraries.

> Shouldn't something about Prototype be in the FAQ? It comes up very
> frequently.

An FAQ Entry should be unbiased and informative. There could be a link
to some Prototype JS forums. This topic does come up a lot.

>
> Peter

timothytoe

unread,
Feb 16, 2008, 4:26:20 PM2/16/08
to
>>An FAQ Entry should be unbiased and informative...

Now that's a provocative idea!

dhtml

unread,
Feb 16, 2008, 4:32:43 PM2/16/08
to
On Feb 16, 11:29 am, timothytoe <timothy...@gmail.com> wrote:
> 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.
>
<snip blah>

> And don't underestimate the impact of these libraries

They do damage. They do this by relying on browser bugs, sniffing the
userAgent, and then patching it with a hack. What happens if the
browser is to fix the bug? Chris Wilson takes about IE trying to "not
break the web".


<snip blah>

Peter Michaux

unread,
Feb 16, 2008, 4:40:54 PM2/16/08
to

That right there is the most solid argument I've seen against hacking.
That is worth having in your sig line.

Peter

Peter Michaux

unread,
Feb 16, 2008, 4:47:29 PM2/16/08
to
On Feb 16, 1:19 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Feb 15, 10:23 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>
> > > Guys, I see a fair bit of negativity around re subject package. Can
> > > someone share your views, either way?
>
> > <FAQENTRY>
>
> There shuold be an article about javascript API design. It should
> ideally include an interview or forward by Brendan (long or brief).
> This could be discussed by library authors and users of libraries.

Richard Cornford had an interesting comment about Brendan Eich and
browser scripting. It is a bit uncomfortable to read...

<URL: http://groups.google.com/group/comp.lang.javascript/msg/49401dc958fba9fb>


> > Shouldn't something about Prototype be in the FAQ? It comes up very
> > frequently.
>
> An FAQ Entry should be unbiased and informative.

The contributors to this group have solid arguments why Prototype has
problems. Those would need to be pointed out or the FAQ answer would
not encapsulate the general opinions of the contributors. That is
really what the FAQ is for: to reduce typing the same thing over and
over again. If that is "biased" then the entry should be biased.

> There could be a link
> to some Prototype JS forums.

It should have that. It is a genuine frequent answer to "I'm having
trouble with Prototype..."

> This topic does come up a lot.

A lot.

Randy, what do you say? Is a FAQ entry acceptable?

Peter

John Resig

unread,
Feb 16, 2008, 4:54:31 PM2/16/08
to
> "Since valid HTML is simply a subset of XML, having an efficient way to
> parse and browser DOM documents is an absolutely essential for making
> JavaScript development easier." -JohnResig: Pro JavaScript Techniques.
> 2006

Oh, interesting - is book errata submitted via usenet sig these days?
http://apress.com/book/errata/275

To help you out the correct quote is:


"Since valid HTML is simply a subset of XML, having an efficient way
to

parse and browse DOM documents is absolutely essential for making
JavaScript development easier." (Chapter 1, Page 8)

--John

timothytoe

unread,
Feb 16, 2008, 4:58:49 PM2/16/08
to

On his aptly-named blog (Albatross!), Chris Wilson says, "standards
compliance and not breaking existing websites are, in fact, why I show
up to work."

The albatross around his neck is that buggy old browser, IE. We've
been living with Microsoft's buggy non-compliant slop for years and
years. Chris Wilson knows that's why he has to deal with the hard job
of not breaking websites that did ugly things to get around IE's ugly
things.

And yet he manages to do it with a positive attitude nothing like the
angry, bile-filled, childish vitriol that passes for acceptable
behavior in this group. Inspirational.

As he says, he has two jobs--working towards compliance and not
breaking the web. He performs his job cheerfully. He has a keen sense
of reality, knowing people are using what they have to to get their
jobs done. Good for him.

timothytoe

unread,
Feb 16, 2008, 5:06:54 PM2/16/08
to
>>The contributors to this group have solid arguments why Prototype has
problems. Those would need to be pointed out or the FAQ answer would
not encapsulate the general opinions of the contributors. That is
really what the FAQ is for: to reduce typing the same thing over and
over again. If that is "biased" then the entry should be biased.

It would be incredibly disappointing to me if the clj FAQ Entry for
Prototype failed to condense the supreme rage that occurs when that
library is mentioned into a hellishly hot and nasty black hole of snot.

dhtml

unread,
Feb 16, 2008, 5:10:13 PM2/16/08
to
On Feb 16, 1:58 pm, timothytoe <timothy...@gmail.com> wrote:
> On Feb 16, 1:40 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
>
>
> > On Feb 16, 1:32 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > On Feb 16, 11:29 am, timothytoe <timothy...@gmail.com> wrote:> 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.
>
> > > <snip blah>
>
> > > > And don't underestimate the impact of these libraries
>
>
> And yet he manages to do it with a positive attitude nothing like the
> angry, bile-filled, childish vitriol that passes for acceptable
> behavior in this group. Inspirational.
>

Childish behavior. Yeah, I know. Flame bait threads are the worst!

Peter Michaux

unread,
Feb 16, 2008, 5:11:46 PM2/16/08
to
On Feb 16, 1:58 pm, timothytoe <timothy...@gmail.com> wrote:

> nothing like the
> angry, bile-filled, childish vitriol that passes for acceptable
> behavior in this group. Inspirational.

I don't worry about how people behave here unless it is at the level
of racism. Really it is just the content (which is the best on the
internet) that is important to me and I can easily ignore a little
rudeness. The people that are rude often have a good point.

Peter

Richard Cornford

unread,
Feb 16, 2008, 5:13:58 PM2/16/08
to
On Feb 16, 9:54 pm, John Resig <jere...@gmail.com> wrote:
>> "Since valid HTML is simply a subset of XML, having an efficient
>> way to parse and browser DOM documents is an absolutely
>> essential for making JavaScript development easier."
>> -JohnResig: Pro JavaScript Techniques. 2006
>
> Oh, interesting - is book errata submitted via usenet sig these
> days?

It is not errata, the intention is humorous. Though I am not surprised
that you would not see the funny side.

> To help you out the correct quote is:
> "Since valid HTML is simply a subset of XML, having an
> efficient way to parse and browse DOM documents is absolutely
> essential for making JavaScript development easier." (Chapter
> 1, Page 8)

This would be "correct" in a sense I was not previously aware of.

Richard.
--
"Compression should be used as the final step, just before putting
your code into production, as your code will frequently become
obfuscated beyond recognition." - John Resig: Pro JavaScript
Techniques. 2006

David Mark

unread,
Feb 16, 2008, 5:14:25 PM2/16/08
to
On Feb 16, 7:01 am, dhtml <dhtmlkitc...@gmail.com> wrote:
> On Feb 15, 7:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Feb 15, 9:36 pm, dhtml <dhtmlkitc...@gmail.com> wrote:
>
> > > On Feb 15, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Feb 15, 4:53 pm, ashore <shor...@gmail.com> wrote:
>
> > I highly recommend the YUI "compressor" (misnomer), but certainly not
> > YUI itself.
>
> Me too. But why 'misnomer'? It reduces the file size pretty well.

It is a minifier/obfuscator. Compression is the final reduction that
is negotiated by the server and client.

>
>  It is a better script than Prototype, but shares many of> the same problems (e.g. browser sniffing, too much sugar, etc.)  Then
> > there is that ridiculous "namespace."
>
> Namespacing seemed stupid to me, at first. I mean, these aren't
> "packages", they're just objects.

One flat namespace is all that is required IMO. Its only purpose is
to keep the global namespace clean.

>
> In fact, it confused the junior devs. Check out this example:
>
> YAHOO.namespace("YAHOO.mst.scheduler");
>
> YAHOO.mst.scheduler = function() { ... }
>
> It's entirely possible to do this; to reassing a "package" to a
> function (or any value, or delete it). It's not safe. But neither are
> prototypes.
>
> extend(Sub, Super);
> Sub.prototype = { }; // <- Developer Mistake, just reassinged
> prototype.
>
> extend(Sub, Super, mixin); // <- corrected.
>
> On the other hand, enforcing namespacing has made my code more
> modular. Keeping the global namespace clean is just a small benefit.

I don't see how it helps with modularity.

>
> If I didn't use packages and a build system, unit testing would be a
> lot harder.

I use a build system, but only one namespace. I used to build a
hierarchy ala Yahoo, but came to the conclusion that it was a waste of
time and space.

>
> Writing a library is a lot of work. I want to write a better one. This
> includes:
> modular desing.
> minimal framework.
> building things as simple as possible, but not any simpler.
> unit testing.
> code review.
>
> Now that last one, I could probably use a lot of help on.

Post code here.

>
>
>
> > > What do YOU think?
>
> That was meant for the OP. I'm not sure why this thread was brought up
> even. If s/he's really considering Prototype, he could have done a web
> search, or searched this group. (but I can't search Groups in FF
> again; it's only FF now).

You can't search GG in FF? I assume GG has a new bug then. (?)

>
> > ME?  I think I have made that abundantly clear.  
>
> You have.
> The only thing worse
>
> > than Prototype is jQuery.  YUI is slightly better, but still well
> > south of competent.  Using any of these libraries (or God forbid
> > combinations of them) is a bad idea.  The average Web developer can
> > achieve lousy results on their own, so what is the benefit of adding
> > 100K of third-party incompetence to the mix?
>
> Most of the F/E jobs here in the bay area want someone who has one of
> the following:
> Prototype, YUI, Dojo, Scriptaculous, jQuery. If you can do that (of
> fake it good enough), you can make decent money.

HR people are clueless when it comes to front-end development. More
often than not (at least around here), their posted requirements
include such things as "x years of DreamWeaver experience." (!) Of
course, the more years of DW experience you have, the less likely you
are to know anything about Web development.

timothytoe

unread,
Feb 16, 2008, 5:40:28 PM2/16/08
to

Accepting needless and humorless rudeness will be what keeps clj in
the ghetto.

I would hope that clj could be more relevant and influential. To be
so, it'd have to be a little less consumed by its cult of misanthropic
personalities and stereotypical programmer nervous twitches, and a
little bit more about JavaScript.

David Mark

unread,
Feb 16, 2008, 5:45:42 PM2/16/08
to
On Feb 16, 2:29 pm, timothytoe <timothy...@gmail.com> wrote:

Who are you responding to? This is not a blog.

> Until a clj Nazi codes a "correct" library with the capabilities of

LOL. Perhaps you haven't been paying attention?

> jQuery or Prototype or YUI, those libraries will be continue to be
> used to make websites. And probably to an acccelerating degree.

Doubtful. Though it will be hard to derail YUI as it is backed by a
behemoth (soon to be swallowed by a bigger behemoth.)

>
> I agree that browser-sniffing is about as appealing as anus-sniffing,
> but programmers in the real-world sometimes need to actually get

Not the "real-world" argument again.

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

So the aim of a "smart programmer" is to design an instantly obsolete
Website with the hope that such a design will lead to additional work
fixing their own mistakes? Interesting strategy. Ridiculous and
disingenuous, but interesting.

>
> If my site is cobbled together in jQuery, guess what I'm going to look

Then you have a lousy site.

> for on a FE resume. I need another guy who knows jQuery, so he can

So if you are incompetent, then you would hypothetically look to other
incompetents for help? I don't follow the logic.

> read and debug the crappy code I wrote, and create new crappy code
> that I can read and debug. I want someone who knows the jQuery plug-
> ins, not some guy that'll come in and write a bunch of new untested
> tab systems, tablesorters, Canvas charting systems, modal dialogs, and

LOL. The jQuery UI components are garbage piled on garbage. Even
their developers admit they are crawling with bugs.

> tool-tips. If my new programmer quits because he hates the music I
> play, or because we have a dangerous-looking homeless guy outside who
> regularly threatens his life and throws half-eaten mayonnaise-and-
> cheese sandwiches at him every time he walks to his car at night, I'm
> going to look for <i>another</i> jQuery programmer to replace him.

<em>another</em>

It seems your initial cobbling strategy has led you down the
proverbial "slippery slope."

>
> And don't underestimate the impact of these libraries on the makers of
> browsers. As jQuery shows up in more and more sites, will Microsoft

Microsoft surely doesn't care how many sites use jQuery. And I don't
think the total is headed anywhere but down.

> really want to be seen as releasing an IE8 that is "broken" and
> "sucks?" I predict that Microsoft will endeavor to not break jQuery,
> Prototype, and YUI sites. Already, people are starting to base their

LOL. Have you read about IE8's new versioning feature? The IE-
sniffers are going to have to re-code and re-test everything.

> ideas of "browser speed" on the CSS and XPath selector timings from
> various libraries, and upon Javascript performance. It's not just the

Do tell.

> speed of layout that counts now. I bet Microsoft will actually
> accommodate these libraries so that IE has a little bit less
> embarrassing showing in the benchmarks. Do you think it's coincidence

The biggest problem for IE in the selector benchmarks is that they
don't support XPath for HTML documents. If they add that, they will
catch up. But what does that have to do with incompetently coded
libraries?

> that Microsoft is trying to pass acid tests?

I don't see the connection.

>
> By all means, point out the flaws in the libraries. But if you know

Glad to have your approval.

> how to write a better library, perhaps spend some of your time
> building a better mousetrap and a little less time flapping your
> mouthtrap.

As mentioned, you haven't been paying attention.

>
> It's all changed out from under you. The libraries are THE major force

Out from under whom?

> in Web 2.0 development now. jQuery is in (I believe) Rails now, and

Who cares what is in Rails?

> Drupal, and AIR. You may have disdain for them, but it's a quixotic
> (and mildly pathetically humorous) jihad you wage against them.

"Mildy pathetically humorous?" Can you elaborate?

>
> I'm not saying there is not a place for a by-the-books JS programmer

There's no book.

> out there--there certainly is. But I think there are already more
> places for a library-slinger and every month will bring more. It's

A library-slinger? Does that describe you? Most of this sounds like
an attempt to justify browser scripting incompetence (and planned
obsolescence.)

> more helpful to council people of how to deal with the libraries than
> avoid them.

But the best way to deal with them is to ignore them (and the
misguided zealots who promote them.)

David Mark

unread,
Feb 16, 2008, 5:53:43 PM2/16/08
to
On Feb 16, 4:06 pm, timothytoe <timothy...@gmail.com> wrote:
> >>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.
>
> You'd have to hunt one of them down and make them answer to know, but

No need to hunt them down. They pop in here occasionally and attempt
to justify their delusions.

Alternatively, you can gain an insight into their madness by reading
articles like this one:

http://ejohn.org/blog/future-proofing-javascript-libraries/

> my assumption is not yours. You appear to assume that they are simply
> sniffing to detect features. I assume they are sniffing to get around
> browser JS or CSS bugs, or perhaps in some cases to improve

Feature detection and testing can (and should be) done without
resorting to user agent sniffing.

> performance or to reduce the size of their often-transmitted

Then why are these libraries so bloated? And why do they only work in
a handful of modern browsers?

> functions. In other words, they probably have reasons that have to do
> with real-world trade-offs.

LOL. The "real-world" argument again. Is the real world really
devoid of developers who understand JavaScript and browser scripting?
If so, then education, rather than mindless justification, is the
answer.

David Mark

unread,
Feb 16, 2008, 6:06:03 PM2/16/08
to
On Feb 16, 4:54 pm, John Resig <jere...@gmail.com> wrote:
> > "Since valid HTML is simply a subset of XML, having an efficient way to
> > parse and browser DOM documents is an absolutely essential for making
> > JavaScript development easier." -JohnResig: Pro JavaScript Techniques.
> > 2006

And who are you replying to? This is Usenet, not a blog.

>
> Oh, interesting - is book errata submitted via usenet sig these days?http://apress.com/book/errata/275

Will you please stop writing books on browser scripting, at least
until you learn the basics?

>
> To help you out the correct quote is:
> "Since valid HTML is simply a subset of XML, having an efficient way
> to
> parse and browse DOM documents is absolutely essential for making
> JavaScript development easier." (Chapter 1, Page 8)

Other than the grammar, that is hardly an improvement. People who
write books are supposed to know what they are talking about, just as
people who write browser scripting libraries are supposed to know what
they are doing.

David
--
"Additionally, in Internet Explorer, doing object detection checks
can, sometimes, cause actual function executions to occur. For
example:

if ( elem.getAttribute ) {
// will die in Internet Explorer
}

That line will cause problems as Internet Explorer attempts to execute
the getAttribute function with no arguments (which is invalid). (The
obvious solution is to use "typeof elem.getAttribute == 'undefined'"
instead.)" -John Resig: Future-Proofing JavaScript Libraries

timothytoe

unread,
Feb 16, 2008, 6:13:50 PM2/16/08
to
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.

Or is the entertainment value of belittling them more valuable than
actually trying to convince them that you are correct?

timothytoe

unread,
Feb 16, 2008, 6:17:14 PM2/16/08
to

LOL. In the real world people use libraries. I'm all in favor of
education, and I think you do it poorly when you are rude and childish.

David Mark

unread,
Feb 16, 2008, 6:22:56 PM2/16/08
to
On Feb 16, 6:13 pm, timothytoe <timothy...@gmail.com> wrote:
> Perhaps the library writers could be more easily convinced to see

Who and what are you replying to?

> things the correct way if insults were not the default form of
> greeting on clj.

Au contraire. Insults have been shown to be the default form of
deflecting justifiable criticism of the writers' work. You reap what
you sow.

>
> Or is the entertainment value of belittling them more valuable than
> actually trying to convince them that you are correct?

I've personally never tried to convince any of them of anything. It
has been shown to be a waste of time. I simply warn others to resist
the urge to use delusions as a crutch.

timothytoe

unread,
Feb 16, 2008, 6:35:05 PM2/16/08
to
On Feb 16, 3:22 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 16, 6:13 pm, timothytoe <timothy...@gmail.com> wrote:
>
> Au contraire. Insults have been shown to be the default form of
> deflecting justifiable criticism of the writers' work...

If that's true, then the library writers who are being childish. So
are we stuck in a hopeless, vicious cycle of insults that no one is
adult enough to break out of?

>>I've personally never tried to convince any of them of anything. It
>>has been shown to be a waste of time. I simply warn others to resist
>>the urge to use delusions as a crutch.

It seems delusional to think that people will stay away from the
libraries. If the situation (by situation, I mean that these libraries
are being used on more and more websites) is to be improved, I believe
engagement with the library writers or the writing of comparably
useful but more robust libraries is the only solution.

If you've given up on helping the library writers improve the
robustness of their libraries, that's fine. Spend your time as you
like. But I still think the rudeness that permeates this newsgroup is
detrimental to its influence. Perhaps the thuggery elicits a few
chuckles from the peanut gallery, but I don't believe it's impressive
otherwise.

David Mark

unread,
Feb 16, 2008, 6:41:25 PM2/16/08
to

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

> education, and I think you do it poorly when you are rude and childish.

Well, "TimothyToe", if you consider justifiable criticism and warnings
to be "rude and childish", rather than educational, feel free to drop
out of the class.

timothytoe

unread,
Feb 16, 2008, 6:46:28 PM2/16/08
to

Justifiable criticisms and warnings are exactly what I'm looking for,
and are indeed educational. Please, more of that! Personal attacks,
not so much.

David Mark

unread,
Feb 16, 2008, 6:54:19 PM2/16/08
to
On Feb 16, 6:35 pm, timothytoe <timothy...@gmail.com> wrote:
> On Feb 16, 3:22 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Feb 16, 6:13 pm, timothytoe <timothy...@gmail.com> wrote:
>
> > Au contraire.  Insults have been shown to be the default form of
> > deflecting justifiable criticism of the writers' work...
>
> If that's true, then the library writers who are being childish. So
> are we stuck in a hopeless, vicious cycle of insults that no one is
> adult enough to break out of?

Not at all. We rarely talk about people here. The discussions
typically revolve around code.

>
> >>I've personally never tried to convince any of them of anything.  It
> >>has been shown to be a waste of time.  I simply warn others to resist
> >>the urge to use delusions as a crutch.
>
> It seems delusional to think that people will stay away from the
> libraries. If the situation (by situation, I mean that these libraries
> are being used on more and more websites) is to be improved, I believe
> engagement with the library writers or the writing of comparably
> useful but more robust libraries is the only solution.

The latter is the only option I see. The writers of the currently
popular libraries have shown that they have little interest in
learning from their mistakes. As Richard pointed out, the fact that
they rushed out their first attempts at browser scripting and found a
public willing to bet their sites on them, has left many frozen in
time. I would add that praise heaped on them by people who clearly
didn't know any better has given them a false sense of righteousness.

>
> If you've given up on helping the library writers improve the
> robustness of their libraries, that's fine. Spend your time as you

Thanks. I'll do that.

> like. But I still think the rudeness that permeates this newsgroup is

Who wants to be coddled in a technical discussion group? An encounter
group would seem a better place for that.

> detrimental to its influence. Perhaps the thuggery elicits a few
> chuckles from the peanut gallery, but I don't believe it's impressive
> otherwise.

Thuggery? I think you are reaching.

Richard Cornford

unread,
Feb 16, 2008, 6:54:59 PM2/16/08
to
timothytoe wrote:
> 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.

The way in which you read things seems to be having a very big impact on how
your perceive them. Try reading what you see as measured statements by
reasoning individuals and you might find that it is not at all insulting
(even if the comments are likely to be unwelcome to their recipient).

The post you are replying to (have you worked out which post you are
replying to yet?) contains a request (including the word "please"), a very
reasonable statement about the section of a book that I originally quoted
(which was a statement that in terms of semantics and verisimilitude is
about as reasonable as asserting that "Since Atlantic Salmon spawn in the
deep oceans refrigerators operate more effectively with clean shelves"), a
reasonable statement about general expectations of the qualifications of
book authors and library authors (expectations are often disappointed) and
finally cites and obvious (and easily demonstrated) nonsense.

If you don't read that as insulting it promptly stops being insulting, just
critical, and being relentlessly critical is the strength of Usenet.

> Or is the entertainment value of belittling them more
> valuable than actually trying to convince them that you
> are correct?

Think about that. John Resig has written a book called "Pro JavaScript
Techniques". So presumably he believes not only that he knows what he is
talking about but that he is in a position to be telling other people what
they should be doing. If you are going to successfully introduce such an
individual to the notion that they don't know what they are talking about
you are not going to do it by slapping them on the back and telling them how
well they have done.

Richard.
--
"Listing 3-12. Examples of How != and == Differ from !== and ===
// Both of these are true
null == false
0 == undefined" - John Resig: Pro JavaScript Techniques. 2006


timothytoe

unread,
Feb 16, 2008, 7:41:00 PM2/16/08
to
>>have you worked out which post you are
replying to yet?

No, could you please help me with that?

timothytoe

unread,
Feb 16, 2008, 7:44:51 PM2/16/08
to
> 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

unread,
Feb 16, 2008, 8:17:30 PM2/16/08
to
On Feb 16, 3:13 pm, timothytoe <timothy...@gmail.com> wrote:
> 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

unread,
Feb 16, 2008, 8:55:27 PM2/16/08
to
timothytoe wrote:
>>>have you worked out which post you are replying to yet?
>
> 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.
--
"When performing string concatenation the result is always a new string
object rather than a modified version of the original string." - John Resig:
Pro JavaScript Techniques. 2006


timothytoe

unread,
Feb 16, 2008, 9:39:04 PM2/16/08
to
On Feb 16, 5:55 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

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

unread,
Feb 16, 2008, 10:12:47 PM2/16/08
to
timothytoe wrote:
> On Feb 16, 5:55 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
[...]

>> Richard.
>> --
>> "When performing string concatenation the result is always a new string
>> object rather than a modified version of the original string." - John Resig:
>> Pro JavaScript Techniques. 2006
>
> 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.


--
Rob
"We shall not cease from exploration, and the end of all our
exploring will be to arrive where we started and know the
place for the first time." -- T. S. Eliot

Richard Cornford

unread,
Feb 16, 2008, 10:25:30 PM2/16/08
to
timothytoe wrote:
> On Feb 16, 5:55 pm, Richard Cornford wrote:
<snip>
>> ...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.
<snip>
> 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

unread,
Feb 16, 2008, 11:26:37 PM2/16/08
to
timothytoe wrote:
> 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.
--
"Luckily, there exists an excellent resource for explaining how closures
work in JavaScript: "JavaScript Closures" by Jim Jey at
http://jibbering.com/faq/faq_notes/closures.html." - John Resig: Pro
JavaScript Techniques. 2006


Peter Michaux

unread,
Feb 16, 2008, 11:39:27 PM2/16/08
to
On Feb 16, 11:29 am, timothytoe <timothy...@gmail.com> wrote:

> 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

FAQEditor

unread,
Feb 17, 2008, 1:38:14 AM2/17/08
to
Peter Michaux said the following on 2/16/2008 1:23 AM:
> On Feb 15, 1:53 pm, ashore <shor...@gmail.com> wrote:
>> Guys, I see a fair bit of negativity around re subject package. Can
>> someone share your views, either way?
>
> <FAQENTRY>
>
> Shouldn't something about Prototype be in the FAQ? It comes up very
> frequently.

I have not read the rest of the thread yet, so it may be mentioned. But,
the last time an FAQ Entry was requested on Prototype, it was turned
down. If you list Prototype and the problems with it, then you need to
list YUI, Mootools, etc.. and that becomes way too intensive for the
FAQ. What could be listed is a link to this thread about Prototype and
then links to the other library threads.

All in all, I still think it is a bad idea though.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
FAQ Notes: http://www.jibbering.com/faq/faq_notes/faq_notes.html
ECMAScript Language Specification via FAQ2.6

FAQEditor

unread,
Feb 17, 2008, 1:44:49 AM2/17/08
to
Peter Michaux said the following on 2/16/2008 4:47 PM:

<snip>

> Randy, what do you say? Is a FAQ entry acceptable?

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

David Mark

unread,
Feb 17, 2008, 1:47:09 AM2/17/08
to
On Feb 16, 11:26 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> timothytoe wrote:
> > 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.

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?

>
> > 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?

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.
> --
> "Luckily, there exists an excellent resource for explaining how closures

> work in JavaScript: "JavaScript Closures" by Jim Jey athttp://jibbering.com/faq/faq_notes/closures.html." - John Resig: Pro
> JavaScript Techniques. 2006

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

Peter Michaux

unread,
Feb 17, 2008, 1:57:06 AM2/17/08
to
On Feb 16, 10:44 pm, FAQEditor <clj...@comcast.net> wrote:
> Peter Michaux said the following on 2/16/2008 4:47 PM:
>
> <snip>
>
> > Randy, what do you say? Is a FAQ entry acceptable?
>
> 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

Randy Webb

unread,
Feb 17, 2008, 2:09:13 AM2/17/08
to
timothytoe said the following on 2/16/2008 5:06 PM:
>>> The contributors to this group have solid arguments why Prototype has
> problems. Those would need to be pointed out or the FAQ answer would
> not encapsulate the general opinions of the contributors. That is
> really what the FAQ is for: to reduce typing the same thing over and
> over again. If that is "biased" then the entry should be biased.
>
> It would be incredibly disappointing to me if the clj FAQ Entry for
> Prototype failed to condense the supreme rage that occurs when that
> library is mentioned into a hellishly hot and nasty black hole of snot.

If this group decides that an entry in the FAQ should be added for
Prototype.js, then it will reflect the current thinking about
Prototype.js in this group. If the truth hurts peoples feelings, then
they need to learn to bear the pain. My personal feelings about a
subject have never entered into the way an entry is written, modified,
or removed.

--
Randy
Chance Favors The Prepared Mind


comp.lang.javascript FAQ - http://jibbering.com/faq/index.html

Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

FAQEditor

unread,
Feb 17, 2008, 2:21:19 AM2/17/08
to
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
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 haven't been following your RFC threads lately, anything FAQ related
in them?

Peter Michaux

unread,
Feb 17, 2008, 2:30:27 AM2/17/08
to
On Feb 16, 11:21 pm, FAQEditor <clj...@comcast.net> wrote:
> Peter Michaux said the following on 2/17/2008 1:57 AM:
>
> > On Feb 16, 10:44 pm, FAQEditor <clj...@comcast.net> wrote:
> >> Peter Michaux said the following on 2/16/2008 4:47 PM:
>
> >> <snip>
>
> >>> Randy, what do you say? Is a FAQ entry acceptable?
> >> 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?
>
> 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

FAQEditor

unread,
Feb 17, 2008, 2:30:54 AM2/17/08