Why should I eschew prototype.js?

15 views
Skip to first unread message

nolo contendere

unread,
Nov 12, 2007, 10:44:28 AM11/12/07
to
I've recently begun playing with prototype.js as well as
scriptaculous, and found both very helpful in developing web pages
with lots of pop. Modal boxes, SlideUp/Down, calendars, etc.

I've also recently ramped up my lurking and participation in this
newsgroup. There are some who advocate using prototype, and others who
are adamantly opposed to it. Are there any concrete reasons why I
should NOT use it? Is it inefficient? It seems that today's computers
have sufficient processing power to overcome most slowly implemented
solutions in javascript. And the benefits of being able to inject such
a wide variety of effects into a page (to me) far outweigh any harm.

Gregor Kofler

unread,
Nov 12, 2007, 11:08:11 AM11/12/07
to
nolo contendere meinte:

> Are there any concrete reasons why I
> should NOT use it?

Since it won't foster any understanding of proper JavaScript programming
(or even use).

You'll run into problems sooner or later (because you'll combine
prototype with mooTools and jQuery and throw in another "framework" for
good measure, and all those "frameworks" have their individual
shortcomings).
You will end up asking another one of those "my this-or-that form
element doesn't work the way I expect it, why?" questions.

And all the advice you'll get, is to look for help elsewhere.


Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

nolo contendere

unread,
Nov 12, 2007, 11:22:06 AM11/12/07
to
On Nov 12, 12:08 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> nolo contendere meinte:
>
> > Are there any concrete reasons why I
> > should NOT use it?
>
> Since it won't foster any understanding of proper JavaScript programming
> (or even use).
>
> You'll run into problems sooner or later (because you'll combine
> prototype with mooTools and jQuery and throw in another "framework" for
> good measure, and all those "frameworks" have their individual
> shortcomings).
> You will end up asking another one of those "my this-or-that form
> element doesn't work the way I expect it, why?" questions.
>
> And all the advice you'll get, is to look for help elsewhere.

This argument can be applied to any library of functions. The harm
here is that by not using a library, one must constantly reinvent the
wheel. If I get a job as a front-end developer, I'll likely inherit
some code. Whether the code was homebrewed by the previous developer,
or adopted by him/her, it's possible that coding I do for projects
going forward will conflict with this library, and I'll have to debug.
At least with a library that is more widely adopted, and for which
there is some documentation, I'll have better tools and more resources
for doing that debugging.

As far as not fostering understanding of Javascript, that's not what
libraries are for. It's my responsibility as a developer to learn the
language.

I can definitely see your point that it could be a crutch though, and
could enable bad programming practices as well as laziness in
understanding the language. If that's the primary disadvantage, I
won't worry about it. I've just seen in some poster's tags that
prototype was written by people who don't understand javascript, but
there was no evidence to support that claim.

Thanks for your response.

Gregor Kofler

unread,
Nov 12, 2007, 11:37:59 AM11/12/07
to
nolo contendere meinte:

> As far as not fostering understanding of Javascript, that's not what
> libraries are for. It's my responsibility as a developer to learn the
> language.

Discussing the *use* of JS libraries is not the focus of clj.

> I can definitely see your point that it could be a crutch though, and
> could enable bad programming practices as well as laziness in
> understanding the language. If that's the primary disadvantage, I
> won't worry about it. I've just seen in some poster's tags that
> prototype was written by people who don't understand javascript, but
> there was no evidence to support that claim.

Google might help - the problems (or - for some - the lack of these)
with these frameworks have been discussed in this NG several times.

Thomas 'PointedEars' Lahn

unread,
Nov 12, 2007, 12:12:54 PM11/12/07
to
nolo contendere wrote:
> [...] There are some who advocate using prototype, and others who

> are adamantly opposed to it.

You will observe the individuals who recommend against Prototype.js usually
to be more knowledgeable about the language(s) than the individuals who
recommend in favor of it. That should account for something.

> Are there any concrete reasons why I should NOT use it? Is it inefficient?

Yes.

> It seems that today's computers have sufficient processing power
> to overcome most slowly implemented solutions in javascript.

You are mistaken. First-world high-end computers and Internet connections
are not the standard to develop for on the Web, at least they should not be.
Besides, efficience is not restricted to runtime efficience, and efficience
is one of the lesser problems with Prototype.js.

> And the benefits of being able to inject such a wide variety of effects
> into a page (to me) far outweigh any harm.

The harm comes from another direction.


Ceterum censeo Prototype.js esse delendam.[1]

PointedEars
___________
[1] Belated thanks to Evertjan. who by his correction put me on track
to find out that the English verb "(to) delete" is derived from
the Latin verb "deleo" ([to] destroy).
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

nolo contendere

unread,
Nov 12, 2007, 12:16:00 PM11/12/07
to
On Nov 12, 12:37 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> nolo contendere meinte:
>
> > As far as not fostering understanding of Javascript, that's not what
> > libraries are for. It's my responsibility as a developer to learn the
> > language.
>
> Discussing the *use* of JS libraries is not the focus of clj.

I suppose not--as i stated previously, I'm new here. However, just
because it's not the focus doesn't mean that there can't be ancillary
discussions about it.

>
> > I can definitely see your point that it could be a crutch though, and
> > could enable bad programming practices as well as laziness in
> > understanding the language. If that's the primary disadvantage, I
> > won't worry about it. I've just seen in some poster's tags that
> > prototype was written by people who don't understand javascript, but
> > there was no evidence to support that claim.
>
> Google might help - the problems (or - for some - the lack of these)
> with these frameworks have been discussed in this NG several times.

Did so.

I had not realized prototype.js was such a hot topic, or that just by
bringing it up I might invite myself to being viewed with immediate
hostility, or, at best, a standoffish neutrality rather than with a
friendly smile and an offer of a helping hand. Still, better than what
some newbies get at c.l.perl.misc...;-)

After reviewing some threads about this subject, I discovered an
enlightening one:
http://tinyurl.com/yps5l9

Thanks.

Gregor Kofler

unread,
Nov 12, 2007, 12:24:11 PM11/12/07
to
nolo contendere meinte:

> I had not realized prototype.js was such a hot topic,

I'd say it is anything but "hot" on clj.

> or that just by
> bringing it up I might invite myself to being viewed with immediate
> hostility, or, at best, a standoffish neutrality rather than with a
> friendly smile and an offer of a helping hand.

People using prototype are rarely interested in writing their own
scripts, particularly writing them properly. However, that's what a lot
of people reading clj want to do. I once got in touch with prototype
about two years ago - the size of library and the then complete lack of
documentation drove me to writing my own lean libraries.

> Still, better than what
> some newbies get at c.l.perl.misc...;-)

That's usenet. If you want to be caressed you have to resort to web
forums, I suppose.

nolo contendere

unread,
Nov 12, 2007, 12:57:07 PM11/12/07
to
On Nov 12, 1:24 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> nolo contendere meinte:
>
> > I had not realized prototype.js was such a hot topic,
>
> I'd say it is anything but "hot" on clj.
>

s/hot/hot button/

s0lnic

unread,
Nov 12, 2007, 1:58:05 PM11/12/07
to
nolo contendere wrote:

> Are there any concrete reasons why I
> should NOT use it?

No, there aren't, unless you're able to write something better then
jQuery/Prototype/YUI/Mojo/whatever or you just want to have your own
library and you have enough time to do this. If you're creating webapps
with a rich UI then you definitely need a JavaScript library.

> Is it inefficient?

No, it's not.

--
# Regards || piotr[.]solnica[at]gmail[.]com || jid : s0l...@jabster.pl #
# s0lnic || http://blog.solnic.in5.pl || icq : 385935391 #

Thomas 'PointedEars' Lahn

unread,
Nov 12, 2007, 2:05:30 PM11/12/07
to
s0lnic wrote:
> nolo contendere wrote:
>> Are there any concrete reasons why I
>> should NOT use it?
>
> No, there aren't, unless you're able to write something better then
> jQuery/Prototype/YUI/Mojo/whatever

Almost anyone is able to write something better than those, with *maybe*
the exception of YUI.

> or you just want to have your own library and you have enough time
> to do this.

That is an entirely different matter, of course.

> If you're creating webapps with a rich UI then you definitely need
> a JavaScript library.

But not necessarily a library written by people who don't have a clue
about what they are doing.


PointedEars, with a fitting random 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$8300...@news.demon.co.uk>

nolo contendere

unread,
Nov 12, 2007, 2:11:10 PM11/12/07
to
On Nov 12, 2:58 pm, s0lnic <l...@my.sig> wrote:
> nolo contendere wrote:
> > Are there any concrete reasons why I
> > should NOT use it?
>
> No, there aren't, unless you're able to write something better then
> jQuery/Prototype/YUI/Mojo/whatever or you just want to have your own
> library and you have enough time to do this. If you're creating webapps
> with a rich UI then you definitely need a JavaScript library.
>
> > Is it inefficient?
>
> No, it's not.

Thanks Piotr. That's the second time you've helped me :-).

Thomas 'PointedEars' Lahn

unread,
Nov 12, 2007, 2:19:40 PM11/12/07
to

Blind leading the blind.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Matt Kruse

unread,
Nov 12, 2007, 2:27:29 PM11/12/07
to
On Nov 12, 9:44 am, nolo contendere <simon.c...@fmr.com> wrote:
> There are some who advocate using prototype, and others who
> are adamantly opposed to it.

There are a few long threads (one recently) about the concept of
libraries and philosophies about how javascript should be developed.
People usually fall somewhere in the spectrum between "use a library
like prototype and do it all that way" and "never use a general-
purpose library - write your own code to meet the requirement at
hand".

Where you land depends a lot on your javascript knowledge and
experience, your goals, priorities, and context. If you are
comfortable with the idea of using a general-purpose library, then
that whole discussion can be tabled and instead you can focus on which
library you should use and how you should best use it.

> Are there any concrete reasons why I
> should NOT use it?

Stylistic preferences would be one. I don't like its emphasis on
classes, inheritance, etc. For me, the API is too large and complex -
it tries to do more than I want it to. And I found it hard to use to
just add some quick effects or helper functions to an existing page.
I've never looked into the internals to judge it technically.

> Is it inefficient?

Certainly more inefficient than using core DOM functions and built-in
javascript functionality. But probably not enough to make a difference
in most cases. If you get into heavy UI stuff, general-purpose
libraries tend to slow down, in my experience.

