Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Prototype - Good/Bad/Why?

Reply
Thread Tools

Prototype - Good/Bad/Why?

 
 
ashore
Guest
Posts: n/a
 
      02-15-2008
Guys, I see a fair bit of negativity around re subject package. Can
someone share your views, either way?

Thanks,

AS
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      02-15-2008
On Feb 15, 4:53*pm, ashore <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
dhtml
Guest
Posts: n/a
 
      02-16-2008
On Feb 15, 2:36*pm, David Mark <(E-Mail Removed)> wrote:
> On Feb 15, 4:53*pm, ashore <(E-Mail Removed)> 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
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?
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-16-2008
On Feb 15, 9:36*pm, dhtml <(E-Mail Removed)> wrote:
> On Feb 15, 2:36*pm, David Mark <(E-Mail Removed)> wrote:
>
>
>
>
>
> > On Feb 15, 4:53*pm, ashore <(E-Mail Removed)> 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?
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-16-2008
On Feb 16, 12:50*am, Randy Webb <(E-Mail Removed)> 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?
 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      02-16-2008
On Feb 15, 1:53 pm, ashore <(E-Mail Removed)> 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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      02-16-2008
On Feb 16, 1:23*am, Peter Michaux <(E-Mail Removed)> wrote:
> On Feb 15, 1:53 pm, ashore <(E-Mail Removed)> 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


I propose a two word entry: mostly harmful.
And for jQuery: completely worthless.
 
Reply With Quote
 
dhtml
Guest
Posts: n/a
 
      02-16-2008
On Feb 15, 7:42*pm, David Mark <(E-Mail Removed)> wrote:
> On Feb 15, 9:36*pm, dhtml <(E-Mail Removed)> wrote:
>
>
>
> > On Feb 15, 2:36*pm, David Mark <(E-Mail Removed)> wrote:

>
> > > On Feb 15, 4:53*pm, ashore <(E-Mail Removed)> 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.

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      02-16-2008
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: < (E-Mail Removed) om >).

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


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      02-16-2008
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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Prototype WTP 0.2 released,this release for Prototype 1.6.0 javascript fish Javascript 0 10-11-2008 07:35 AM
Class prototype vs C function prototype June Lee C++ 2 04-13-2008 08:17 PM
Prototype Object.extend(new Base() | Hash | Hash.prototype) usage: jacobstr@gmail.com Javascript 3 03-27-2007 07:56 AM
relation between prototype and Prototype.js shypen42@yahoo.fr Javascript 9 05-26-2006 01:13 AM
mod_perl errors: prototype mismatch ... during global destruction ian douglas Perl 0 08-18-2003 11:17 PM



Advertisments