Re: Prototype - Good/Bad/Why?

On Feb 16, 11:26 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
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.
.

Relevant Pages

  • Re: AJAX.NET and prototype.js
    ... Javascript is an ideal language for client-side scripting ... (particularly browser scripting) ...
    (comp.lang.javascript)
  • RE: RadioButtonList, MultiView, and JavaScript
    ... security settings for the Internet zone in your browser to disable Active ... To learn more about the effect of disabling client-side scripting on the ... Question - can I assume javascript must be enabled in ASP.NET? ...
    (microsoft.public.dotnet.framework.aspnet.webcontrols)
  • Re: JS Guru needed! Why doesnt this work?
    ... > (in case if the scripting is disabled). ... accommodating javascript incapable/disabled browsers. ... and then client-side scripting can transform it ... > own browser etc. etc. ...
    (comp.lang.javascript)
  • Re: You cowboys were right
    ... "lightweight and interchangeable functions". ... that it abstracts basic browser scripting tasks (e.g. DOM ... Libraries are typically designed and tested as a unit and often cannot ... Then there was this ridiculous race to "pave over" every known browser ...
    (comp.lang.javascript)
  • Re: bank site & enabling java
    ... but still i cant get into the credit union site. ... Allow scripting of IE browser control ... support JavaScript or JavaScript may be disabled. ...
    (microsoft.public.windowsxp.basics)