> It seems that today's computers
> have sufficient processing power to overcome most slowly implemented
> solutions in javascript.

Depends on your target audience.

> And the benefits of being able to inject such
> a wide variety of effects into a page (to me) far outweigh any harm.

Again, it comes back to your requirements and priorities. If you want
to support as many users and browsers as possible, trying to create a
slick client-side UI with lots of effects and stuff will kill some
people.

I think it's best to read the arguments on both sides to become more
informed. Then consider all the factors in front of you and come to
your own conclusion about whether a javascript library will be helpful
to you.

Matt Kruse

nolo contendere

unread,
Nov 12, 2007, 2:43:51 PM11/12/07
to
On Nov 12, 3:27 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Nov 12, 9:44 am, nolo contendere <simon.c...@fmr.com> wrote:
>

---8<---snip--->8--


> > And the benefits of being able to inject such
> > a wide variety of effects into a page (to me) far outweigh any harm.
>
> Again, it comes back to your requirements and priorities. If you want
> to support as many users and browsers as possible, trying to create a
> slick client-side UI with lots of effects and stuff will kill some
> people.

True, but you can't please all the people all the time. I'm testing
out my code in IE 6, FF 2.0, and Safari 3. That covers enough area for
me. Also, this is an internal site, so I can be reasonably sure of the
consistency and specs of the machines that will be used to view the
site.

>
> I think it's best to read the arguments on both sides to become more
> informed. Then consider all the factors in front of you and come to
> your own conclusion about whether a javascript library will be helpful
> to you.

Sage advice for any topic.

>
> Matt Kruse

During the course of my research into the original question, your name
popped up a few times. I checked out your site, and also noticed that
the clj FAQ guy, Randy, had your Best Practices link in his sig. I
don't know too much about your credentials, but you at least seem to
try to help people rather than latch on to some trivial technicality
or misspelling or minutia and harp on it, for which you get my
respect.

I also noticed that you wrote several Google Gadgets--they look pretty
neat, although the target audience seems to be pretty advanced users
(read: hard-core geeks). By this I mean that the gadgets are very
customizable, which is a good thing, but the number of configuration
options may dissuade it's adoption by the general masses.

Anyway, thanks for your input. It was constructive.

Matt Kruse

unread,
Nov 12, 2007, 2:50:49 PM11/12/07
to
On Nov 12, 1:43 pm, nolo contendere <simon.c...@fmr.com> wrote:
> I also noticed that you wrote several Google Gadgets--they look pretty
> neat, although the target audience seems to be pretty advanced users
> (read: hard-core geeks). By this I mean that the gadgets are very
> customizable, which is a good thing, but the number of configuration
> options may dissuade it's adoption by the general masses.

True, but I wrote them all for my own use. My iGoogle page is heavily
customized and filled with tons of feeds and info. I make the gadgets
available to the world because I never know who might find them
useful :)

Matt Kruse


nolo contendere

unread,
Nov 12, 2007, 2:53:37 PM11/12/07
to

aahh...I thought you might be trying for the Google Gadget Venture:
http://www.google.com/gadgetventures/

Gregor Kofler

unread,
Nov 12, 2007, 2:54:00 PM11/12/07
to
nolo contendere meinte:

> True, but you can't please all the people all the time. I'm testing
> out my code in IE 6, FF 2.0, and Safari 3. That covers enough area for
> me.

It's not a compatibility issue (at least with a decent library) -
webpages should always provide a fallback for people without JS. JS for
the eye-candy and the enhanced usability, but not for the core
functionality, but then...

> Also, this is an internal site, so I can be reasonably sure of the
> consistency and specs of the machines that will be used to view the
> site.

...YMMV.

s0lnic

unread,
Nov 12, 2007, 2:57:04 PM11/12/07
to
Thomas 'PointedEars' Lahn wrote:

>> Thanks Piotr. That's the second time you've helped me :-).
>
> Blind leading the blind.

Why? There are no perfect tools, I'm sure you know that. Prototype helps me
a lot in my everyday work, there are many things which bugs me, but it's
getting better and better. I don't have any serious problems with it, its
current http://www.prototypejs.org/api is very useful, its performance is
just fine, it resolves many common crossbrowser issues which every web
developer has to deal with (sooner or later). I started using Prototype
about 1.5 year ago, before that I was writing all my JavaScript without a
use of any other library and it was sometimes really painful (back then
IE5.5 had to be supported ;P). Maybe you, JavaScript masters with zillions
years of experience, have better alternatives, maybe you have written your
very own libraries, which are better then anything else - good for you
then! I wish I had enough time to do the same, but I don't and I'm using
what's available, and Prototype IS a good option, maybe other libs are
better (jQuery looks very promising), I don't know, haven't used them in
any real project yet. The fact is that I DID use Prototype and there are
MANY working applications which are based on Prototype, and you know what?
People use these apps, and they really like them, so what's the problem?
No, stop, don't answer - Prototype creators don't know what they are doing,
they know sh*t about JavaScript, this library should be destroyed.
Whatever, man.

Cheers and EOT

Randy Webb

unread,
Nov 12, 2007, 3:09:20 PM11/12/07
to
nolo contendere said the following on 11/12/2007 10:44 AM:

> I've recently begun playing with prototype.js as well as
> scriptaculous, and found both very helpful in developing web pages
> with lots of pop. Modal boxes, SlideUp/Down, calendars, etc.

What you call "lots of pop" can be very annoying to some people though.
And that has nothing to do with Prototype.js in particular. What you are
going to find in this group is that you can't get two people here to
agree on anything.

> I've also recently ramped up my lurking and participation in this
> newsgroup. There are some who advocate using prototype, and others who
> are adamantly opposed to it. Are there any concrete reasons why I
> should NOT use it?

The major problem, lately, with prototype.js is people asking here "Why
doesn't it work?" and Peter Michaux has been posting the best answer to
those questions. It is no different than trying to ask in a C++ group
why a program written in C++ doesn't "work". The only difference is one
is open source and one isn't.

In contrast, if someone posts a question along the lines of "This is how
prototype.js does it, is there a better way?" (or similar) then it would
appropriate here.

Why you should, or shouldn't, use it is a decision that you have to
make. Whether it satisfies your needs or not. And, what your end goals
are. If your goal is simply to get something on the web without ever
wanting to learn more, and it satisfies your needs, then use it.

> Is it inefficient?

I can't, and so I won't, comment on that. I have not looked at the
prototype code in a very long time.

> It seems that today's computers have sufficient processing power to
> overcome most slowly implemented solutions in javascript.

That is a backwards issue that has been in computing for over 30 years.
"I don't have to write efficient code because computers are fast enough
to compensate for it."

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

nolo contendere

unread,
Nov 12, 2007, 3:18:54 PM11/12/07
to
On Nov 12, 4:09 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> nolo contendere said the following on 11/12/2007 10:44 AM:
>

>


> > It seems that today's computers have sufficient processing power to
> > overcome most slowly implemented solutions in javascript.
>
> That is a backwards issue that has been in computing for over 30 years.
> "I don't have to write efficient code because computers are fast enough
> to compensate for it."
>

Sure, taken to either extreme, the efficiency of code can either be
the most or least important thing. Practically speaking, it doesn't
make sense to spend years profiling and tuning code to get the
absolute best performance out of it. And yet it also doesn't make
sense to use algorithms that are O(n^3) or worse. I didn't mean to
blithely assert that I can be lazy and not have to consider the
performance of my code, I was looking at it more from an order of
magnitude scope. My earlier question could have been better phrased
"Would using prototype.js rather than the native DOM/javascript
functions impose a cost that would be orders of magnitudes greater?".
If not, then I wouldn't want to spend time micro-optimizing.

I have some expertise in Perl, and like to write efficient code, but I
realize that if performance was THE most important factor, I wouldn't
write code in Perl.

Richard Cornford

unread,
Nov 12, 2007, 7:45:57 PM11/12/07
to
nolo contendere wrote:
> I've recently begun playing with prototype.js as well as
> scriptaculous, and found both very helpful in developing
> web pages with lots of pop. Modal boxes, SlideUp/Down,
> calendars, etc.
>
> I've also recently ramped up my lurking and participation
> in this newsgroup. There are some who advocate using prototype,

Here?

> and others who are adamantly opposed to it. Are there any
> concrete reasons why I should NOT use it?

Lots, but I don't have time to go through all of them right now.
However, one good illustration is the least you deserve.

Take this code form the latest (1.6.0) version of Prototype.js:-

