Prototype - Good/Bad/Why?

32 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