| var Hash = Class.create(Enumerable, (function() {
| if (function() {
| var i = 0, Test = function(value) { this.key = value };
| Test.prototype.key = 'foo';
| for (var property in new Test('bar')) i++;
| return i > 1;
| }()) {
| function each(iterator) {
| var cache = [];
| for (var key in this._object) {
| var value = this._object[key];
| if (cache.include(key)) continue;
| cache.push(key);
| var pair = [key, value];
| pair.key = key;
| pair.value = value;
| iterator(pair);
| }
| }
| } else {
| function each(iterator) {
| for (var key in this._object) {
| var value = this._object[key], pair = [key, value];
| pair.key = key;
| pair.value = value;
| iterator(pair);
| }
| }
| }
| ...

- What this appears to represent is the conditional creation of a
function based upon (rather complex) test. But in ECMAScript terms this
is actually one big syntax error, because inside each of the
BlockStatement branches of the - if-else - there are what appear to be
function declarations, and BlockStatemen may only contain Statements
(not FunctionDeclarations (FunctionDeclarations and Statements being the
two distinct syntactic units from which ECMAScript Programs and function
bodies are constructed)).

Obviously if the 3 or 4 browsers with which Prototype.js 'works'
actually generated a syntax error that fact would have been noticed, so
what is happening? The first part of the answer is that JavaScript(tm)
has a non-standard syntax extension that is a FunctionStatement, which
(being a Statement) may appear inside a BlockStatement and can be
conditionally evaluated. ECMAScript allows for such extensions, though
they usually must be avoided when creating cross-browser code. The
second part of the answer is that JScript (and many other ECMAScript
implementations, including Opera's) are tolerant enough to
unconditionally treat these out of context 'FunctionDeclarations' as
FunctionDeclarations. But because FunctionDeclarations are processed
during variable instantiation, before any actual code execution, in
these environments the effect of the above is the equivalent of:-

var Hash = Class.create(Enumerable, (function() {
function each(iterator) {
for (var key in this._object) {
var value = this._object[key], pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
function each(iterator) {
var cache = [];
for (var key in this._object) {
var value = this._object[key];
if (cache.include(key)) continue;
cache.push(key);
var pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
if (function() {
var i = 0, Test = function(value) { this.key = value };
Test.prototype.key = 'foo';
for (var property in new Test('bar')) i++;
return i > 1;
}()) {

} else {

}
...

- Where the first - each - FunctionDeclaration results in the creation
of a function object and the assignment of a reference to that function
to the 'each' property of the variable object, and then the second -
each - FunctionDeclaration - results in the creation of a second
function object which is then assigned to the 'each' property of the
variable object, replacing the first. So in these environments it is the
second FunctionDeclaration that defines 'each', unconditionally, and
the - if-else - statement is effectively empty, making its execution
worthless.

Now if this code 'works' at all it 'works' mostly by coincidence as it
is relying on a non-standard extension wherever the - if-else - is
effective, and where the FunctionDeclaration are unconditionally acted
upon the result must only 'work' due to the order in which the two
declarations appear.

Of course the conditional creation of function objects is trivial in
javascript in a way that fully conforms with the ECMAScript
specification, and so in a way that can be expected to be fully
cross-browser and consistently executed in ECMA 262 3rd Ed. implementing
environments. Such code would be something like:-

var Hash = Class.create(Enumerable, (function() {
var each;
if (function() {
var i = 0, Test = function(value) { this.key = value };
Test.prototype.key = 'foo';
for (var property in new Test('bar')) i++;
return i > 1;
}()) {
each = function (iterator) {
var cache = [];
for (var key in this._object) {
var value = this._object[key];
if (cache.include(key)) continue;
cache.push(key);
var pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
} else {
each = function (iterator) {
for (var key in this._object) {
var value = this._object[key], pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
}
...

- replacing the 'syntax error' FunctionDeclaration with Expression
Statements where a Function Expression is assigned to an Identifier. The
result is fully ECMAScript standard and so will 'work' consistently in
all past, present and future ECMA 262 3rd Ed. conforming
implementations.

It is simply the case that anyone knowing javascript would have written
the original code in this final form. So would not be writing code that
functioned purely by coincidence but instead they would be programming.

The problem with the way this sort of ignorance of javascript results in
code that only works by coincidence is highlighted by browsers like
Opera. Opera currently acts like JScript, and unconditionally acts on
the FunctionDeclarations out of their (otherwise syntax error) context
but while Opera has an ECMA 262 conforming javascript implementation,
they also aim to emulate JavaScript(tm), and so may introduce
JavaScript(tm)'s FunctionStatement extension at any moment. And so code
that works by coincidence because of the order of the
'FunctionDeclarations' may find itself suddenly conditionally evaluating
FunctionStatements with any next version of Opera, and what these
branches do in that versions of Opera may be totally inappropriate.

The Prototype.js approach results in code that cannot be expected to
work in any more browsers than those in which it has been demonstrated
to 'work', and so cannot even be expected to 'work' with the future
versions of that those browsers. This cannot be a viable approach to
creating cross-browser code, and it does not.

That is quite a bit of writing in order to demonstrate that the authors
of Prototype.js don't know javascript. Similar demonstrations are
possible for bad design, ridiculous inefficiencies, avoidable bad
practices and much else besides, but I don't have time right now so you
will have to look them up in the archive.

> Is it inefficient?

The code itself is about a quarter as efficient as it could be, but
certain aspects of the design promote its extremely inefficient use, so
examples you will see are often orders of magnitude worse than that.
Fast computers mitigate that problem, but you would find systems created
with Prototype.js become unacceptably sluggish at much lower levels of
complexity.

> It seems that today's computers have sufficient processing
> power to overcome most slowly implemented solutions in
> javascript.

Maybe, but that doesn't stop my boss continually wanting the client-side
code our web applications to run faster. He maintains that they are
easier to sell when they are fast, and then that they are easier to sell
if they have ever more bells and whistles. Obviously those are
contradictory demands.

> And the benefits of being able to inject such
> a wide variety of effects into a page (to me) far
> outweigh any harm.

At least for as long as you avoid understanding how those effects work,
and so how trivial they are to create for yourself.

Richard.

nolo contendere

unread,
Nov 13, 2007, 10:45:42 AM11/13/07
to
On Nov 12, 8:45 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> nolo contendere wrote:
> > I've recently begun playing with prototype.js as well as
> > scriptaculous, and found both very helpful in developing
> > web pages with lots of pop. Modal boxes, SlideUp/Down,
> > calendars, etc.
>
> > I've also recently ramped up my lurking and participation
> > in this newsgroup. There are some who advocate using prototype,
>
> Here?
>

In this very thread in fact.

> > and others who are adamantly opposed to it. Are there any
> > concrete reasons why I should NOT use it?
>
> Lots, but I don't have time to go through all of them right now.
> However, one good illustration is the least you deserve.
>

I appreciate it.

Why has a library not been written this way? Obviously it's not your
responsibility to do it, or to even know the reason why it hasn't been
done thus far, but if so many people are in error, and it causes you
any distress, it would behoove you to write one, or at least begin
one. Perhaps set up a project? Clearly you care a lot about this
subject, and have invested much time in it. This is just another
avenue by which you can participate in -- and even shape -- the future
of how javascript is used.

> It is simply the case that anyone knowing javascript would have written
> the original code in this final form. So would not be writing code that
> functioned purely by coincidence but instead they would be programming.
>
> The problem with the way this sort of ignorance of javascript results in
> code that only works by coincidence is highlighted by browsers like
> Opera. Opera currently acts like JScript, and unconditionally acts on
> the FunctionDeclarations out of their (otherwise syntax error) context
> but while Opera has an ECMA 262 conforming javascript implementation,
> they also aim to emulate JavaScript(tm), and so may introduce
> JavaScript(tm)'s FunctionStatement extension at any moment. And so code
> that works by coincidence because of the order of the
> 'FunctionDeclarations' may find itself suddenly conditionally evaluating
> FunctionStatements with any next version of Opera, and what these
> branches do in that versions of Opera may be totally inappropriate.
>

So this is the browser's problem. They are too permissive. But if you
think about it, if 90% of people do something one way, and that way
doesn't conform to "the standard" (in this case, ECMA), doesn't the
way most people do it BECOME the standard? It may be horrific in its
implementation, syntax, whatever, but so is HTTP. So you either adapt
and use it, or try to make change.

> The Prototype.js approach results in code that cannot be expected to
> work in any more browsers than those in which it has been demonstrated
> to 'work', and so cannot even be expected to 'work' with the future
> versions of that those browsers. This cannot be a viable approach to
> creating cross-browser code, and it does not.
>

Again, this may be the browser's fault then. Bear in mind that browser
developers do have to cater to existing web pages, and have all sorts
of testing to try to ensure that nothing breaks in future versions. I
highly doubt that just because a page doesn't conform to ECMA
standards, the browser developers will say "screw that web page, if
they don't follow ECMA they don't get a proper rendering in our
browser." This may work if the percentage of "bad" web pages were
vanishingly small, but hey, this is the real world where people are
stupid and market share is of vital importance to a browser's
continued existence. I'm not saying I'm encouraging bad coding, or
stupidity, but I'm being a realist. Once all market share is captured,
THEN you can begin to gradually enforce whichever standards are the
best. But until then, it's a free-for-all.

> That is quite a bit of writing in order to demonstrate that the authors
> of Prototype.js don't know javascript. Similar demonstrations are
> possible for bad design, ridiculous inefficiencies, avoidable bad
> practices and much else besides, but I don't have time right now so you
> will have to look them up in the archive.
>

I truly do appreciate your perspective. I did a little research on
you, and you appear to be a very intelligent individual, although (and
I don't mean to be destructively critical) a bit of an idealist/
purist--which the world does need, but isn't the way the world works.

> > Is it inefficient?
>
> The code itself is about a quarter as efficient as it could be, but
> certain aspects of the design promote its extremely inefficient use, so
> examples you will see are often orders of magnitude worse than that.
> Fast computers mitigate that problem, but you would find systems created
> with Prototype.js become unacceptably sluggish at much lower levels of
> complexity.
>
> > It seems that today's computers have sufficient processing
> > power to overcome most slowly implemented solutions in
> > javascript.
>
> Maybe, but that doesn't stop my boss continually wanting the client-side
> code our web applications to run faster. He maintains that they are
> easier to sell when they are fast, and then that they are easier to sell
> if they have ever more bells and whistles. Obviously those are
> contradictory demands.
>
> > And the benefits of being able to inject such
> > a wide variety of effects into a page (to me) far
> > outweigh any harm.
>
> At least for as long as you avoid understanding how those effects work,
> and so how trivial they are to create for yourself.

Again, if they are so trivial, why wouldn't a "good" library have been
written? Wouldn't evolution cause the "good" librarues to bubble up
and become the de facto standard? Wouldn't "bad libraries" break in
future revs, independent browsers, etc, and the "good libraries" gain
mind- and market-share with each manifestation of the "bad
libararies'" failure?

Gregor Kofler

unread,
Nov 13, 2007, 11:56:39 AM11/13/07
to
nolo contendere meinte:

> Again, this may be the browser's fault then. Bear in mind that browser
> developers do have to cater to existing web pages, and have all sorts
> of testing to try to ensure that nothing breaks in future versions.

You know what? There are websites (not conforming to standards, sure),
wich looked perfectly ok on IE6, but break more or less seriously on IE7.

> I highly doubt that just because a page doesn't conform to ECMA
> standards, the browser developers will say "screw that web page, if
> they don't follow ECMA they don't get a proper rendering in our
> browser." This may work if the percentage of "bad" web pages were
> vanishingly small, but hey, this is the real world where people are
> stupid and market share is of vital importance to a browser's
> continued existence. I'm not saying I'm encouraging bad coding, or
> stupidity, but I'm being a realist. Once all market share is captured,
> THEN you can begin to gradually enforce whichever standards are the
> best. But until then, it's a free-for-all.

Websites all break in different ways. It's impossible to care about all
of them.

> I truly do appreciate your perspective. I did a little research on
> you, and you appear to be a very intelligent individual, although (and
> I don't mean to be destructively critical) a bit of an idealist/
> purist--which the world does need, but isn't the way the world works.

What's your point? You're looking for points against prototype, but
whenever points follow you dismiss them with empty statements.


> Again, if they are so trivial, why wouldn't a "good" library have been
> written?

Perhaps mine *could* be better. But I don't want to put in all the
effort needed for proper testing and documentation. And I deem those
things important, when publicising a library (contrary to the prototype
authors). Other authors might have similar or other reasons.

> Wouldn't evolution cause the "good" librarues to bubble up
> and become the de facto standard? Wouldn't "bad libraries" break in
> future revs, independent browsers, etc, and the "good libraries" gain
> mind- and market-share with each manifestation of the "bad
> libararies'" failure?

I suppose that's the reason, why the least standards compliant browser
has the marginal market share of, say, 80 percent?

nolo contendere

unread,
Nov 13, 2007, 12:14:38 PM11/13/07
to
On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> nolo contendere meinte:
>
> > Again, this may be the browser's fault then. Bear in mind that browser
> > developers do have to cater to existing web pages, and have all sorts
> > of testing to try to ensure that nothing breaks in future versions.
>
> You know what? There are websites (not conforming to standards, sure),
> wich looked perfectly ok on IE6, but break more or less seriously on IE7.

Of course, I'm saying that the future versions of browsers would make
the attempt to break as few sites out there as possible. If the
majority of sites DON'T conform to ECMA standards, the deveoplers will
cater towards THAT first, and not the standards.

>
> > I highly doubt that just because a page doesn't conform to ECMA
> > standards, the browser developers will say "screw that web page, if
> > they don't follow ECMA they don't get a proper rendering in our
> > browser." This may work if the percentage of "bad" web pages were
> > vanishingly small, but hey, this is the real world where people are
> > stupid and market share is of vital importance to a browser's
> > continued existence. I'm not saying I'm encouraging bad coding, or
> > stupidity, but I'm being a realist. Once all market share is captured,
> > THEN you can begin to gradually enforce whichever standards are the
> > best. But until then, it's a free-for-all.
>
> Websites all break in different ways. It's impossible to care about all
> of them.
>
> > I truly do appreciate your perspective. I did a little research on
> > you, and you appear to be a very intelligent individual, although (and
> > I don't mean to be destructively critical) a bit of an idealist/
> > purist--which the world does need, but isn't the way the world works.
>
> What's your point? You're looking for points against prototype, but
> whenever points follow you dismiss them with empty statements.

No, I don't dismiss them. I appreciate the points. My argument is that
however wonderful the vision is of a completely standards compliant
web, reality differs. It's pointless to rail against something one
deems "bad", and not do anything about it. Either adapt, or strive to
improve it. Here, Robert does strive to improve it a little by
engaging in this discussion, but his efforts would be more fruitful
simply to come up with a better library.

>
> > Again, if they are so trivial, why wouldn't a "good" library have been
> > written?
>
> Perhaps mine *could* be better. But I don't want to put in all the
> effort needed for proper testing and documentation. And I deem those
> things important, when publicising a library (contrary to the prototype
> authors). Other authors might have similar or other reasons.

So by saying that you need all that effort, you are contradicting the
statement that it is trivially easy. You can't have it both ways.

>
> > Wouldn't evolution cause the "good" librarues to bubble up
> > and become the de facto standard? Wouldn't "bad libraries" break in
> > future revs, independent browsers, etc, and the "good libraries" gain
> > mind- and market-share with each manifestation of the "bad
> > libararies'" failure?
>
> I suppose that's the reason, why the least standards compliant browser
> has the marginal market share of, say, 80 percent?

You're missing the point. I'm saying if you have enough market share,
rightly or wrongly, you MAKE the standards.

Thomas 'PointedEars' Lahn

unread,
Nov 13, 2007, 12:31:41 PM11/13/07
to
nolo contendere wrote:
> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>> nolo contendere meinte:
>>> Again, this may be the browser's fault then. Bear in mind that browser
>>> developers do have to cater to existing web pages, and have all sorts
>>> of testing to try to ensure that nothing breaks in future versions.
>> You know what? There are websites (not conforming to standards, sure),
>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> Of course, I'm saying that the future versions of browsers would make
> the attempt to break as few sites out there as possible. If the
> majority of sites DON'T conform to ECMA standards, the deveoplers will
> cater towards THAT first, and not the standards.

And therefore writing non-standard code that breaks *now* is a good thing?
That's just ridiculous.

>>> Wouldn't evolution cause the "good" librarues to bubble up
>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>> future revs, independent browsers, etc, and the "good libraries" gain
>>> mind- and market-share with each manifestation of the "bad
>>> libararies'" failure?
>> I suppose that's the reason, why the least standards compliant browser
>> has the marginal market share of, say, 80 percent?
>
> You're missing the point. I'm saying if you have enough market share,
> rightly or wrongly, you MAKE the standards.

That is what companies like Microsoft want naive people like you to believe.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

nolo contendere

unread,
Nov 13, 2007, 12:48:35 PM11/13/07
to
On Nov 13, 1:31 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> nolo contendere wrote:
> > On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> >> nolo contendere meinte:
> >>> Again, this may be the browser's fault then. Bear in mind that browser
> >>> developers do have to cater to existing web pages, and have all sorts
> >>> of testing to try to ensure that nothing breaks in future versions.
> >> You know what? There are websites (not conforming to standards, sure),
> >> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> > Of course, I'm saying that the future versions of browsers would make
> > the attempt to break as few sites out there as possible. If the
> > majority of sites DON'T conform to ECMA standards, the deveoplers will
> > cater towards THAT first, and not the standards.
>
> And therefore writing non-standard code that breaks *now* is a good thing?
> That's just ridiculous.
>

Why do you infer that the non-standard code breaks now? Richard's
stance was that it DOES work, albeit coincidentally.

> >>> Wouldn't evolution cause the "good" librarues to bubble up
> >>> and become the de facto standard? Wouldn't "bad libraries" break in
> >>> future revs, independent browsers, etc, and the "good libraries" gain
> >>> mind- and market-share with each manifestation of the "bad
> >>> libararies'" failure?
> >> I suppose that's the reason, why the least standards compliant browser
> >> has the marginal market share of, say, 80 percent?
>
> > You're missing the point. I'm saying if you have enough market share,
> > rightly or wrongly, you MAKE the standards.
>
> That is what companies like Microsoft want naive people like you to believe.

I don't think I'm being naive. I think hoping/expecting/suggesting
that no one use "imperfect" libraries is naive. If you disagree with
the status quo, and you know better and have the ability, make change.

Gregor Kofler

unread,
Nov 13, 2007, 1:09:44 PM11/13/07
to
nolo contendere meinte:

> Why do you infer that the non-standard code breaks now? Richard's
> stance was that it DOES work, albeit coincidentally.

This very example. Richard picked an example to illustrate the bad code
quality, nothing else.

> I don't think I'm being naive. I think hoping/expecting/suggesting
> that no one use "imperfect" libraries is naive.

I'd say no one on clj hopes/expects/suggests that *no one* uses
imperfect libraries. However, if one is willing and able, there might be
better ways.

Anyway, since you are perfectly satisfied with prototype and can live
with it's shortcomings: use it, and end this futile discussion.

EOD, Gregor

Randy Webb

unread,
Nov 13, 2007, 1:52:55 PM11/13/07
to
nolo contendere said the following on 11/13/2007 12:14 PM:

> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>> nolo contendere meinte:
>>
>>> Again, this may be the browser's fault then. Bear in mind that browser
>>> developers do have to cater to existing web pages, and have all sorts
>>> of testing to try to ensure that nothing breaks in future versions.
>> You know what? There are websites (not conforming to standards, sure),
>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> Of course, I'm saying that the future versions of browsers would make
> the attempt to break as few sites out there as possible. If the
> majority of sites DON'T conform to ECMA standards, the deveoplers will
> cater towards THAT first, and not the standards.

I have been saying that in this group for years. Give up, it doesn't do
any good.

90% of the people that write Javascript don't know what ECMAScript is.
Of the remaining 10%, 90% of those don't care what ECMAScript is.
The other 1% post here proclaiming it as the savior of Javascript.

ECMAScript, in its current incarnation, was nothing more than an effort
to "standardize" what was already in place. And probably for no other
reason than to be able to say "There is a standard". And, it was a
stroke of marketing/research genius on the part of Microsoft.

It was Richard, not Robert, but, I don't think Richard was trying to
improve on Prototype.js as much as show the flaws in it. There is
another one that is, perhaps without a doubt, the mostly hotly debated
in this group and that is the use of $ as a function name. The main
issue is "ECMAScript says it is intended for machine generated code" and
people grasp onto that and want to condemn the practice simply because
"ECMAScript says so".

The $ function itself is another area where it could be improved simply
by removing some of it. It is over-written for what it is used for.

>>> Wouldn't evolution cause the "good" librarues to bubble up
>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>> future revs, independent browsers, etc, and the "good libraries" gain
>>> mind- and market-share with each manifestation of the "bad
>>> libararies'" failure?
>> I suppose that's the reason, why the least standards compliant browser
>> has the marginal market share of, say, 80 percent?
>
> You're missing the point. I'm saying if you have enough market share,
> rightly or wrongly, you MAKE the standards.

I don't think they "make" the standard as much as they "become" the
standard. Microsoft drives this market, whether people admit it or not.
It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
out next week and proclaimed "The only markup language we will support
in the future is MSML(Microsoft Markup Language), the only script
language we will support is MSScript (Microsoft Script), and nothing
else". Then the rest of the browser world would flip on it's head in an
effort to support them and the W3C would become a thing of the past.

Randy Webb

unread,
Nov 13, 2007, 1:54:20 PM11/13/07
to
Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:

> nolo contendere wrote:
>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>> nolo contendere meinte:
>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>> developers do have to cater to existing web pages, and have all sorts
>>>> of testing to try to ensure that nothing breaks in future versions.
>>> You know what? There are websites (not conforming to standards, sure),
>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>> Of course, I'm saying that the future versions of browsers would make
>> the attempt to break as few sites out there as possible. If the
>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>> cater towards THAT first, and not the standards.
>
> And therefore writing non-standard code that breaks *now* is a good thing?
> That's just ridiculous.

What is more ridiculous is to believe that everybody is going to write
"perfect" code. Now or ever.

>>>> Wouldn't evolution cause the "good" librarues to bubble up
>>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>>> future revs, independent browsers, etc, and the "good libraries" gain
>>>> mind- and market-share with each manifestation of the "bad
>>>> libararies'" failure?
>>> I suppose that's the reason, why the least standards compliant browser
>>> has the marginal market share of, say, 80 percent?
>> You're missing the point. I'm saying if you have enough market share,
>> rightly or wrongly, you MAKE the standards.
>
> That is what companies like Microsoft want naive people like you to believe.

Oh monkeys ass.

nolo contendere

unread,
Nov 13, 2007, 2:02:08 PM11/13/07
to

LMMAO!

Doug Miller

unread,
Nov 13, 2007, 2:09:30 PM11/13/07
to
In article <tb2dnRIadto...@giganews.com>, Randy Webb <HikksNo...@aol.com> wrote:
>Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>
>> And therefore writing non-standard code that breaks *now* is a good thing?
>> That's just ridiculous.
>
>What is more ridiculous is to believe that everybody is going to write
^^^^^^^^^

>"perfect" code. Now or ever.

You misspelled "anybody". <g>

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Thomas 'PointedEars' Lahn

unread,
Nov 13, 2007, 2:20:37 PM11/13/07
to
Randy Webb wrote:
> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>> nolo contendere wrote:
>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>> nolo contendere meinte:
>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>> You know what? There are websites (not conforming to standards, sure),
>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>> Of course, I'm saying that the future versions of browsers would make
>>> the attempt to break as few sites out there as possible. If the
>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>> cater towards THAT first, and not the standards.
>> And therefore writing non-standard code that breaks *now* is a good thing?
>> That's just ridiculous.
>
> What is more ridiculous is to believe that everybody is going to write
> "perfect" code. Now or ever.

I did not state anything about "perfect code", you just made that up. That
aside, technical newsgroups like this exist to increase understanding. If
no poster would believe that it is possible to convince a reasonable number
of readers that it is better to write good code, this newsgroup would have
lost its purpose and all people who post now could stop posting.

That it still exists, and that people knowing more still provide people
knowing less with corrections, suggestions and better code proves that you
are utterly wrong.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Matt Kruse

unread,
Nov 13, 2007, 3:31:38 PM11/13/07
to
On Nov 13, 1:20 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> That
> aside, technical newsgroups like this exist to increase understanding.

And also to inflate the egos of people have a good technical
understanding and want to flaunt it for all to see by criticizing
everyone they can. It's amusing to watch sometimes.

This group exists for more than to simply reduce all problems to the
most efficient and standards-compliant code that could possibly be
written. There are Javascript-related questions that are only
partially technical. For example, recent discussions on libraries
point out that people have different priorities. If someone comes here
looking for advice on the pros and cons of library X, the technical
issues with the library is only part of the equation. Even if a
library has technical problems, using it still may be the best
business decision, and that overall discussion is still Javascript-
related.

Technical perfection is not _THE_ goal, but _A_ goal.

Critiques of code and offering advice on why it is good or bad and how
it could be improved is a great thing that should always be welcome.
But not at the expense of discussing what the OP is really trying to
figure out. That's where so many regulars on this group get it wrong.
IMO.

I would still like to see answers from some of the hardcore critics
here about real-world situations and what they would recommend when
real-world problems and priorities need to be taken into
consideration. When technical merit is probably not the #1 concern,
but maybe down the list a bit. Then falling back to the same old
"libraries suck" arguments and pointing to all coding practices that
conflict with the "standards" do you no good, and many here don't seem
to be able to carry on an intelligent conversation once their mantra
is irrelevant.

Matt Kruse

Randy Webb

unread,
Nov 13, 2007, 7:58:33 PM11/13/07
to
Thomas 'PointedEars' Lahn said the following on 11/13/2007 2:20 PM:

> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>> nolo contendere wrote:
>>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>>> nolo contendere meinte:
>>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>>> You know what? There are websites (not conforming to standards, sure),
>>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>>> Of course, I'm saying that the future versions of browsers would make
>>>> the attempt to break as few sites out there as possible. If the
>>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>>> cater towards THAT first, and not the standards.
>>> And therefore writing non-standard code that breaks *now* is a good thing?
>>> That's just ridiculous.
>> What is more ridiculous is to believe that everybody is going to write
>> "perfect" code. Now or ever.
>
> I did not state anything about "perfect code", you just made that up.

Let me check and re-read what I wrote. Nope, I never said you stated
anything about perfect code. Nope, sure didn't. Do you see where I did?
Didn't think so. Now, who is "making things up"?

> That aside, technical newsgroups like this exist to increase understanding.

No, that is not why they exist. If understanding is increased then it is
a by-product, not the product of the group.

> If no poster would believe that it is possible to convince a reasonable number
> of readers that it is better to write good code, this newsgroup would have
> lost its purpose and all people who post now could stop posting.

Your problem is you think that any code that doesn't follow some
"standard" to the letter isn't "good code". You couldn't be further from
the truth when it comes to writing cross-browser scripts for the web.

> That it still exists, and that people knowing more still provide people
> knowing less with corrections, suggestions and better code proves that you
> are utterly wrong.

You should endeavor to understand what it is that you are whining about
before you whine about it.

dhtmlk...@gmail.com

unread,
Nov 13, 2007, 8:46:15 PM11/13/07
to
that's one issue. The other is that it's not semantic.

A method should do what it says. What does $ say it does? If it were a
shortcut to document.getElementById, I'd call unnecessary delegation,
but that's not the case.

The $ has been so overloaded to do xpath, et c in jQuery. In a way,
it's like those html pages where every tag is div.

> The $ function itself is another area where it could be improved simply
> by removing some of it. It is over-written for what it is used for.
>

I'm in complete agreement. All the getBySelector functionality. YAGNI.
The only one time I needed something like that was when I wrote the
CssEditor, and then I really needed to parse the styleSheet and
capture clicks on elements matching the most specific selector.

Another place it was used is Selenium, although I do not use those
selectors in Selenium becauise selenium already has xpath which is
very good at what it does.

> >>> Wouldn't evolution cause the "good" librarues to bubble up
> >>> and become the de facto standard? Wouldn't "bad libraries" break in
> >>> future revs, independent browsers, etc, and the "good libraries" gain
> >>> mind- and market-share with each manifestation of the "bad
> >>> libararies'" failure?
> >> I suppose that's the reason, why the least standards compliant browser
> >> has the marginal market share of, say, 80 percent?
>
> > You're missing the point. I'm saying if you have enough market share,
> > rightly or wrongly, you MAKE the standards.
>
> I don't think they "make" the standard as much as they "become" the
> standard. Microsoft drives this market, whether people admit it or not.
> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
> out next week and proclaimed "The only markup language we will support
> in the future is MSML(Microsoft Markup Language), the only script
> language we will support is MSScript (Microsoft Script), and nothing
> else". Then the rest of the browser world would flip on it's head in an
> effort to support them and the W3C would become a thing of the past.
>

I doubt that. So many HTML pages now, and people need to log in to
their pages, et c. If IE doesn't support that feature (HTML) then it
would fall out of favor. MS would have to get users on to a new
platform first, and get enogh pgs developed on that platrofm to make
it really attractiuve,.

Thomas 'PointedEars' Lahn

unread,
Nov 14, 2007, 4:19:05 AM11/14/07
to
Randy Webb wrote:
> Thomas 'PointedEars' Lahn said the following on 11/13/2007 2:20 PM:
>> Randy Webb wrote:
>>> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>>> nolo contendere wrote:
>>>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>>>> nolo contendere meinte:
>>>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>>>> You know what? There are websites (not conforming to standards, sure),
>>>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>>>> Of course, I'm saying that the future versions of browsers would make
>>>>> the attempt to break as few sites out there as possible. If the
>>>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>>>> cater towards THAT first, and not the standards.
>>>> And therefore writing non-standard code that breaks *now* is a good thing?
>>>> That's just ridiculous.
>>> What is more ridiculous is to believe that everybody is going to write
>>> "perfect" code. Now or ever.
^^^^^^^^^^^^^^

>> I did not state anything about "perfect code", you just made that up.
>
> Let me check and re-read what I wrote. Nope, I never said you stated
> anything about perfect code. Nope, sure didn't. Do you see where I did?

As you appear to have impaired vision, I have marked it for you above.

> Didn't think so. Now, who is "making things up"?

You are.

>> That aside, technical newsgroups like this exist to increase understanding.
>
> No, that is not why they exist. If understanding is increased then it is
> a by-product, not the product of the group.

A matter of opinion.

>> If no poster would believe that it is possible to convince a reasonable number
>> of readers that it is better to write good code, this newsgroup would have
>> lost its purpose and all people who post now could stop posting.
>
> Your problem is you think that any code that doesn't follow some
> "standard" to the letter isn't "good code". You couldn't be further from
> the truth when it comes to writing cross-browser scripts for the web.

You are an idiot. Any code has to be written according to some convention
or it could not qualify as good code; that is, code that does not only run
in a single test environment. Adhering to the convention of a standard,
especially *the* international standard for the programming language, is
vital for it to become interoperable. Without that property, it definitely
qualifies as bad code.

Gregor Kofler

unread,
Nov 14, 2007, 4:22:08 AM11/14/07
to
Randy Webb meinte:

> I don't think they "make" the standard as much as they "become" the
> standard. Microsoft drives this market, whether people admit it or not.
> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
> out next week and proclaimed "The only markup language we will support
> in the future is MSML(Microsoft Markup Language), the only script
> language we will support is MSScript (Microsoft Script), and nothing
> else". Then the rest of the browser world would flip on it's head in an
> effort to support them and the W3C would become a thing of the past.

Come on... MS isn't even able to make their IE7 the "standard" browser.
People stick rather to the wretched interface of IE6, than "learn" to
use the added comfort of alternative products.

Randy Webb

unread,
Nov 14, 2007, 5:12:27 AM11/14/07
to
Thomas 'PointedEars' Lahn said the following on 11/14/2007 4:19 AM:

Let me try, desperately, to explain plain English to you Thomas. I know
it is difficult for you to comprehend as it is not your native language.
As difficult as this is going to be, I am still going to try. Ready?

Thomas said: "writing non-standard code...."
Randy added: "What is more ridiculous....."

To which you replied and accused me of saying you said anything about
perfect code. I never said you did. Now, if you can "mark" for me where
I said you said anything about perfect code, then please do so.
Otherwise, you are still whining about something that didn't happen.

Your move.

>> Didn't think so. Now, who is "making things up"?
>
> You are.

See above. And then try again.

>>> That aside, technical newsgroups like this exist to increase understanding.
>> No, that is not why they exist. If understanding is increased then it is
>> a by-product, not the product of the group.
>
> A matter of opinion.

And what the outdated charter of this group has to say.

>>> If no poster would believe that it is possible to convince a reasonable number
>>> of readers that it is better to write good code, this newsgroup would have
>>> lost its purpose and all people who post now could stop posting.
>> Your problem is you think that any code that doesn't follow some
>> "standard" to the letter isn't "good code". You couldn't be further from
>> the truth when it comes to writing cross-browser scripts for the web.
>
> You are an idiot.

<URL: http://en.wikipedia.org/wiki/Idiot>

<quote>
Its modern meaning and form dates back to Middle English around the year
1300, from the Old French idiote ("uneducated or ignorant person").
</quote>

Specifically, the part about "uneducated". Since every person on this
planet is uneducated about something in some form or fashion, your
attempt to insult me was nowhere near as successful as you would like
for it to have been.

Try again Thomas, you failed.

> Any code has to be written according to some convention or it could
> not qualify as good code; that is, code that does not only run
> in a single test environment.

I wrote nothing about conventions, I wrote about it conforming to a
"standard", in this case the ECMAScript standard.

> Adhering to the convention of a standard, especially *the* international
> standard for the programming language, is vital for it to become
> interoperable. Without that property, it definitely qualifies as bad code.

So, you are saying that if code doesn't "adhere to the international
standard" for javascript, then it is "bad code"? Be careful because
there are a lot of things that you have to do in IE that doesn't adhere
to the "standards" but it won't work if you make your code adhere
strictly to that standard. Must mean you have to write "bad code" in
order for it to be "cross-browser". And that leads right back to what I
said. Code that is cross-browser can be good, solid code and not even
come close to adhering to a "standard".

Now, since you can't adhere strictly to that standard, and you are
producing "bad code" because of it, then you can't possibly write "good
cross-browser scripts". Of course, you can prove me wrong here. Simple
actually. I only have to give you one example of where you can't write
strictly standard code and have it cross-browser to prove you wrong. So,
to prove me wrong, all you have to do is write a cross-browser
compatible script that adheres *strictly* to the "standards" with these
requirements:

Given a string of JS Code, create a script element and have the browser
execute that code in proper context. Pretty simple huh? I will give you
a hint though, you can't do it as IE won't handle createTextNode
properly and you have to fall back on a proprietary method to pull it off.

You really should take more care in trying to understand what you read.

Randy Webb

unread,
Nov 14, 2007, 9:54:45 PM11/14/07
to
dhtmlk...@gmail.com said the following on 11/13/2007 8:46 PM:

> On Nov 13, 10:52 am, Randy Webb <HikksNotAtH...@aol.com> wrote:

<snip>

>> It was Richard, not Robert, but, I don't think Richard was trying to
>> improve on Prototype.js as much as show the flaws in it. There is
>> another one that is, perhaps without a doubt, the mostly hotly debated
>> in this group and that is the use of $ as a function name. The main
>> issue is "ECMAScript says it is intended for machine generated code" and
>> people grasp onto that and want to condemn the practice simply because
>> "ECMAScript says so".
>>
> that's one issue. The other is that it's not semantic.
>
> A method should do what it says. What does $ say it does? If it were a
> shortcut to document.getElementById, I'd call unnecessary delegation,
> but that's not the case.

No, that is not all that $ does in Prototype. Far from it. In fact, it
is so convoluted you would have a hard time coming up with a "semantic"
name for it that was under about 20 characters or so.

As for "unnecessary delegation", I can see a benefit to having a wrapper
function as long as the function handled feature detection. Then you
wouldn't have to write this every time:

if (document.getElementById){
//
}

You could simply write:
getRef('someElement')
And then have the function getRef handle the feature detection.

But, most of the discussions about the use of $ don't center on the
semantics of it (although it has been mentioned in the past), the
discussion centers on the "ECMAScript says don't do it" aspect of it.

> The $ has been so overloaded to do xpath, et c in jQuery. In a way,
> it's like those html pages where every tag is div.

Honestly, I have never looked at jQuery other than seeing snippets of it
here so I can't comment on it. The only reason I have looked at
Prototype.js lately is because of this thread.

<snip>

>> I don't think they "make" the standard as much as they "become" the
>> standard. Microsoft drives this market, whether people admit it or not.
>> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
>> out next week and proclaimed "The only markup language we will support
>> in the future is MSML(Microsoft Markup Language), the only script
>> language we will support is MSScript (Microsoft Script), and nothing
>> else". Then the rest of the browser world would flip on it's head in an
>> effort to support them and the W3C would become a thing of the past.
>>
> I doubt that. So many HTML pages now, and people need to log in to
> their pages, et c. If IE doesn't support that feature (HTML) then it
> would fall out of favor. MS would have to get users on to a new
> platform first, and get enogh pgs developed on that platrofm to make
> it really attractiuve,.

Let me clarify it a little differently as it is a little ambiguous as I
wrote it. If MS came out and said:

<conjecture>
The only way IE will process a script block is if it is formatted in
this manner:

<script type="MSScript">
//script code here
</script>

Furthermore, if any other attributes are present, IE will ignore the
script block.
</conjecture>

Then you would see a TON of webpages get changed in a hurry. Would they
ever do it? No. Could they do it and make it work? Absolutely. It is a
bad side effect of having a dominating monopoly over the browser area.

Want a real world example though? XHTML. MS snubbed there noses at it
and now it's a dead language. Not because it was bad, not because of
anything other than the fact that MS doesn't support it. Not saying
there aren't uses for it (there are). But for the web itself, it is a
pretty dead language.

Microsoft didn't gain that advantage by offering a better product, they
gained it by brute force of forcing IE onto the desktop and then
integrating it into the OS.

Now that we are way off topic, I don't want to continue having a
discussion about MS and the problems with it. Let's just get back to
Prototype.js :)

--
Randy
Chance Favors The Prepared Mind

Randy Webb

unread,
Nov 14, 2007, 9:56:34 PM11/14/07
to
Gregor Kofler said the following on 11/14/2007 4:22 AM:

> Randy Webb meinte:
>
>> I don't think they "make" the standard as much as they "become" the
>> standard. Microsoft drives this market, whether people admit it or
>> not. It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS
>> came out next week and proclaimed "The only markup language we will
>> support in the future is MSML(Microsoft Markup Language), the only
>> script language we will support is MSScript (Microsoft Script), and
>> nothing else". Then the rest of the browser world would flip on it's
>> head in an effort to support them and the W3C would become a thing of
>> the past.
>
> Come on... MS isn't even able to make their IE7 the "standard" browser.
> People stick rather to the wretched interface of IE6, than "learn" to
> use the added comfort of alternative products.

If, and only if, they are made aware of the alternative product and MS
does a damn spiffy job of attempting to hide that fact. You can't get a
new Windows based PC manufacturer to pre-install a different browser
because MS won't allow it.

Thomas 'PointedEars' Lahn

unread,
Nov 15, 2007, 5:17:53 AM11/15/07
to
Randy Webb wrote:
> [...] You can't get a new Windows based PC manufacturer to pre-install a

> different browser because MS won't allow it.

Yes, you can. M$ has lost that case already, and it is unlikely they will
try again.

Randy Webb

unread,
Nov 15, 2007, 6:06:49 AM11/15/07
to
Thomas 'PointedEars' Lahn said the following on 11/15/2007 5:17 AM:

> Randy Webb wrote:
>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>> different browser because MS won't allow it.
>
> Yes, you can. M$ has lost that case already, and it is unlikely they will
> try again.

Whatever you say, kiddie. It doesn't help your credibility any when you
fall prey to the "cool" stuff like referring to Microsoft as M$, it
detracts from it.

Thomas 'PointedEars' Lahn

unread,
Nov 15, 2007, 7:36:34 AM11/15/07
to
Randy Webb wrote:
> Thomas 'PointedEars' Lahn said the following on 11/15/2007 5:17 AM:
>> Randy Webb wrote:
>>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>>> different browser because MS won't allow it.
>> Yes, you can. M$ has lost that case already, and it is unlikely they will
>> try again.
>
> Whatever you say, kiddie. It doesn't help your credibility any when you
> fall prey to the "cool" stuff like referring to Microsoft as M$, it
> detracts from it.

| Learn to read what you are replying to.
| Learn to understand what other people have written.
| Learn the basic vocabulary of a culture you are participating in.
-- Harald Blahovec (translated)

That said, we are pretty much off-topic already with *your* introducing
Microsoft into the equation. Speaking of which, they do have paid a lot
of $s as results of the lawsuits and appeals of competitors against the
aforementioned practice :)

VK

unread,
Nov 15, 2007, 10:33:47 AM11/15/07
to
On Nov 12, 8:16 pm, nolo contendere <simon.c...@fmr.com> wrote:
> I had not realized prototype.js was such a hot topic

For two years at least or even more. More exactly: the usage of
"solution size" libraries in JavaScript as such, prototype.js is just
a banner of this fight IMHO :-)

I personally do not stand with the kind of argument "as the result
people will not learn JavaScript". One may think that the the whole
army of C++ programmers spending their days in for(x=y;x<z;++x) and
similar programming. Just give me a break! 95% of programming in an
average company consists of linking and registering different
libraries, calling their methods over pre-filled drop-downs and
searching through the help what a hey method does what I need in
A=>B=>C=>D=>E=>F=>G=>H object - the last often is the main time
consumer :-) I now some libraries that came into life exactly because
it was quicker to write something of your own rather than memorize
some too weird named or placed properties and methods of a 3rd party
library.

IMHO there are two differences and problems for JavaScript libraries.
1) All DLL are written with Windows and Visual Studio in mind.
Respectively if one registered a new DLL and some weird stuff started,
normally one files complain/bug report to DLL producer. JavaScript
libraries are some creations "out of time and space". So it is often
some one linked Dojo, jQuery, Prototype and a couple more, the browser
gets crazy of it, and where to look for help? Who has to get your bug
report (or misuse explanation)? Often clj is chosen for that for the
lack of any other evident place - and I definitely understand that
people here are refusing to accept the role of a world-wide free 3rd
party libraries maintenance and correction.

2) The formation of JavaScript libraries was and remains up till now a
totally anarchical process. There is not any RFC or any other commonly
accepted technical documents about JavaScript structuring,
interfacing, naming or documenting. As a result the progress in the
area reminds me a bunch of ants dragging something big to the ant
house: it seems like everyone is working together but really each one
is pushing to his own side, so the slow movement happens only because
the resulting vector is a bit above zero and going to the right
direction. :-)

Randy Webb

unread,
Nov 16, 2007, 9:45:51 AM11/16/07
to
Thomas 'PointedEars' Lahn said the following on 11/15/2007 7:36 AM:

> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 11/15/2007 5:17 AM:
>>> Randy Webb wrote:
>>>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>>>> different browser because MS won't allow it.
>>> Yes, you can. M$ has lost that case already, and it is unlikely they will
>>> try again.
>> Whatever you say, kiddie. It doesn't help your credibility any when you
>> fall prey to the "cool" stuff like referring to Microsoft as M$, it
>> detracts from it.
>
> | Learn to read what you are replying to.
> | Learn to understand what other people have written.
> | Learn the basic vocabulary of a culture you are participating in.
> -- Harald Blahovec (translated)
>
> That said, we are pretty much off-topic already with *your* introducing
> Microsoft into the equation. Speaking of which, they do have paid a lot
> of $s as results of the lawsuits and appeals of competitors against the
> aforementioned practice :)

I would tell you that your intelligence level is beginning to remind me
of VK, but, I don't want to insult VK like that so I won't.

P.S. Fix your signature.

dhtmlk...@gmail.com

unread,
Nov 16, 2007, 3:19:49 PM11/16/07
to
> I don't mean to be destructively critical) a bit of...
>
> read more >>

I think the idea here is looking at the code is a good idea.

There will always be bugs. (browsers are a good example) Some bugs you
can live with, others are too unacceptable.

Mistakes and misconceptions are different.

Looking at code can show how the author thinks. Mistakes are one
thing, but when a script is written with misconceptions, well, it kind
of makes you look sideways at the script.

VK

unread,
Nov 16, 2007, 5:47:52 PM11/16/07
to
On Nov 16, 5:45 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> I would tell you that your intelligence level is beginning to remind me
> of VK, but, I don't want to insult VK like that so I won't.

You mean that VK needs a special profoundly thought insult, not a
simplified spontaneous one? :-)

Randy Webb

unread,
Nov 16, 2007, 7:19:51 PM11/16/07
to
VK said the following on 11/16/2007 5:47 PM:

Geez, just when I thought you might be using your brain, you prove me wrong.

If telling PointedHead that he is acting like you is an insult to you,
that means he is acting worse than you. But now, I am not so sure anymore.

VK

unread,
Nov 17, 2007, 7:12:37 AM11/17/07
to
On Nov 17, 3:19 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
> If telling PointedHead that he is acting like you is an insult to you,
> that means he is acting worse than you.

So is it a compliment to me? OK, but also can be read as an insult to
PointedEars (or anyone else in the future): "You are worser than VK" -
so "really ground bottom". A too complex statement for simple minds
like mine :-)

Randy Webb

unread,
Nov 17, 2007, 1:24:41 PM11/17/07
to
VK said the following on 11/17/2007 7:12 AM:

> On Nov 17, 3:19 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> If telling PointedHead that he is acting like you is an insult to you,
>> that means he is acting worse than you.
>
> So is it a compliment to me?

Don't get your hopes up :)

> OK, but also can be read as an insult to PointedEars (or anyone else in the future):

You are beginning to grasp it.

> "You are worser than VK" - so "really ground bottom".

I am proud of you. It only took you three posts to figure that out.

> A too complex statement for simple minds like mine :-)

No comment :)

VK

unread,
Nov 17, 2007, 2:09:48 PM11/17/07
to
<OT>

> >> If telling PointedHead that he is acting like you is an insult to you,
> >> that means he is acting worse than you.
>
> > So is it a compliment to me?
>
> Don't get your hopes up :)
>
> > OK, but also can be read as an insult to PointedEars (or anyone else in the future):
>
> You are beginning to grasp it.
>
> > "You are worser than VK" - so "really ground bottom".
>
> I am proud of you. It only took you three posts to figure that out.

Oh... But from the other side "there are people worser then you, VK,
so be proud of"; but from the other side "you're getting worser than
VK, PointedEars, so try to shape up"; but also can be read as ...
Did you you ever tried for a White House PR representative? You would
pass the sort out tests for sure.
:-)

</OT>

Dr J R Stockton

unread,
Nov 17, 2007, 2:19:56 PM11/17/07
to
In comp.lang.javascript message <8db60425-1b85-42ae-8744-d522680d9b2a@s1
2g2000prg.googlegroups.com>, Fri, 16 Nov 2007 12:19:49,
"dhtmlk...@gmail.com" <dhtmlk...@gmail.com> posted:

Lines: 253
>> ... ... ...


>
>I think the idea here is looking at the code is a good idea.
>
>There will always be bugs. (browsers are a good example) Some bugs you
>can live with, others are too unacceptable.
>
>Mistakes and misconceptions are different.
>
>Looking at code can show how the author thinks. Mistakes are one
>thing, but when a script is written with misconceptions, well, it kind
>of makes you look sideways at the script.

Please trim your quotes. See FAQ 2.3.

--
(c) John Stockton, Surrey, UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.

Richard Cornford

unread,
Nov 17, 2007, 9:47:32 PM11/17/07
to
nolo contendere wrote:

> On Nov 12, 8:45 pm, Richard Cornford wrote:
>> nolo contendere wrote:
>>> I've recently begun playing with prototype.js as well
>>> as scriptaculous, and found both very helpful in
>>> developing web pages with lots of pop. Modal boxes,
>>> SlideUp/Down, calendars, etc.
>>
>>> I've also recently ramped up my lurking and participation
>>> in this newsgroup. There are some who advocate using
>>> prototype,
>>
>> Here?
>
> In this very thread in fact.

If you are talking about "s0lnic" then you should note that he has
hardly made a dozen posts in the last 3 month and the only code he has
posted featured the usual cross-browser error and needed to be corrected
before it was fit for its proposed purpose.

>>> and others who are adamantly opposed to it. Are there
>>> any concrete reasons why I should NOT use it?
>>
>> Lots, but I don't have time to go through all of them
>> right now. However, one good illustration is the least
>> you deserve.
>
> I appreciate it.
>
>> Take this code form the latest (1.6.0) version of Prototype.js:-

<snip>
>> - What this appears to represent ...
<snip>


>> Now if this code 'works' at all it 'works' mostly by

>> coincidence ...
<snip>


>> Of course the conditional creation of function objects is
>> trivial in javascript in a way that fully conforms with

>> the ECMAScript specification, ...
<snip>
>>... and so will 'work' consistently in all past, present


>> and future ECMA 262 3rd Ed. conforming implementations.
>
> Why has a library not been written this way?

In what way? Such that the code used conforms to language's
specification and does not rely on inconsistent implementation details?
Lots of libraries have been written in that way. For example I have not
yet noticed anything in dojo that relies upon language extensions or
non-standard implementation features. Granted the evidence that dojo's
authors don't understand the code they are writing suggests that that
is itself probably best attributed to coincidence, but still it is the
case.

> Obviously it's not your responsibility to do it, or to even
> know the reason why it hasn't been done thus far,

Except it has been done, and is probably the norm, even in otherwise
very dubious library code.

> but if so many people are in error, and it causes you
> any distress,

What makes you think it causes me any distress? I am massively cynical,
so a world where idleness, ignorance, ineptitude and incompetence are
endemic is reassuring (almost comforting).

> it would behoove you to write one, or at
> least begin one.

One what? A general-purpose library? Doesn't that imply a
presupposition that a general-purpose library would be
something that would be useful to have? If that a-priori
assumption is not itself valid then creating such an object
could be a bad idea and I could be entirely justified in
not spending my time pursuing folly.

> Perhaps set up a project? Clearly you care a lot about
> this subject, and have invested much time in it. This
> is just another avenue by which you can participate in
> -- and even shape -- the future of how javascript is used.

Why do I need another avenue to shape the future of how javascript is
used?

>> It is simply the case that anyone knowing javascript would
>> have written the original code in this final form. So would
>> not be writing code that functioned purely by coincidence
>> but instead they would be programming.
>>
>> The problem with the way this sort of ignorance of javascript
>> results in code that only works by coincidence is highlighted
>> by browsers like Opera. Opera currently acts like JScript,
>> and unconditionally acts on the FunctionDeclarations out of
>> their (otherwise syntax error) context but while Opera has an
>> ECMA 262 conforming javascript implementation, they also aim
>> to emulate JavaScript(tm), and so may introduce
>> JavaScript(tm)'s FunctionStatement extension at any moment.
>> And so code that works by coincidence because of the order
>> of the 'FunctionDeclarations' may find itself suddenly
>> conditionally evaluating FunctionStatements with any next
>> version of Opera, and what these branches do in that versions
>> of Opera may be totally inappropriate.
>>
>
> So this is the browser's problem.

No, it is the programmer's responsibility. The responsibility of the
browsers is no more than to correctly implement the standards that they
claim to implement. Whatever they do beyond that is up to them.

> They are too permissive.

It does appear that web browsers being permissive leads to problems when
people try to learn programming entirely by trial and error in a
restricted set of browsers and then try to move on to cross-browser
scripting.

> But if you think about it, if 90%
> of people do something one way, and that way doesn't conform
> to "the standard" (in this case, ECMA), doesn't the
> way most people do it BECOME the standard?

But what then 'becomes the standard'? The code I highlighted is amenable
to three different interpretations in web browser environments, and
actually behaves radically differently in the two most popular browsers.
Is that either JavaScript's or JScript's interpretation that 'becomes
the standard', or do you mean that it becomes the standard to be writing
code that behaves differently in each and every browser it encounters?
We tried that and it did not work, which is why the standardisation of
the language (and the DOM) was started.

One of the main reasons that it is currently possible for the uses of
javascript to be taking the directions they are taking is that
ECMAScript has been stable since the turn of the century and so its
implementations have become very complete and stable.

> It may be horrific in its
> implementation, syntax, whatever, but so is HTTP.

What is wrong with HTTP? It does precisely what it was designed to do,
and does it very well. Of course you start to see issues as soon as you
attempt to use HTTP for something other than what it was designed for,
but that is hardly surprising or unusual.

> So you either adapt
> and use it, or try to make change.
>
>> The Prototype.js approach results in code that cannot be
>> expected to work in any more browsers than those in which
>> it has been demonstrated to 'work', and so cannot even be
>> expected to 'work' with the future versions of that those
>> browsers. This cannot be a viable approach to creating
>> cross-browser code, and it does not.
>
> Again, this may be the browser's fault then.

No, it is the programmer's fault.

> Bear in mind that browser developers do have to cater to
> existing web pages, and have all sorts of testing to try
> to ensure that nothing breaks in future versions. I
> highly doubt that just because a page doesn't conform to
> ECMA standards, the browser developers will say "screw
> that web page, if they don't follow ECMA they don't get
> a proper rendering in our browser."

ECMAScript conformance has nothing what so ever to do with rendering.

Whether the Prototype.js code conforms to the ECMA standard or not was
not the issue. The issue is that the code does not actually do what its
author clearly thinks it does, and what it does do is not even the same
in the two most common browsers. Re-writing it as ECMA 262 conforming
code only acts to avoid that issue, as the code will then do the one
thing it is programmed to do, and do that same thing on (at absolute
minimum) all the browsers that Prototype.js is interested in.

It would also be possible to re-write the code so that it acted in a way
that made sense in terms of how it would be interpreted under
JavaScript(tm) and JScript, where you would short-circuit the
heavyweight - if - test on finding that the - each - function was
defined prior to the test (i.e. wherever the test was futile). The
result would not be any more cross-browser but at least it would show an
author actually programming the library instead of being at the mercy of
misconceptions and coincidence.

> This may work if the percentage of "bad" web pages were
> vanishingly small, but hey, this is the real world where people are
> stupid and market share is of vital importance to a browser's
> continued existence.

Market share has nothing to do with the existence or viability of web
browsers. Recently the growth area in web browsers has been browsers for
embedded devices (usually mobile phones), and that is simply because
that is virtually the only market where money is exchanged for web
browsers (even if indirectly). Unlike the desktop browser market where
if the user doesn't get the browser for free they go and get one form
someone else. The embedded browsers don't have much market share (yet),
but they do have the potential to fund their own development, return a
profit, and continue to exist for that reason.

> I'm not saying I'm encouraging bad coding, or
> stupidity, but I'm being a realist.

You are not being a realist. You are assuming that you have enough
information to make informed judgments about a subject while admitting
near total ignorance of the technologies involved. A realistic position
would be to recognise that you are probably not yet qualified to judge.

> Once all market share is captured, THEN you can begin to
> gradually enforce whichever standards are the best. But
> until then, it's a free-for-all.

<snip>

No web project is ever created without it's having some purpose. That
is, there is always someone who wants something from it. That
'something' may be profit/turnover, publicity, goodwill, specific
functionality, etc. (or some combination of those sorts of things). The
'professional' web developer's responsibility should be to maximise the
project's ability to achieve that 'something'. That is not a
"free-for-all", it is a knowledge driven process with a context specific
pre-defined direction.

> I truly do appreciate your perspective. I did a little
> research on you, and you appear to be a very intelligent
> individual, although (and I don't mean to be destructively

> critical) a bit of an idealist/ purist--which the world
> does need, but isn't the way the world works.

The way the world works at the moment has the demand for my (client-side
scripting) skills exceeding their supply. Which leaves me
(idealist/purist or not) selling in a seller's market and quite happy
with the outcome. And the direction javascript use has taken makes me
think that that situation is not going to change in the near future.

When my boss comes to me and says, "Can we do this thing ... ?" (as he
usually does at lest a couple of times a week) I can answer "yes", "yes,
but ..." or "no" and be pretty sure that when I say "yes" I can deliver,
when I say "yes, but ..." I am accurately enumerating the pertinent
caveats, and that when I say "no" he is not going to be able to find
anyone else who can deliver what I cannot. This while the vast bulk of
the 'competition' are operating at a level of knowledge and
understanding that is below those of the authors of the libraries that
they have learnt to be dependent upon. While the authors of those
libraries don't actually know enough to be programming with javascript.

<snip>
>>> And the benefits of being able to inject such
>>> a wide variety of effects into a page (to me) far
>>> outweigh any harm.

Can you judge the 'harm'? A while ago I was directed to a web page where
a web developer was proudly explaining how he had used a particular
rapid development process/system to create an e-commerce site, and how
easy/profitable it had been for him. He was very satisfied with the
outcome, and though his clients were also very happy with the outcome.

However, when I viewed the site using IE 6 I found that the shopping
cart did not work at all, which is pretty fatal for an e-commerce site.
Looking at the source for the site it immediately became obvious that my
problem was because of the specific configuration of my IE 6, but
simultaneously I observed that the code would only 'work' with 3 or 4
'major' desktop browsers in their default configurations.

There is a lot of nonsense talked about 'target audiences' when trying
to justify only supporting limited sets of (default configurations of)
browsers. It is a notion that starts with odd assertion that there is a
strong relationship between groupings of individuals and the web
browsers they use such that a 'target audience' implies some specific
set of web browser will be used by that audience (as opposed to
admitting the reality where anyone could be using just about any
(non-archaic) browser at all and that it is only a trivial coincidence
that the majority of them will be using the 'most common' browsers). The
'target audience' excuse also suffers from web 'statistics' problem,
where HTTP is inherently resistant to accurate browser usage statistics
gathering and most statistics gathering techniques are incapable if
distinguishing 'minor' browsers from 'major' browsers.

On the other hand the notion of 'target audiences' did have something to
contribute to this particular project because the e-commerce site in
question was selling web icon imagery. That means that its 'target
audience' is web developers, web designers and people in related fields.
While generalisations about web browser usage are inherently problematic
it certainly is the case that this particular target audience is the
target audience that is _most_ likely to be using non-standard web
browsers and web browsers in non-default configurations (because they
are the single group of users most likely to know about a wide range of
browser, have attitudes towards the browsers they use, and be confident
about configuring those browsers in precisely the way that suites them).

This means that from the point of view of the e-commerce site's client
the web developer's 'decision' to create something that only worked with
default configurations of 3 or 4 browsers was potentially harmful. It
effectively throttled potential turnover at the design stage. Of course
they don't appreciate that as if they had been in a position to make
that sort of judgement they would not have needed to employ someone else
to create the site for them. So instead they employed a 'professional'
and trusted that they would not be screwed as a result.

(Remember that this e-commerce site could have been created such that it
could take money off anyone who's browser is capable of making HTTP(S)
connections, displaying HTML pages, showing images and submitting a from
in a POST request (which is pretty much every non-pure text web browser
that has ever existed).)

The ironic aspect of this is that a month or so after this site was
pointed out to me I was in the office on a Saturday afternoon knocking
up some web material for a sails presentation and my boss decided that
he wanted different/better icon graphics. He could not get (hold of) any
of our designers to come in and create the graphics and didn't think he
could afford to leave the task until Monday. So he went to Google,
credit card in hand, to find and purchase some off the shelf graphics.
The very fist site he hit was our e-commerce icon seller above. He liked
one of the sets of icons and so hit the shopping cart to purchase them,
and it did not work for him. It did not work for him because his IE is
not in its default configuration either, but his is not in its default
configuration because our technical department found out that he had let
some spyware get onto his laptop and so leaked a company e-mail address
book (meaning we all got spammed continuously for a couple of months).
So they have clamped down his browser security in the Internet zone and
arranged that he (and I) cannot re-set those settings. The practical
upshot was that my boss's money went to a different seller of web icons.

So given that the original web developer was proud of his creation, and
how easy and profitable it had been (for him), so much so that he
published a web page to boast about his triumph, do you think he
appreciated the harm his design decisions had done? I don't think so,
and if challenged I bet he would make a lot of noise about working in
the 'real world' and play down the impact of his design decisions on his
client's turnover as 'not statistically significant' (without daring to
ask their opinion on the subject).

>> At least for as long as you avoid understanding how those
>> effects work, and so how trivial they are to create for
>> yourself.
>
> Again, if they are so trivial, why wouldn't a "good" library
> have been written?

For a start; a total disconnection of responsibilities. You just don't
need a 'library' to do trivial things.

But where is your statement of a valid justification for the creation of
a 'library' to start with? Without that we haven't even arrived at this
question.

> Wouldn't evolution cause the "good" librarues to bubble up
> and become the de facto standard? Wouldn't "bad libraries"
> break in future revs, independent browsers, etc, and the "good
> libraries" gain mind- and market-share with each manifestation
> of the "bad libararies'" failure?

In a world where people don't see demonstrations of a library's author
not knowing the language well enough to actually be programming with it
as sufficient grounds to dismiss the use of that library out of hand it
is quite likely that manifestations of failure would go unnoticed (or be
disregarded).

Richard.

Matt Kruse

unread,
Nov 19, 2007, 9:29:26 AM11/19/07
to
On Nov 17, 8:47 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> But where is your statement of a valid justification for the creation of
> a 'library' to start with? Without that we haven't even arrived at this
> question.

Some arguments in favor of a 'library' are:

1. Normalizing browser behavior, to the greatest extent possible, and
encapsulating the code required to do so into a 'standard' API
relieves the developer of the effort of considering browser quirks
every time code is to be written.

2. The code required to perform some common and repeated javascript
tasks correctly can be long and error-prone. Putting a layer over
commonly-used functionality so access to that functionality is shorter
and more concise leads to clearer code and simplifies development.

3. Not all organizations or development efforts are able to employ
javascript programmers with the level of knowledge required to write
robust, cross-browser code. Having a library of pre-written code by
someone who is much more experienced allows more inexperienced
javascript developers to perform complex tasks and develop
functionality that otherwise could not have realistically been
written.

4. A single library js file can be used on many pages throughout a web
site or webapp, and the reasonable assumption is that browsers will
cache the source. Rather than writing page-specific code (or putting
reusable functions in each page where they are required) that is
downloaded with each request, the caching of the library code can
result in faster pages.

There are caveats, of course. I don't think that using a general-
purpose library is always a good solution. Do you never believe that
it _is_ a good solution?

Under what situations do you think that using a general-purpose
library is a good choice? What kind of functionality would this
library have or not have?

Matt Kruse