to learn jQuery if already using prototype

184 views
Skip to first unread message

liketofindoutwhy

unread,
Apr 15, 2008, 9:04:27 AM4/15/08
to
I am learning more and more Prototype and Script.aculo.us and got the
Bungee book... and wonder if I should get some books on jQuery (jQuery
in Action, and Learning jQuery) and start learning about it too?

Once I saw a website comparing Prototype to Java and jQuery to Ruby...
but now that I read more and more about Prototype, it is said that
Prototype actually came from Ruby on Rails development and the creator
of Prototype created it with making Prototype work like Ruby in mind.
Is jQuery also like Ruby? Thanks so much for your help.

Thomas 'PointedEars' Lahn

unread,
Apr 15, 2008, 7:47:55 PM4/15/08
to
liketofindoutwhy wrote:
> I am learning more and more Prototype and Script.aculo.us and got the
> Bungee book... and wonder if I should get some books on jQuery (jQuery
> in Action, and Learning jQuery) and start learning about it too?
> [...]

Prototype.js, and consequently everything based upon it, like
Script.aculo.us, is junk. The jQuery junk support forums are
elsewhere, too.


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

kangax

unread,
Apr 15, 2008, 10:53:15 PM4/15/08
to
On Apr 15, 9:04 am, liketofindoutwhy <liketofindout...@gmail.com>
wrote:

Questions regarding prototype.js are better to be asked at
http://groups.google.com/group/rubyonrails-spinoffs

Best,
kangax

beegee

unread,
Apr 16, 2008, 10:15:06 AM4/16/08
to
On Apr 15, 9:04 am, liketofindoutwhy <liketofindout...@gmail.com>
wrote:

> Once I saw a website comparing Prototype to Java and jQuery to Ruby...

In a very, very superficial way, yes but no, forget what I just said.
I can't make the connection (not having read the site). Ruby and
Javascript are dynamic languages. JQuery and Prototype would not be
possible if Javascript was a compiled language like Java. And I
personally think Ruby is a beautiful language whereas I haven't
experienced a library whose "use code" looks quite as ugly as JQuery.

As PointedEars said, they are both junk. If you insist on a library,
check out YUI which is a lot like Javascript.

Thomas 'PointedEars' Lahn

unread,
Apr 16, 2008, 12:44:24 PM4/16/08
to
beegee wrote:

> [...] liketofindoutwhy [...] wrote:
>> Once I saw a website comparing Prototype to Java and jQuery to Ruby...
>
> In a very, very superficial way, yes but no, forget what I just said.
> I can't make the connection (not having read the site). Ruby and
> Javascript are dynamic languages. JQuery and Prototype would not be
> possible if Javascript was a compiled language like Java.

For that matter, at least JavaScript[tm] *is* a compiled language like Java.
Don't confuse prompt execution with no-compilation.

> [...]


> As PointedEars said, they are both junk. If you insist on a library,
> check out YUI which is a lot like Javascript.

I think you miss the point. YUI is *supposedly* only "more like
'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
that its developers *supposedly* knew enough about the programming languages
to unleash their full potential without having to resort to inefficient and
error-prone detours of inventing "classes" and "initializers" where there
are already prototypes and constructors.


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>

liketofindoutwhy

unread,
Apr 17, 2008, 8:19:29 AM4/17/08
to
On Apr 15, 4:47 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> liketofindoutwhy wrote:
> > I am learning more and more Prototype and Script.aculo.us and got the
> > Bungee book... and wonder if I should get some books on jQuery (jQuery
> > in Action, and Learning jQuery) and start learning about it too?
> > [...]
>
> Prototype.js, and consequently everything based upon it, like
> Script.aculo.us, is junk. The jQuery junk support forums are
> elsewhere, too.

So you mean Prototype and jQuery are both junk? Can you give some
points as to why you think so? For example, how else would you pass a
call back function binding to the current scope, such as
processData.bind(this) ? I kind of like the arr.each(function(x)
{ ... }) or the arr.sort().uniq().join(" ") syntax.

Thomas 'PointedEars' Lahn

unread,
Apr 17, 2008, 8:20:42 AM4/17/08
to
liketofindoutwhy wrote:
> On Apr 15, 4:47 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>
> So you mean Prototype and jQuery are both junk? Can you give some
> points as to why you think so?

I want popcorn.

humeniuc

unread,
Apr 17, 2008, 11:31:15 AM4/17/08
to
On Apr 16, 2:47 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Prototype.js, and consequently everything based upon it, like
> Script.aculo.us, is junk. The jQuery junk support forums are
> elsewhere, too.
>
> PointedEars

The list of the ones who uses, and consider Prototype or jQuery is
good coded is long... very long.
Some famous users:

Apple(http://www.apple.com/) uses Prototype
Google code (http://code.google.com/) uses jQuery
NASA(http://www.nasa.gov/) uses Prototype
Mozilla Addons (http://addons.mozilla.org/) uses jQuery
CNN (betaversion http://beta.cnn.com/) uses Prototype

I think PointedEars is wrong. If he could do better than jQuery,
Prototype, or YUI, maybe he could make examples of his 'great' work.
But i think he could not.

Thomas 'PointedEars' Lahn

unread,
Apr 17, 2008, 11:57:19 AM4/17/08
to
humeniuc wrote:
> On Apr 16, 2:47 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>> [...]

>
> The list of the ones who uses, and consider Prototype or jQuery is
> good coded is long... very long.
> Some famous users:
>
> Apple(http://www.apple.com/) uses Prototype
> Google code (http://code.google.com/) uses jQuery
> NASA(http://www.nasa.gov/) uses Prototype
> Mozilla Addons (http://addons.mozilla.org/) uses jQuery
> CNN (betaversion http://beta.cnn.com/) uses Prototype

So what? They all have made the wrong design decision. Whether source code
is good is not defined by those who use it but by the source code itself.

Yours is an "appeal to authority" fallacy, BTW.

> I think PointedEars is wrong. If he could do better than jQuery,
> Prototype, or YUI, maybe he could make examples of his 'great' work.
> But i think he could not.

And an ad hominem fallacy in addition.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Gregor Kofler

unread,
Apr 17, 2008, 1:32:11 PM4/17/08
to
humeniuc meinte:

> The list of the ones who uses, and consider Prototype or jQuery is
> good coded is long... very long.
> Some famous users:

And I suppose equally groundbreaking when it comes to web authoring.

> Apple(http://www.apple.com/) uses Prototype

The website is HTML 4 *Transitional* - still issues several warnings.
YSlow rates it "F". Flexible layouts? Never heard of these.

> Google code (http://code.google.com/) uses jQuery

More or less the same. Can't find jQuery in the scripts list, perhaps it
is included in another one.

> NASA(http://www.nasa.gov/) uses Prototype

As another one with pointed ears would have put it: "Fascinating".
Proprietary doctype. 48 warnings. Again: Layouting from the last century.
Starts with:

<script type="text/javascript">
/**
* Browser Detect Class (sic!)
*/
function detectBrowserClass(modern){
var nBrowser = navigator.appName;
var nVersion = navigator.appVersion;
var nAgent = navigator.userAgent;
this.version;
this.browser;
this.os;
this.modern = (typeof modern == 'object') == true ? modern:0;
if(nVersion.indexOf('Windows') !=-1){
this.os = 'win';
}else{
this.os = (nVersion.indexOf('Macintosh') !=-1) == true ? 'mac':'other';
}

Those guys definitely know, what they're doing... Apart from that
they've added around 400kB of various JS libraries. Seems as if
prototype isn't capable of anything.

> CNN (betaversion http://beta.cnn.com/) uses Prototype

Super slow loading - about 50% of the 630kB payload is eaten up by JS
files...

> I think PointedEars is wrong. If he could do better than jQuery,
> Prototype, or YUI, maybe he could make examples of his 'great' work.

He frequently posts links to his "work". Anyway, I suppose since Richard
Cornford, Douglas Crockford, Randy Webb and others also question the
quality of these libraries frequently, they're clueless ignorants, too.


Gregor


--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

VK

unread,
Apr 17, 2008, 2:34:01 PM4/17/08
to
On Apr 17, 9:32 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> > Apple(http://www.apple.com/) uses Prototype
>
> The website is HTML 4 *Transitional* - still issues several warnings.

So what? HTML 4 Transitional is the only usable doctype so far - until
HTML 5 will finally arrive. HTML 4 Strict is missing some vital
features like target attribute for links and iframe. Moreover HTML 4
Strict puts IE6 into W3C box model and it doesn't understand box-
sizing: border-box to switch it back to normal. So while IE6 is still
in consideration and while HTML 5 is not ready, HTML 4 Transitional is
the only one you can really work with.

> Flexible layouts? Never heard of these.

Nor me. At least not a single one that could be trusted. The choice is
very simple here: do you want flexible (liquid) layout or do you want
another contract work?

Moreover any modern browser now supports Ctrl+/- magnifier, so the
need of flexible (liquid) layouts - which was a workaround for IE4/5/6
display augmentation weakness - is mostly over.

> > Google code (http://code.google.com/) uses jQuery
>
> More or less the same. Can't find jQuery in the scripts list, perhaps it
> is included in another one.

Look at the http://code.google.com page source itself. It loads
http://code.google.com/js/codesite.pack.01312008.js
which is jQuery 1.2.3

> > NASA(http://www.nasa.gov/) uses Prototype
>
> As another one with pointed ears would have put it: "Fascinating".
> Proprietary doctype. 48 warnings. Again: Layouting from the last century.
> Starts with:
>
> <script type="text/javascript">
> /**
> * Browser Detect Class (sic!)
> */
> function detectBrowserClass(modern){
> var nBrowser = navigator.appName;
> var nVersion = navigator.appVersion;
> var nAgent = navigator.userAgent;
> this.version;
> this.browser;
> this.os;
> this.modern = (typeof modern == 'object') == true ? modern:0;
> if(nVersion.indexOf('Windows') !=-1){
> this.os = 'win';}else{
>
> this.os = (nVersion.indexOf('Macintosh') !=-1) == true ? 'mac':'other';
>
> }
>
> Those guys definitely know, what they're doing... Apart from that
> they've added around 400kB of various JS libraries. Seems as if
> prototype isn't capable of anything.


NASA is a US governmental unit, their site is under FOIA and ADA
rules. Whatever they had to be done to not be sued they had to do. If
you are a US citizen - or you know one to help you - contact NASA at
http://www.nasa.gov/help/contact/index.html showing where and how the
site accessibility or usability is broken for you.

> > CNN (betaversionhttp://beta.cnn.com/) uses Prototype


>
> Super slow loading - about 50% of the 630kB payload is eaten up by JS
> files...

It takes 3sec on my 4Mb/sec downstream DSL for the initial page
display where the download itself takes 0.39sec You may want to
consider switching from Dial-Up to something more speedy ;-)

humeniuc

unread,
Apr 17, 2008, 3:05:46 PM4/17/08
to
> Yours is an "appeal to authority" fallacy, BTW.
I am not an authority at all. I am just a developer. But I think I
have the right to an opinon. Prototype helped me in developement and
other found a help in jQuery.

"They all have made the wrong design decision."

From this afirmation, I could say you are with "appeal to authority".
If you sad that they made wrong descisions, show us some good
decision. Where did they made wrong decisions?
Invitation: post here some links of your works, so anybody could see
good code, better than Prototype or jQuery.
Could you, please?
---------------------

Gregor, I only wanted to point that many sites uses that libraryes.
Google code have an "/js/codesite.pack.01312008.js" -- minified
version of jQuery

> He frequently posts links to his "work".

I haven't seen any work of this person, I will search deeply in his
archive, but until now all that I saw was a lot of sarcasm and acid
remarks, but maibe PointedEars is a great programmer, in which case
wee should see some great code or some urls with that work from
him. :) (eventualy....)

All my best

Gregor Kofler

unread,
Apr 17, 2008, 4:14:43 PM4/17/08
to
humeniuc meinte:

> Gregor, I only wanted to point that many sites uses that libraryes.
> Google code have an "/js/codesite.pack.01312008.js" -- minified
> version of jQuery

That's what I meant with "included in another one".

>> He frequently posts links to his "work".
>
> I haven't seen any work of this person, I will search deeply in his
> archive, but until now all that I saw was a lot of sarcasm and acid
> remarks, but maibe PointedEars is a great programmer, in which case
> wee should see some great code or some urls with that work from
> him. :) (eventualy....)

The discussion about the "quality" of jQuery et al pops up frequently.

Anyway, as I noted: Thomas is not the only one. You can search for
previous threads on this topic. You can search for the other names (and
their work; David Mark comes to my mind, too). You know how to use
search engines.

Anyway, the point that somebody has to show off his own work before
being allowed to critize others work, is a poor one. You don't have to
be a chef to rate something as tasty or not.

humeniuc

unread,
Apr 17, 2008, 5:33:07 PM4/17/08
to
> Anyway, the point that somebody has to show off his own work before
> being allowed to critize others work, is a poor one. You don't have to
> be a chef to rate something as tasty or not.

I agree with you. I exagerated a little here, but i was a little
iritated about Tomas atitude and his acid posts, not only in this
topic.
I reached his site, I see that he is a good programmer, but his
atitude ....

about jQuery quality, can't make a statement, I have coleagues who use
it and are happy with it.
I prefer Prototype. I don't know what programing rules broke Prototype
developers (if you have some links, discutions, please share), but
works for me.

Sorry if I offended someone, and happy programming. In pure
Javascript, Prototype, jQuery, YUI or what suits :)

Good day to all.

Gregor Kofler

unread,
Apr 17, 2008, 5:57:47 PM4/17/08
to
humeniuc meinte:

> I agree with you. I exagerated a little here, but i was a little
> iritated about Tomas atitude and his acid posts, not only in this
> topic.
> I reached his site, I see that he is a good programmer, but his
> atitude ....
>
> about jQuery quality, can't make a statement, I have coleagues who use
> it and are happy with it.
> I prefer Prototype. I don't know what programing rules broke Prototype
> developers (if you have some links, discutions, please share), but
> works for me.

Perhaps this one:
<http://groups.google.at/group/comp.lang.javascript/browse_frm/thread/2072e63631688fc4/d63033d712a89e02>

RobG

unread,
Apr 17, 2008, 7:03:51 PM4/17/08
to
On Apr 18, 7:57 am, Gregor Kofler <use...@gregorkofler.at> wrote:
> humeniuc meinte:
>
> > I agree with you. I exagerated a little here, but i was a little
> > iritated about Tomas atitude and his acid posts, not only in this
> > topic.
> > I reached his site, I see that he is a good programmer, but his
> > atitude ....
>
> > about jQuery quality, can't make a statement, I have coleagues who use
> > it and are happy with it.
> > I prefer Prototype. I don't know what programing rules broke Prototype
> > developers (if you have some links, discutions, please share), but
> > works for me.
>
> Perhaps this one:
> <http://groups.google.at/group/comp.lang.javascript/browse_frm/thread/...>

Or this one:

<URL:
http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thread/181f03af63cc81c2/e88d79970736fe36?hl=en&lnk=gst&q=+Why+should+I+eschew+prototype.js#e88d79970736fe36
>

A salient quote from one of Richard Cornford's posts in that thread:

"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 ... those
browsers. This cannot be a viable approach to creating
cross-browser code, and it does not."


--
Rob

VK

unread,
Apr 18, 2008, 12:36:35 AM4/18/08
to
On Apr 18, 3:03 am, RobG <rg...@iinet.net.au> wrote:
> A salient quote from one of Richard Cornford's posts in that thread:
>
> "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 ... those
> browsers. This cannot be a viable approach to creating
> cross-browser code, and it does not."

The Richard Cornford's point of view was well expressed in this NG
many times. In his universe a program for MS-DOS has to seamlessly
migrate on 16bit GUI of any kind (not Windows only), then equally
seamlessly migrate to 32bit and 64bit GUI. Respectively when
programming in say MS-DOS the programmer has to foresee the whole
future line of OS development 10-20 years in advance. Any message of
the kind "This program requires ... to run" is a sign of a very bad
programming. I do respect personal philosophical schemes including
idealistic romanticism as well. Yet claiming it as a world-wide the
only correct programming pattern is Richard Cornford's personal choice
other have rights do no agree with.


humeniuc

unread,
Apr 18, 2008, 2:30:28 AM4/18/08
to

Richard Cornford

unread,
Apr 18, 2008, 2:40:51 AM4/18/08
to
liketofindoutwhy wrote:

> On Apr 15, 4:47 pm, Thomas 'PointedEars' Lahn wrote:
>> liketofindoutwhy wrote:
>>> I am learning more and more Prototype and Script.aculo.us
>>> and got the Bungee book... and wonder if I should get some
>>> books on jQuery (jQuery in Action, and Learning jQuery)
>>> and start learning about it too?

In the end it would be more productive to learn javascript and browser
scripting, and then you make your own mind up.

>>> [...]
>>
>> Prototype.js, and consequently everything based upon it, like
>> Script.aculo.us, is junk. The jQuery junk support forums are
>> elsewhere, too.
>
> So you mean Prototype and jQuery are both junk?

I didn't think that statement was ambiguous in any way.

> Can you give some points as to why you think so?

That is probably going to come down to understanding.

> For example, how else would you pass a
> call back function binding to the current scope,

Do you know what that means? It reads like the usual parroting of the
(lamentably) common misconception(or mislabelling) that scope is in some
way related to the value of the - this - keyword in javascript. While in
javascript scope is lexical and so (mostly) determined by the (structure
of the) source code and the - this - value is determined by how
functions/methods are call, and determined at runtime.

> such as processData.bind(this) ?

So it is the - this - value that concerns you, not scope at all.

But what sort of question are you asking? Javascript programmers know
what the - this - keyword will refer to at any point, and how to arrange
that the - this - keyword refers to specific objects when it is
necessary. You are not programming until you are in control of that sort
of thing.

As both of Prototype.js and JQuery are written in javascript it must be
possible to write javascript code that does anything and everything that
either are capable of.

> I kind of like the arr.each(function(x)
> { ... })

But is "like" enough of a reason? I have seen some horrendously
inefficient uses of function expressions in - each - and - forEach -
methods (including inside the JQuery source code). They seem to
encourage it, at lest where the author had not understood the
implications of what they are doing.

> or the arr.sort().uniq().join(" ") syntax.

That style of method chaining has been dogging javascript for years. It
is occasionally useful, but it does result in some very obscure source
code, which probably explains why I can think of no regular contributors
to this group who choose that style of coding.

And one of the consequences of the inherent obscurity of that style of
code is demonstrated in your example. It looks to me like the intention
of - uniq - would be to remove repetitious values from the array
(assuming the subject is an array) and it is unlikely that that method
has been written such that it benefits in any way from the array being
pre-sorted, but the sort method will almost certainly be more efficient
if any elements that are to be removed from the array are removed before
sorting.

Of course seeing and understanding the source code for those methods
would answer the question one way or the other.

But 'liking' superficial syntax and convenience methods are nowhere near
enough to mitigate for the observation (from the source code) that the
authors of those two libraries did not (and seemingly still do not)
understand javascript as a language or its application in browser
scripting.

Richard.


RobG

unread,
Apr 18, 2008, 8:05:53 AM4/18/08
to
On Apr 18, 2:36 pm, VK <schools_r...@yahoo.com> wrote:
> On Apr 18, 3:03 am, RobG <rg...@iinet.net.au> wrote:
>
> > A salient quote from one of Richard Cornford's posts in that thread:
>
> >   "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 ... those
> >    browsers. This cannot be a viable approach to creating
> >    cross-browser code, and it does not."
>
> The Richard Cornford's point of view was well expressed in this NG
> many times. In his universe [... snip ...]

The snipped part your post utterly misrepresents Richard's often
expressed opinion. The funny thing is that only those familiar with
your posting style will have any idea what you were trying to say -
and they know enough about what you post to ignore it.


--
Rob

J.S.Criptoff

unread,
Apr 18, 2008, 1:21:56 PM4/18/08
to
While c.l.j regulars are ridiculing John Resig's first javascript book
he's writing the second one - "Secrets of the JavaScript Ninja". He
was a javascript Guru. Now he is a javascript Ninja. Hey, it's time to
iconize him!

Your are invited to pray here:
http://ejohn.org/blog/state-of-the-secrets/

Thomas 'PointedEars' Lahn

unread,
Apr 18, 2008, 1:26:01 PM4/18/08
to
J.S.Criptoff wrote:
> While c.l.j regulars are ridiculing John Resig's first javascript book

It does not need to be ridiculed. Many (if not most) of Resig's statements
are provably factually utterly wrong (and have been proven so here), so it
provides the ridiculousness by itself already.

> he's writing the second one - "Secrets of the JavaScript Ninja".

OMG!


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

Gregor Kofler

unread,
Apr 18, 2008, 2:25:23 PM4/18/08
to
J.S.Criptoff meinte:

> While c.l.j regulars are ridiculing John Resig's first javascript book
> he's writing the second one - "Secrets of the JavaScript Ninja". He
> was a javascript Guru. Now he is a javascript Ninja. Hey, it's time to
> iconize him!

I thought he was an "evangelist". Anyway, "What does with(){...} do and
why is it so useful?" will be one of the topics. PLUS: more class-like
implementations in JavaScript. I hope this book will finally put the
hipocrites of this group to shame.

> Your are invited to pray here:
> http://ejohn.org/blog/state-of-the-secrets/

Who knows? If you pray fervently enough, you might be in for a free
sample of "Secrets of the JavaScript Ninja". (Or the forthcoming "Way of
the JavaScript Samurai".)

Lasse Reichstein Nielsen

unread,
Apr 18, 2008, 3:48:59 PM4/18/08
to
Gregor Kofler <use...@gregorkofler.at> writes:

> Anyway, "What does with(){...} do
> and why is it so useful?" will be one of the topics.

It adds an object to the scope chain throughout its body.

This is one of the two ways to add a level to the scope chain, the other
being a function call.

Using "with" like a let-construct is dangerous, though.

function stepWatch(watch) {
for(var i = 0; i < watch; i++) {
with({i:i}) {
setTimeout(function(){alert(i + " of " + watch);}, i*1000);
}
}
}
stepWatch(5);

This appears to work fine in IE and Opera (where omitting the "with"
construct will alert "5" all the times).

Then someone runs it in Firefox, and it alerts:
0 of function watch() {
[native code]
}

The problem with the "with" construct is that you cannot control which
properties exist on the object. It differs between browsers (as
above), and it can be changed by other, misbehaved, libraries that
change Object.prototype.

So there, I'm looking forward to hearing why it's so useful :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Gregor Kofler

unread,
Apr 18, 2008, 4:29:31 PM4/18/08
to
Lasse Reichstein Nielsen meinte:

> The problem with the "with" construct is that you cannot control which
> properties exist on the object. It differs between browsers (as
> above), and it can be changed by other, misbehaved, libraries that
> change Object.prototype.
>
> So there, I'm looking forward to hearing why it's so useful :)

Let John respond:

Gopal:
would consider the "with" statement in JavaScript to be very harmful
rather than being useful.

John:
@Gopal: There's a ton of things in JavaScript that can be "considered
harmful". Since JavaScript is such an, extremely, flexible language you
can make mistakes all over the place and not catch it. I just think that
we need to have a better understanding of how the existing features work
to give us a clearer way to move forward and to work with what we have.

I hope this makes things *a lot* clearer.

John G Harris

unread,
Apr 18, 2008, 4:13:33 PM4/18/08
to
On Thu, 17 Apr 2008 at 11:34:01, in comp.lang.javascript, VK wrote:
>On Apr 17, 9:32 pm, Gregor Kofler <use...@gregorkofler.at> wrote:

<snip>


>> > CNN (betaversionhttp://beta.cnn.com/) uses Prototype
>>
>> Super slow loading - about 50% of the 630kB payload is eaten up by JS
>> files...
>
>It takes 3sec on my 4Mb/sec downstream DSL for the initial page
>display where the download itself takes 0.39sec You may want to
>consider switching from Dial-Up to something more speedy ;-)


A lot of sailors have to use dial-up via INMARSAT. Do you have a cheery
word for them ?

John
--
John Harris

J.S.Criptoff

unread,
Apr 18, 2008, 4:50:10 PM4/18/08
to
On 18 апр, 23:48, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:
> The problem with the "with" construct is that you cannot control which
> properties exist on the object. It differs between browsers (as
> above), and it can be changed by other, misbehaved, libraries that
> change Object.prototype.

Almost the same situation with named FunctionExpression:

(function () {
var watch = 0;
(function f() {
alert(watch); //-> native code...
})();
})();

Lasse Reichstein Nielsen

unread,
Apr 18, 2008, 5:08:51 PM4/18/08
to
"J.S.Criptoff" <J.S.Cr...@googlemail.com> writes:

> Almost the same situation with named FunctionExpression:
>
> (function () {
> var watch = 0;
> (function f() {
> alert(watch); //-> native code...
> })();
> })();

Wow! That's ... bad!

It seems Firefox decided to let the activation object inherit from
Object.prototype. There is nothing in the specification that requires
this, and, as you show us, it can give problems.

Neither Opera nor IE does this. Has it been bug-reported yet?

J.S.Criptoff

unread,
Apr 18, 2008, 5:22:52 PM4/18/08
to
On 19 апр, 01:08, Lasse Reichstein Nielsen <l...@hotpop.com> wrote:
> It seems Firefox decided to let the activation object inherit from
> Object.prototype. There is nothing in the specification that requires
> this, and, as you show us, it can give problems.

No, Lasse, it is "special" object in scope chain created to keep
FunctionExpression name only (ES 13), no bug here.

Andrew Dupont

unread,
Apr 18, 2008, 6:19:57 PM4/18/08
to
On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> So what?  They all have made the wrong design decision.  Whether source code
> is good is not defined by those who use it but by the source code itself.
And the source code makes its divine message known through you, its
emissary in the human realm? (And I thought I had to read the
_comments_ to understand how code worked. What a fool I was.)

You're that guy who stubbornly insists that music is not a matter of
taste — who cannot suffer the fools who dare to question the status of
Rush's _Fly By Night_ as the best album of all time in any genre.
These philistines! They ply their ears with the bleating of musical
sheep!

> Yours is an "appeal to authority" fallacy, BTW.

You call foul for a logical fallacy against someone who was rebutting
your claim that two immensely popular JavaScript libraries are "junk"?
I count two right there: "appeal to ridicule" and "misplaced burden of
proof." You're the one asserting they're junk. The burden of proof is
yours.

> And an ad hominem fallacy in addition.

How dare he spoil the cordial tone. Someone asks a question about
Prototype and jQuery; you reply that they're junk, and snarkily imply
he's in the wrong place. He plainly asks you why you think they're
junk; instead of mounting an argument, you make a quip. Did this guy
piss in your cornflakes?

(I'm sure you've laid out your argument in the past, and have had to
repeat it several times – so there's no reason why you shouldn't slap
it on a web server somewhere and give someone a URL.)

Now, this is Usenet; flamewars and intellectual laziness are the rule,
not the exception. But if you're pointing out the logical fallacies of
others I can only assume you aspire to a higher plane of debate.

Cheers,
Andrew

AKS

unread,
Apr 19, 2008, 4:02:00 AM4/19/08
to

J.S.Criptoff wrote:

> No, Lasse, it is "special" object in scope chain created to keep
> FunctionExpression name only (ES 13), no bug here.

"Special" object? No, it's not:


F();

function F() {
alert(watch); //-> native code...
};

AKS

unread,
Apr 19, 2008, 4:14:44 AM4/19/08
to
On Apr 19, 2:02 pm, AKS <aksus...@yandex.ru> wrote:

> "Special" object? No, it's not:

Excuse me, I was mistaken!


Lasse Reichstein Nielsen

unread,
Apr 19, 2008, 4:54:09 AM4/19/08
to
"J.S.Criptoff" <J.S.Cr...@googlemail.com> writes:

> No, Lasse, it is "special" object in scope chain created to keep
> FunctionExpression name only (ES 13), no bug here.

Indeed, by bad. It only occurs when the inner function expression is a
named function. It's not the activation object, and it is as specified
in the standard (which probably means that the standard should be
changed, becuause that's a bad choice!)

Richard Cornford

unread,
Apr 19, 2008, 7:01:41 AM4/19/08
to
Lasse Reichstein Nielsen wrote:

> J.S.Criptoff writes:
>
>> No, Lasse, it is "special" object in scope chain created
>> to keep FunctionExpression name only (ES 13), no bug here.
>
> Indeed, by bad. It only occurs when the inner function expression
> is a named function. It's not the activation object, and it is
> as specified in the standard (which probably means that the
> standard should be changed, becuause that's a bad choice!)

That does seem a bit of an oversight on the part of the authors of the
specification (possibly not seeing the full consequences of what they
were writing). On the other hand the infamous JScript(tm) bug where
using an Identifier with a function expression results in the creation
of an additional function object as a named property of the current
Variable object (and during variable insanitation) already means that
using Identifiers with function expression has inconsistent
consequences. So doing so was already a bad idea.

Richard.


Richard Cornford

unread,
Apr 19, 2008, 7:40:06 AM4/19/08
to
J.S.Criptoff wrote:
> While c.l.j regulars are ridiculing John Resig's first
> javascript book he's writing the second one - "Secrets
> of the JavaScript Ninja".
<snip>

That would not necessarily have to such a bad thing as it may at first
appear to be. The first book was published in 2006 and it is possible to
learn a great deal in two years. Granted I don't think that John Resig's
attitude will lend itself to facilitating his learning anything
effectively.

Richard.


Richard Cornford

unread,
Apr 19, 2008, 12:02:49 PM4/19/08
to
Andrew Dupont wrote:

> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>> So what? They all have made the wrong design decision. Whether
>> source code is good is not defined by those who use it but by
>> the source code itself.
>
> And the source code makes its divine message known through you,
> its emissary in the human realm? (And I thought I had to read
> the _comments_ to understand how code worked. What a fool I
> was.)

It is very often a characteristic of 'good' source code (at least in
higher level languages) that the code can easily be understood by
reading the source code.

However, the last significant discussion of the Prototype.js source code
that we had here (the link, via Google groups, to that discussion is in
one of the posts in this thread) showed that the authors of Protoype.js
obviously did not understand the code they were writing (instead finding
themselves victims of code that exhibited behaviour that conformed with
their expectations by no more than coincidence (but then only on the
browsers were they had observed that behaviour)). Under those
circumstances the code itself if more informative than the comments
because an author who does not understand the code they are writing
cannot comment it in an informative way.

> You're that guy who stubbornly insists that music is not a

> matter of taste - who cannot suffer the fools who dare to


> question the status of Rush's _Fly By Night_ as the best
> album of all time in any genre. These philistines! They ply
> their ears with the bleating of musical sheep!
>
>> Yours is an "appeal to authority" fallacy, BTW.

I didn't think that was an appeal to authority, more of an appeal to
bulk, in some sens.

> You call foul for a logical fallacy against someone who was
> rebutting your claim that two immensely popular JavaScript
> libraries are "junk"?

That wasn't a rebuttal, more of an excuse for using the code regardless
of any informed assessment of its quality.

> I count two right there: "appeal to ridicule" and "misplaced
> burden of proof." You're the one asserting they're junk. The
> burden of proof is yours.

<snip>

Where the 'proof' is already a matter of public record, and familiar to
anyone who has any more than superficial record of participating in this
group, there is no longer any burden of proof at all.

Still, if you want examples they are just a short download away.
Downloding the latest version of Prototype.js (1.6.0.2) I wondered how
long it would take me to find an example of something being done
sufficiently badly for that to be easily and unambiguously demonstrated.
The answer was under three seconds. During the first scroll through the
code, not even looking at most of the details, I noticed this:-

| if (Prototype.Browser.WebKit || Prototype.Browser.IE)
| Object.extend(String.prototype, {
| escapeHTML: function() {
| return this.replace(/&/g,'&amp;')
| .replace(/</g,'&lt;')
| .replace(/>/g,'&gt;');
| },
| unescapeHTML: function() {
| return this.replace(/&amp;/g,'&')
| .replace(/&lt;/g,'<')
| .replace(/&gt;/g,'>');
| }
| });

- which is adding a couple of escaping/unescaping methods to the -
String.prototype - object based upon a condition. Seeing it I asked
myself whether the author had made the rookie mistake that every web
development novice always makes (and the thing I deliberately double
check every time I ask someone to write an escaping/unescaping function
for any purpose), and the answer was a very obvious "yes they have".

One of the arguments paraded in favour of these libraries is that they
are examined, worked on and used by very large numbers of people, and so
they should be of reasonably high quality because with many eyes looking
at the code obvious mistakes should not go unnoticed. My experience of
looking at code from the various 'popular' libraries suggests that this
is a fallacy, because (with the exception of YUI (for obvious reasons))
all of the 'popular' library contain numerous obviously stupid mistakes.
The problem probably being that it does not matter how many people may
look at, review or use, any particular piece of code, if none of them
understand what they are doing none of them are capable of spotting the
obvious mistakes.

In this case we have a very obviously stupid use of user agent string
based browser detection to make a decision that would be more logically
made with feature detection. That is, the attempt is to add two methods
to the - String.prototype - in environments were those methods do not
already exist. Obvioulsy the is a one-to-one relationship between -
String.prototype.escapeHTML - having trueness and an environment where
a - String.prototype.escapeHTML - has been implemented. While the
relationship between a user agent sting an a -
String.prototype.escapeHTML - method is at best tenuous, and certainly
not guaranteed to be comprehensive or continuous over time.

But that is not the rookie mistake I alluded to above. That mistake is
that the escaping and unescaping methods are not symmetrical. That is,
if you apply the second to the output of the first you will not always
end up with the character sequence you start with. I.E.:-

<script type="text/javascript">
alert('&lt;'.escapeHTML().unescapeHTML()); //alerts "<"
alert('&amp;lt;'.unescapeHTML().escapeHTML()) //alerts "&lt;"
<script>

- and that is pretty bad by anyone's standards (except maybe VK's).

Richard.


J.S.Criptoff

unread,
Apr 19, 2008, 12:32:30 PM4/19/08
to
On 19 апр, 15:40, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

In two years? Are you kidding, Richard? John Resig gave a presentation
for the local ACM of Northeastern University and covered the basics of
javascript a few weeks ago. Weeks. Look at his slide, Richard:

Type coersion
0 == false
null == false
!"foo" == false

And listen to guru-ninja's explanation: "Zero is equal to false. Zero
gets coerced into becoming а boolean value... Same thing with
nulls...".

from 5:50
http://video.google.com/videoplay?docid=-7485992465859932389

Thomas 'PointedEars' Lahn

unread,
Apr 19, 2008, 3:00:48 PM4/19/08
to
Richard Cornford wrote:
> Andrew Dupont wrote:
>> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>>> Yours is an "appeal to authority" fallacy, BTW.
>
> I didn't think that was an appeal to authority, more of an appeal to
> bulk, in some sens.

Quoting people who approve of something and concluding that therefore this
something must be good is the classical example for the logical fallacy of
appeal to authority, also known as "ipse dixit" ("he himself said it").

Unfortunately, out of general appreciation of the other person, several
regulars around here tend to fall victim to this fallacy as well, without
recognizing it. We should strive to avoid such fallacious arguments,
especially as they only weaken a good case when confronted with an argument
that is fallacious as well.

http://en.wikipedia.org/wiki/Appeal_to_authority


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>

Richard Cornford

unread,
Apr 19, 2008, 4:06:29 PM4/19/08
to
J.S.Criptoff wrote:

>Richard Cornford wrote:
>> J.S.Criptoff wrote:
>>> While c.l.j regulars are ridiculing John Resig's first
>>> javascript book he's writing the second one - "Secrets
>>> of the JavaScript Ninja".
>> <snip>
>>
>> That would not necessarily have to such a bad thing as it may

That really should have been; "... have to be such a bad thing ..".

>> at first appear to be. The first book was published in 2006
>> and it is possible to learn a great deal in two years. Granted
>> I don't think that John Resig's attitude will lend itself to
>> facilitating his learning anything effectively.
>

> In two years? Are you kidding, Richard?

Not at all. The bulk of what I have learnt about javascript was learnt
in the period from 2002 to 2004. Two years is plenty of time, if you put
the effort in and are receptive to the idea that you really didn't know
it all to start with.

> John Resig gave a presentation for the local ACM of
> Northeastern University and covered the basics of
> javascript a few weeks ago. Weeks. Look at his slide,
> Richard:
>
> Type coersion
> 0 == false
> null == false
> !"foo" == false
>
> And listen to guru-ninja's explanation: "Zero is equal to

> false. Zero gets coerced into becoming ? boolean value...


> Same thing with nulls...".

<snip>

Well, I did say that his attitude would get in the of his potential to
learn. He dropped into a thread on this group with the subject
"prototype - Good/Bad/Why?", which commenced 15th February 2008 and in
which the section of his first book that reads:-

"In JavaScript, null, 0, '', false, and undefined are all equal (==)
to each other, since they all evaluate to false. This means that if
you use the code test == false, it will evaluate true if test is
also undefined or equal to null, which may not be what you want."

- and goes on to state that:-

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

- was directly criticised for its demonstrably false statements about
javascript (and also the competence of the book's technical editor (who
apparently works for Google) as a result of letting those errors pass
uncorrected). If he had hung around and paid attention to his critics he
would not have been repeating that same mistake just a couple of weeks
ago. But then the code:-

| makeArray: function( array ) {
| var ret = [];
|
| // Need to use typeof to fight Safari childNodes crashes
| if ( typeof array != "array" )
| for ( var i = 0, length = array.length; i < length; i++ )
| ret.push( array[ i ] );
| else
| ret = array.slice( 0 );
|
| return ret;
| },

- was still in the last (1.2.3) release of JQuery more than six months
after John Resig had been directly asked to justify it during his
previous visit to this group. He did not attempt to justify it (which
would not have been that difficult if it could be justified at all [1]),
but apparently also did not grasp the reason for the criticism.

Interestingly I observed Matt Kruse (who is the nearest thing to a
supporter JQuery has among the regular contributors to this group, and
someone who can easily outgun anyone directly involved in JQuery
development when it comes to javascript) directly asked however was
responsible for the - if ( typeof array != "array" ) - code to own up to
it in a post on the JQuery development group. However, when I checked
back a week later to see if anyone had the intellectual integrity to own
up to their mistake I found that Matt's post had been deleted from the
group.

Well, we get used to the intellectual freedom of Usenet, where criticism
is just a matter of public record. While those more familiar with
blogging and (self?) moderated Google forums might see deleting their
critics as a satisfactory approach to avoiding realising their mistakes.

Richard.

[1] For those who need to be told; javascript primitives and native and
built in objects may only result in the strings 'string', 'undefined',
'object', 'function', 'number' and 'boolean' from a typeof operation
(with no known implementation bugs in this area). Host objects are
allowed to return any value (or even throw exceptions), such as when the
methods of ActiveX object result in the string 'unknown' when a typeof
operation is applied to them. So, if the code - if ( typeof array !=
"array" ) - makes any sense at all there must be an object property of a
host object in a browser (and since JQuery only works with the default
configurations of just four browser it must be one of those four
browsers) with a - slice - method that results in 'array' when a typeof
operation is applied to it. It should not be at all difficult to name
the object/property and browser/browser version in question, and so
justify code that otherwise looks like a long running mistake that is
being repeated in the face of direct criticism.


Richard Cornford

unread,
Apr 19, 2008, 5:20:53 PM4/19/08
to
Thomas 'PointedEars' Lahn wrote:
> Richard Cornford wrote:
>> Andrew Dupont wrote:
>>> On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:
>>>> Yours is an "appeal to authority" fallacy, BTW.
>>
>> I didn't think that was an appeal to authority, more of an
>> appeal to bulk, in some sens.
>
> Quoting people who approve of something and concluding that
> therefore this something must be good is the classical example
> for the logical fallacy of appeal to authority, also known as
> "ipse dixit" ("he himself said it").

It is certainly an appeal to something, but it often feels as if that
something is not "authority" much of the time. After all, why should
NASA, Apple or CNN be considered authorities on web development at all.
You would not cite someone who was perceived as having web development
expertise in support of opinions on space exploration, computer hardware
design or news broadcasting so why attempt to do so the other way
around.

And Google is just a joke in any list of 'authorities' on web
development. I noticed at the beginning of last week that they have
(after just half a decade) finally managed to improve the accuracy of
their adding-up code on Google groups to an accuracy better than the
previous plus or minus 60% (and so radically re-arrange their 'all time
top posters' list for comp.lang.javascript), and the next day I tried to
show someone that they had done something about that code only to find
that the page containing the list was no longer working at all (and
stayed non-functional for the rest of the week). Their code is clearly
such a mess that whenever they try to fix one of its faults it promptly
unravels somewhere else.

> Unfortunately, out of general appreciation of the other
> person, several regulars around here tend to fall victim
> to this fallacy as well, without recognizing it.

Yes, and it seems to be getting to be me who keeps being cited as an
authority. I suppose that I probably should not worry about that from a
personal point of view because for each opinion of mine that is
accurately represented there will also be reasoned statement of
justification for that position somewhere on the public record. Though
it is perhaps a pity that reasoned arguments are apparently not seen as
standing or falling independently of any 'authority' that makes them,
and so should be presented in themselves.

> We should strive to avoid such fallacious arguments,
> especially as they only weaken a good case when confronted
> with an argument that is fallacious as well.

That would be good. But I can certainly see how the Prototype.js/JQuery
argument is starting to get so old that people are reverting to
knee-jerk generalisation as an alternative to going over it all again.

Richard.


VK

unread,
Apr 19, 2008, 5:52:08 PM4/19/08
to

As a person: "Good and safe trip to all of you!".
As a web developer: nothing. Unless of course some particular project
will require to accommodate the content delivery to the most thin
clients and/or most narrow bandwidth. In the latter case we will do
anything possible within the budget for that: from light weighted HTML
to WML. But no one will change the Web in whole neither for Inmarsat
nor for GSM cell phone surfers.

Andrew Dupont

unread,
Apr 19, 2008, 9:33:01 PM4/19/08
to
On Apr 19, 11:02 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

First off, full disclosure: I am a Prototype developer, and I know
John Resig well and have immense respect for his library. I don't seek
to change anyone's mind about libraries; I only want to ensure that
dislike thereof is driven by thoughtful deliberation and/or a core
philosophy difference. I welcome any constructive criticism and agree
to disagree about the rest.

>
> > You call foul for a logical fallacy against someone who was
> > rebutting your claim that two immensely popular JavaScript
> > libraries are "junk"?
>
> That wasn't a rebuttal, more of an excuse for using the code regardless
> of any informed assessment of its quality.

To be clearer: I saw it as an argument for why Thomas owned the burden
of proof. If these libraries have won legitimacy on the mainstream
Web, then the opinion that they are shoddy is held by a minority, and
they obviously need to do more persuading.

Again, I worry about matters of taste being presented as facts. I
don't mean to say that all statements need to be prepended with "In my
opinion," but Thomas was using his own taste to render judgement on a
thread and shoo away its originator. I think it's far more
constructive to say "Most of us are not library fans, so you're
unlikely to find useful answers here," then point the way to the
jQuery mailing list. That'd accomplish the same goal with far less
drama.

>
> > I count two right there: "appeal to ridicule" and "misplaced
> > burden of proof." You're the one asserting they're junk. The
> > burden of proof is yours.
>
> <snip>
>
> Where the 'proof' is already a matter of public record, and familiar to
> anyone who has any more than superficial record of participating in this
> group, there is no longer any burden of proof at all.

Perhaps the comp.lang.javascript FAQ needs an entry for this, then. A
large portion of those who post on this newsgroup aren't participants
or even lurkers; they come by only when they have problems. They can't
be expected to catch up on the backstory.

> In this case we have a very obviously stupid use of user agent string
> based browser detection to make a decision that would be more logically
> made with feature detection.

Actually, no — no browser implements String#(un)escapeHTML, so feature
detection would be pointless. We define that function earlier in the
file, but redefine them for WebKit and IE because the String#replace
approach is much, much faster in these two browsers (but much, much
slower in FF and Opera).

To be sure, there are other UA sniffs in Prototype that hard-liners
would decry as unnecessary. I personally try to avoid sniffing
wherever possible, but there are some instances in which a capability
check is either impossible or prohibitively complicated. (The line
between "acceptably complicated" and "prohibitively complicated" is
defined by the individual.)

>
> But that is not the rookie mistake I alluded to above. That mistake is
> that the escaping and unescaping methods are not symmetrical. That is,
> if you apply the second to the output of the first you will not always
> end up with the character sequence you start with. I.E.:-
>
> <script type="text/javascript">
> alert('&lt;'.escapeHTML().unescapeHTML()); //alerts "<"
> alert('&amp;lt;'.unescapeHTML().escapeHTML()) //alerts "&lt;"
> <script>
>
> - and that is pretty bad by anyone's standards (except maybe VK's).

I agree with you on this one. A bug was filed on this not too long
ago; I believe a fix has been checked into trunk and will be in the
next release.

Cheers,
Andrew

Richard Cornford

unread,
Apr 20, 2008, 12:07:37 AM4/20/08
to
Andrew Dupont wrote:

> On Apr 19, 11:02 am, Richard Cornford wrote:
>
> First off, full disclosure: I am a Prototype developer,
> and I know John Resig well and have immense respect for
> his library.
> I don't seek to change anyone's mind about libraries; I only
> want to ensure that dislike thereof is driven by thoughtful
> deliberation and/or a core philosophy difference. I welcome
> any constructive criticism and agree to disagree about the
> rest.

Who is going to be deciding what 'constructive' means in this context?

>>> You call foul for a logical fallacy against someone who was
>>> rebutting your claim that two immensely popular JavaScript
>>> libraries are "junk"?
>>
>> That wasn't a rebuttal, more of an excuse for using the code
>> regardless of any informed assessment of its quality.
>
> To be clearer: I saw it as an argument for why Thomas owned
> the burden of proof. If these libraries have won legitimacy
> on the mainstream Web,

That is an 'if'. Did they win legitimacy or are they just the next
evolution of the copy-and-paste script collections that were mainstay of
less commencement web developers of 5 or 6 years ago?

> then the opinion that they are shoddy is held by a minority,

Most informed quality assessments in technical areas will be held by a
minority.

> and they obviously need to do more persuading.

You mean that if someone is in a 'minority' then they must be wrong?
That is hardly an attitude that would allow progress through the
adoption of new ideas.

> Again, I worry about matters of taste being presented
> as facts.

You have not demonstrated that these are questions of taste. The last
time we discussed the prototype.js code here in detail (which was
version 1.6, in November last year) it demonstrated evidence of or its
authors (collectively, as nobody had corrected the code) not
understanding how the code they were writing was going to behave. Seeing
that brings everything into question, form the original design concepts
to every detail of its implementation. And those are not then questions
of taste but the inevitable consequence of evident ignorance among its
developers.

> I don't mean to say that all statements need to be
> prepended with "In my opinion," but Thomas was using his
> own taste to render judgement on a thread and shoo away
> its originator.

How do you know that? It seems likely to me that Thomas was using his
memory of the many (more or less detailed) discussions of Prototype.js
code that have happened here over the past few years to inform a general
assessment of the code.

> I think it's far more constructive to say "Most of us
> are not library fans, so you're unlikely to find useful
> answers here,"

That would not be a true statement (at least the second part of it, and
the first part if you take the word 'library' in its most general
sense).

> then point the way to the jQuery mailing list.

I have read enough of posts on the JQuery groups to be pretty sure
nobody is likely to much understanding their either. There is too much
of the blind leading the blind (and a huge proportion of questions never
seem to get answered at all).

> That'd accomplish the same goal with far less
> drama.

Accomplish which goal? Don't you think the OP, if he/she is still
reading this, has not learnt a great deal from this discussion despite
its initial response. There is a lot to be said for the uncensored
exchange of ideas in public.

>>> I count two right there: "appeal to ridicule" and "misplaced
>>> burden of proof." You're the one asserting they're junk. The
>>> burden of proof is yours.
>>
>> <snip>
>>
>> Where the 'proof' is already a matter of public record, and
>> familiar to anyone who has any more than superficial record
>> of participating in this group, there is no longer any
>> burden of proof at all.
>
> Perhaps the comp.lang.javascript FAQ needs an entry for this,
> then.

It has been discussed, and a number of draft entries proposed. But there
remains some dispute as to what an appropriate response to the question
should be. From the point of view of someone wanting a better
understanding of javascript or browser scripting who just happens to be
using some 'popular' library then they really would get the best answers
to their questions here, if they could present their questions in
isolation (from all of the unrelated and irrelevant stuff that those
libraries contain).

> A large portion of those who post on this newsgroup aren't
> participants or even lurkers;

If they post questions then they are participants.

> they come by only when they have problems. They can't
> be expected to catch up on the backstory.

They can. Expecting someone to do a few web searches before they ask to
be spoon fed is not too unreasonable.

>> In this case we have a very obviously stupid use of user
>> agent string based browser detection to make a decision that
>> would be more logically made with feature detection.
>

> Actually, no - no browser implements String#(un)escapeHTML,


> so feature detection would be pointless. We define that
> function earlier in the file,

Yes, I noticed the other two assignments to the - String.prototype -
later and realised that I was wrong about that.

> but redefine them for WebKit and IE because the String#replace
> approach is much, much faster in these two browsers (but much,
> much slower in FF and Opera).

Can you post a test-case that demonstrates that assertion? Historically
IE has been renowned for its lousy performance with string
manipulation, while Mozilla outperformed everyone else in that area.

But I noticed that the other two escaping/unescaping methods are nothing
like analogous to the two I posted. That is pretty bad in itself because
it means that the same source code is going to have different outcomes
depending on which browser it encounters, and the only way to avoid
falling foul of that would be to explicitly test any application using
the code on each and every browser and with a sufficiently divers set of
data to expose the situations where those inconsistencies might be
problematic. And that is something that is unlikely to actually happen
even in organisations that do do formal QA. After all, you missed the
fact that Safari/IE versions were defective yourselves so how could you
expect web developers who know no more than how to use a library find
the potential issues (or understand them if they did manifest
themselves).

It would be safer to forget about performance in this respect and just
use one set of escaping and unescaping methods. After all, these methods
are not used by the library itself, and are unlikely to be that heavily
used in applications.

> To be sure, there are other UA sniffs in Prototype that
> hard-liners would decry as unnecessary.

It is not 'unnecessary' that is the questionable aspect of browser
sniffing, but rather that it is technically baseless and demonstrably
ineffective.

<snip>


>> But that is not the rookie mistake I alluded to above. That
>> mistake is that the escaping and unescaping methods are not
>> symmetrical. That is, if you apply the second to the output
>> of the first you will not always end up with the character
>> sequence you start with. I.E.:-
>>
>> <script type="text/javascript">
>> alert('&lt;'.escapeHTML().unescapeHTML()); //alerts "<"
>> alert('&amp;lt;'.unescapeHTML().escapeHTML()) //alerts "&lt;"
>> <script>
>>
>> - and that is pretty bad by anyone's standards (except maybe
>> VK's).
>
> I agree with you on this one.

But I suppose that you would not agree that being able to find an
obvious rookie mistake in less then three seconds of looking (at a
library that is already a good few years old) tends to support the
"junk" assessment.

> A bug was filed on this not too long ago; I believe a
> fix has been checked into trunk and will be in the
> next release.

Well, it is a pretty simple fix, and I notice that the subject of my
last substantial criticism of the prototype's code has also been
removed.

Richard.


Thomas 'PointedEars' Lahn

unread,
Apr 20, 2008, 7:24:42 AM4/20/08
to
Gregor Kofler wrote:
> Lasse Reichstein Nielsen meinte:
>> The problem with the "with" construct is that you cannot control which
>> properties exist on the object. It differs between browsers (as
>> above), and it can be changed by other, misbehaved, libraries that
>> change Object.prototype.
>>
>> So there, I'm looking forward to hearing why it's so useful :)
>
> Let John respond:
>
> Gopal:
> would consider the "with" statement in JavaScript to be very harmful
> rather than being useful.
>
> John:
> @Gopal: There's a ton of things in JavaScript that can be "considered
> harmful". Since JavaScript is such an, extremely, flexible language you
> can make mistakes all over the place and not catch it. I just think that
> we need to have a better understanding of how the existing features work
> to give us a clearer way to move forward and to work with what we have.
>
> I hope this makes things *a lot* clearer.

Unfortunately, your "this speaks for itself" statement is too ambiguous
to stand as an argument by itself. What exactly are you trying to say here?

beegee

unread,
Apr 20, 2008, 12:35:01 PM4/20/08
to
On Apr 16, 12:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> beegee wrote:

> For that matter, at least JavaScript[tm] *is* a compiled language like Java.
> Don't confuse prompt execution with no-compilation.

Uh, no. Do you understand what compilation is? I mean, there are
javascript compilers but as far as I've heard, none in a browser yet.


> I think you miss the point. YUI is *supposedly* only "more like
> 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
> that its developers *supposedly* knew enough about the programming languages
> to unleash their full potential without having to resort to inefficient and
> error-prone detours of inventing "classes" and "initializers" where there
> are already prototypes and constructors.

You certainly do like to argue, don't you. It takes quite a talent to
obfuscate agreement to point of it sounding like disagreement.

Bob

Gregor Kofler

unread,
Apr 20, 2008, 3:10:46 PM4/20/08
to
Thomas 'PointedEars' Lahn meinte:

> Unfortunately, your "this speaks for itself" statement is too ambiguous
> to stand as an argument by itself. What exactly are you trying to say here?

I can only think of one advantage of with - saves some typing (and
script size). There might be others I don't know of. However, I also
know about the problem with with because of breaking the scope chain
(perhaps that's Gopal meant with his comment). There might be others I
don't know of.

Anyway, I expect that somebody claiming to be an "evangelist", "guru" or
"ninja" advertising the usefulness of "with", comes up with a more
substantial response than ...this. Well, maybe he doesn't want to give
away the best parts of the book.

Thomas 'PointedEars' Lahn

unread,
Apr 20, 2008, 4:44:31 PM4/20/08
to
beegee wrote:
> On Apr 16, 12:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> beegee wrote:
>> For that matter, at least JavaScript[tm] *is* a compiled language like
>> Java. Don't confuse prompt execution with no-compilation.
>
> Uh, no. Do you understand what compilation is?

Yes, do you?

> I mean, there are javascript compilers but as far as I've heard, none in
> a browser yet.

There are JIT-compilers.

>> > I think you miss the point. YUI is *supposedly* only "more like
>> > 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
>> > that its developers *supposedly* knew enough about the programming languages
>> > to unleash their full potential without having to resort to inefficient and
>> > error-prone detours of inventing "classes" and "initializers" where there
>> > are already prototypes and constructors.
>
> You certainly do like to argue, don't you. It takes quite a talent to
> obfuscate agreement to point of it sounding like disagreement.

We don't have an agreement here.

Thomas 'PointedEars' Lahn

unread,
Apr 20, 2008, 4:47:30 PM4/20/08
to
Gregor Kofler wrote:
> Thomas 'PointedEars' Lahn meinte:
>> Unfortunately, your "this speaks for itself" statement is too ambiguous
>> to stand as an argument by itself. What exactly are you trying to say here?
>
> [...] I expect that somebody claiming to be an "evangelist", "guru" or
> "ninja" advertising the usefulness of "with", comes up with a more
> substantial response than ...this. [...]

I see, and I agree with you here. Thanks for your explanation.


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

Lasse Reichstein Nielsen

unread,
Apr 20, 2008, 4:52:12 PM4/20/08
to
Andrew Dupont <goo...@andrewdupont.net> writes:

> If these libraries have won legitimacy on the mainstream
> Web, then the opinion that they are shoddy is held by a minority, and
> they obviously need to do more persuading.

There is no contradiction between the two opinions. Something can
easily win ligitimacy and still be shoddy.

In this particular case, I believe libraries like Prototype and JQuery
to be distruptive technologies (q.v.). I.e., they *are* qualitatively
inferior to doing things the hard (old) way. However, they work
/adequately/ for many things, and they allow people with less skill
than would otherwise be necessary to create pages that serve their
needs. I.e., they are /enabling/ without being perfect.

People here will keep complaining about the shoddy quality of
libraries while that quality, slowly, increases. This goes on until
the time when libraries have won, and anybody not using them is
putting themselves at a disadvantage.

Richard Cornford

unread,
Apr 20, 2008, 5:46:17 PM4/20/08
to
Lasse Reichstein Nielsen wrote:

> Andrew Dupont writes:
>
>> If these libraries have won legitimacy on the mainstream
>> Web, then the opinion that they are shoddy is held by a minority,
>> and they obviously need to do more persuading.
>
> There is no contradiction between the two opinions. Something can
> easily win ligitimacy and still be shoddy.
<snip>

And then there is the question of what constitutes "legitimacy" in the
first place. Were the copy-and-paste code collections of the last decade
illegitimate? Or endemic bad practices such as eval-ing runtime
constructed property accessor strings? Some would answered with a
resounding 'yes', while the people using them would probably have
disagreed.

> People here will keep complaining about the shoddy quality of
> libraries while that quality, slowly, increases.

If complaining was the only thing that went on here then that would end
up being futile and pointless. But over the years the discussions of the
many inherent problems with general purpose libraries had resulted in
some useful ideas about how to set about creating a code-base that could
offer high levels of code re-use, and a relatively low entry level,
while mitigating the problems inherent in the current approaches.

As to "slowly, increasing"; that is happening, at minimum because the
authors of those libraries cannot avoid becoming better informed about
how javascript works at time goes on. The really very obviously bad
aspects of their original cod do eventually get weeded out. But there is
a limit to how far that can go because while these things have 'users'
who expect ongoing support, bug fixes and updates for new browsers there
is never a possibility of going back and re-visiting the fundamental
design of the library's API. And if the original design was done at a
time when the original authors were writing code that was amenable to
improvements in its internal quality the odd are extremely good that
those shortcomings also manifested themselves in the API design itself.

So Prototype.js and QUery authors are struggling to mitigate the poor
performance that their code exhibits, and realistically can probably
nearly double its actual performance, but that is it. Aspects of the
original library design place a fixed cap on what can be achieved even
if all of the internal details were rendered optimal.

> This goes on until the time when libraries have won, and
> anybody not using them is putting themselves at a
> disadvantage.

There is no disadvantage from understanding javascript. In the event
that I was put in a position of being forced to use any of these
'popular' libraries the ability to understand how they work internally
would be a huge advantage in actually using them. Though that is
extremely unlikely to happen where I work now because none of the
existing popular libraries perform anywhere near fast enough for the web
applications I work on, and they never could.

Richard.


kangax

unread,
Apr 20, 2008, 11:47:25 PM4/20/08
to
On Apr 20, 5:46 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> There is no disadvantage from understanding javascript. In the event
> that I was put in a position of being forced to use any of these
> 'popular' libraries the ability to understand how they work internally
> would be a huge advantage in actually using them. Though that is
> extremely unlikely to happen where I work now because none of the
> existing popular libraries perform anywhere near fast enough for the web
> applications I work on, and they never could.

Is it possible to see the above mentioned web applications?

Thanks,
kangax

beegee

unread,
Apr 21, 2008, 9:44:55 AM4/21/08
to
On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> beegee wrote:

> > Uh, no.  Do you understand what compilation is?
>
> Yes, do you?

Transforming an english-like higher level programming language coded
program into a lower-level programming language coded program for the
benefits of speed and size.


> > I mean, there are javascript compilers but as far as I've heard, none in
> > a browser yet.
>
> There are JIT-compilers.

And what lower level language or instruction set are these JIT-
compilers compiling Javascript into to? Setting up a symbol table and
transforming to more efficient Javascript in the pre-processing pass
of Javascript is not compiling. All modern interpreters do this.
Again, there are real compilers for Javascript (Rhino) but they are
not in browsers yet although it's possible that FF 3.0 has one.


> >> > I think you miss the point.  YUI is *supposedly* only "more like
> >> > 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense
> >> > that its developers *supposedly* knew enough about the programming languages
> >> > to unleash their full potential without having to resort to inefficient and
> >> > error-prone detours of inventing "classes" and "initializers" where there
> >> > are already prototypes and constructors.
>
> > You certainly do like to argue, don't you.  It takes quite a talent to
> > obfuscate agreement to point of it sounding like disagreement.
>
> We don't have an agreement here.

Really? Are you saying the creators of YUI do not know enough about
javascript to avoid the pitfalls of JQuery and Prototype? I'm the
first to admit that YUI has some speed and object model problems but
I'm not sure that mocking the libary for only *supposedly* being
better than the others without some kind of specifics is really a
point view.

Bob

Zeroglif

unread,
Apr 21, 2008, 2:50:56 PM4/21/08
to
On 21 апр, 17:44, beegee <bgul...@gmail.com> wrote:
> On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > beegee wrote:
> > > Uh, no. Do you understand what compilation is?
>
> > Yes, do you?
>
> Transforming an english-like higher level programming language coded
> program into a lower-level programming language coded program for the
> benefits of speed and size.

Brendan Eich (JavaScript):
"Client JavaScript reads source from SCRIPT tag contents, but compiles
it into an internal bytecode for faster interpretation."

Eric Lippert (JScript):
"JScript Classic acts like a compiled language in the sense that
before any JScript Classic program runs, we fully syntax check the
code, generate a full parse tree, and generate a bytecode. We then run
the bytecode through a bytecode interpreter. In that sense, JScript is
every bit as "compiled" as Java. The difference is that JScript does
not allow you to persist or examine our proprietary bytecode. Also,
the bytecode is much higher-level than the JVM bytecode -- the JScript
Classic bytecode language is little more than a linearization of the
parse tree, whereas the JVM bytecode is clearly intended to operate on
a low-level stack machine."

Andrew Dupont

unread,
Apr 21, 2008, 4:11:59 PM4/21/08
to
On Apr 19, 11:07 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> Who is going to be deciding what 'constructive' means in this context?

Each individual on his own. Or, in other words: say what you want to
say, and I'll brush off anything I think is unwarranted. I'm not
setting conditions for prior restraint here.

> You mean that if someone is in a 'minority' then they must be wrong?
> That is hardly an attitude that would allow progress through the
> adoption of new ideas.

I never said anything of the sort. I said the minority need to do more
_persuading_. You stated that these libraries were junk as though it
were common knowledge. Clearly it isn't common knowledge.

> You have not demonstrated that these are questions of taste. The last
> time we discussed the prototype.js code here in detail (which was
> version 1.6, in November last year) it demonstrated evidence of or its
> authors (collectively, as nobody had corrected the code) not
> understanding how the code they were writing was going to behave. Seeing
> that brings everything into question, form the original design concepts
> to every detail of its implementation. And those are not then questions
> of taste but the inevitable consequence of evident ignorance among its
> developers.

I hold that any technology decision is a question of taste. There is
no objective "better" in the sense of Ruby vs. Python, or vi vs.
emacs; there is only the subjective "better" — whichever best serves
the user's own needs.

Naturally, this does _not_ mean that everything is relative, or that
it's not worth having passionate arguments thereabout. I implied as
much in my music analogy: friends argue among themselves over which
band is "better," but they all realize that taste is the ultimate
arbiter. These arguments become tiresome only when people dig trenches
and start speaking in absolutes.

> How do you know that? It seems likely to me that Thomas was using his
> memory of the many (more or less detailed) discussions of Prototype.js
> code that have happened here over the past few years to inform a general
> assessment of the code.

And I submit that is a matter of taste. Bugs are bugs, of course, and
we welcome bug reports. But you've gone further than that; you've
inferred from "evidence" that code in Prototype does not do what its
author means for it to do.

> > I think it's far more constructive to say "Most of us
> > are not library fans, so you're unlikely to find useful
> > answers here,"
>
> That would not be a true statement (at least the second part of it, and
> the first part if you take the word 'library' in its most general
> sense).

Then write your own words. That way they'll be _from the heart_. You
know the point I'm trying to make.

>
> > then point the way to the jQuery mailing list.
>
> I have read enough of posts on the JQuery groups to be pretty sure
> nobody is likely to much understanding their either. There is too much
> of the blind leading the blind (and a huge proportion of questions never
> seem to get answered at all).

>
> > That'd accomplish the same goal with far less
> > drama.
>
> Accomplish which goal? Don't you think the OP, if he/she is still
> reading this, has not learnt a great deal from this discussion despite
> its initial response. There is a lot to be said for the uncensored
> exchange of ideas in public.

The word "censorship" doesn't come within miles of this thread. I do
not own a telecommunications company; I don't have the means or
authority to "censor" anyone.

I can only imagine the OP was interested in the free exchange of ideas
when he asked you why you thought jQuery and Prototype were junk. I'm
arguing that he'd have learned far more from a link to a page called
"Why I, Richard Cornford, Think Prototype and jQuery Are Junk" than
from this low-signal, high-noise snark-off.

> > Perhaps the comp.lang.javascript FAQ needs an entry for this,
> > then.
>
> It has been discussed, and a number of draft entries proposed. But there
> remains some dispute as to what an appropriate response to the question
> should be. From the point of view of someone wanting a better
> understanding of javascript or browser scripting who just happens to be
> using some 'popular' library then they really would get the best answers
> to their questions here, if they could present their questions in
> isolation (from all of the unrelated and irrelevant stuff that those
> libraries contain).

That last sentence is the answer to such a FAQ. Even a link to that
question and answer would be more helpful than what has happened in
this thread.

> > A large portion of those who post on this newsgroup aren't
> > participants or even lurkers;
>
> If they post questions then they are participants.

I mean that they weren't participants before their first post. Many
posters, I would venture, only come here when they need help, and
therefore aren't already familiar with the quirks of the community.

> > they come by only when they have problems. They can't
> > be expected to catch up on the backstory.
>
> They can. Expecting someone to do a few web searches before they ask to
> be spoon fed is not too unreasonable.

Please search this newsgroup for the terms "Prototype" and/or "jQuery"
and see how quickly you find a well-summarized critique of either
library.

> >> In this case we have a very obviously stupid use of user
> >> agent string based browser detection to make a decision that
> >> would be more logically made with feature detection.
>
> > Actually, no - no browser implements String#(un)escapeHTML,
> > so feature detection would be pointless. We define that
> > function earlier in the file,
>
> Yes, I noticed the other two assignments to the - String.prototype -
> later and realised that I was wrong about that.
>
> > but redefine them for WebKit and IE because the String#replace
> > approach is much, much faster in these two browsers (but much,
> > much slower in FF and Opera).
>
> Can you post a test-case that demonstrates that assertion? Historically
> IE has been  renowned for its lousy performance with string
> manipulation, while Mozilla outperformed everyone else in that area.

I don't have a test-case. The change was made one year ago by Thomas
Fuchs [1]. You're welcome to ask him, though I suspect he'll punch me
in the sternum for having dragged him into this.

>
> But I noticed that the other two escaping/unescaping methods are nothing
> like analogous to the two I posted. That is pretty bad in itself because
> it means that the same source code is going to have different outcomes
> depending on which browser it encounters, and the only way to avoid
> falling foul of that would be to explicitly test any application using
> the code on each and every browser and with a sufficiently divers set of
> data to expose the situations where those inconsistencies might be
> problematic. And that is something that is unlikely to actually happen
> even in organisations that do do formal QA. After all, you missed the
> fact that Safari/IE versions were defective yourselves so how could you
> expect web developers who know no more than how to use a library find
> the potential issues (or understand them if they did manifest
> themselves).

Nothing I say in our defense will satisfy you, because you seem to
want a level of certitude that I can't guarantee. I could say that we
have extensive unit tests, but clearly they were not extensive enough
to catch the bug that you pointed out — though that bug was noticed in
the wild, submitted to our tracker, and patched, and more unit tests
were added in the process. This is how open-source software works.

I can't guarantee that any of us will write bug-free code on the first
pass, any more than you can guarantee that you won't spell another
word incorrectly for the rest of your life. instead, we have a testing
process meant to ferret out as many self-introduced bugs as possible.
When that fails, we rely on the community to file tickets. No doubt
you have rolled your eyes by now, so I'll just move on.

>
> It would be safer to forget about performance in this respect and just
> use one set of escaping and unescaping methods. After all, these methods
> are not used by the library itself, and are unlikely to be that heavily
> used in applications.
>
> > To be sure, there are other UA sniffs in Prototype that
> > hard-liners would decry as unnecessary.
>
> It is not 'unnecessary' that is the questionable aspect of browser
> sniffing, but rather that it is technically baseless and demonstrably
> ineffective.

You haven't demonstrated that anything is baseless or ineffective;
you've only revealed a different set of priorities. You'd rather have
100% guaranteed behavior even if it meant a wildly-varying performance
graph across browsers. I'd rather have the reverse.

> But I suppose that you would not agree that being able to find an
> obvious rookie mistake in less then three seconds of looking (at a
> library that is already a good few years old) tends to support the
> "junk" assessment.

The check-in is only one year old. It is Thomas's bug, but he is no
rookie, so I can only surmise that we all make silly mistakes
sometimes. Bad luck for him that he managed to stumble upon your
Shibboleth Bug(TM).

> > A bug was filed on this not too long ago; I believe a
> > fix has been checked into trunk and will be in the
> > next release.
>
> Well, it is a pretty simple fix, and I notice that the subject of my
> last substantial criticism of the prototype's code has also been
> removed.

We listen to criticism, we read bug reports, and we constantly search
for ways to improve the feedback loop. So does John Resig, by the way,
so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
mistake.

Cheers,
Andrew

Matt Kruse

unread,
Apr 21, 2008, 4:54:18 PM4/21/08
to
On Apr 19, 3:06 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> Interestingly I observed Matt Kruse (who is the nearest thing to a
> supporter JQuery has among the regular contributors to this group, and
> someone who can easily outgun anyone directly involved in JQuery
> development when it comes to javascript)

Wow, given your view of the jQuery dev team, I'm not sure if that's
even close to a compliment ;)

> directly asked however was
> responsible for the - if ( typeof array != "array" ) - code to own up to
> it in a post on the JQuery development group. However, when I checked
> back a week later to see if anyone had the intellectual integrity to own
> up to their mistake I found that Matt's post had been deleted from the
> group.

If you're referring to this point:
http://groups.google.com/group/jquery-dev/msg/54b54712bd48ec83
then I can still find it.

Unfortunately, it hasn't generated any further discussion as I thought
it certainly warranted.
It's this kind of indifference about truly embarrassing code in the
jQuery source that I find most troubling.
They seem to be more interested in adding a new CSS3 selector or
saving 20 bytes by condensing some code than in correcting bad
programming practices.

I think John Resig loves Javascript and is probably learning more
about it as time goes on, but I suspect that his primary goal of
evangelizing jQuery is to enable the writing of more books and
attending more speaking engagements. Otherwise I can't comprehend why
some of these issues haven't gotten instant attention as I believe
they deserve.

Matt Kruse

Matt Kruse

unread,
Apr 21, 2008, 5:04:48 PM4/21/08
to
On Apr 21, 3:11 pm, Andrew Dupont <goo...@andrewdupont.net> wrote:
> We listen to criticism, we read bug reports, and we constantly search
> for ways to improve the feedback loop. So does John Resig, by the way,
> so I'd suggest you file a bug on jQuery's Trac about the "makeArray"
> mistake.

I know nothing about Prototype's "feedback loop" but I'll say that my
impression of the jQuery loop has been that it is very fond of praise
and quick to dismiss or ignore genuine critiques about its core code
or design decisions.

I've made a number of attempts to make suggestions that I consider to
be no-brainers... getting rid of unnecessary browser sniffs,
optimizing loops which are extremely inefficient, making the
isFunction() function work more more closely to how it was
(misguidedly) intended, removing some code that is completely
unnecessary (makeArray), and reporting some bugs.

I've gotten a lackluster response to most posts, even though I would
consider some of these issues to be extremely important in cleaning up
the jQuery code, making it faster, and improving its overall quality.

I'm quite fond of much of the API that jQuery offers, the coding style
that it often enables, and the ease with which it enables new/amateur
developers to create working code in the right environments. If I had
the time and interest, I would probably be inclined to branch the code
into something more solid, fix many of the issues that exist, and
remove some of the overloading that makes the API kind of a mess.

But since I lack both the time and interest, I'm still trying to push
the jquery dev team into improving the code and hopefully bringing
jQuery up to par as a library that can withstand the scrutiny of
experienced js developers. Even if they would still not choose to use
it.

Matt Kruse

dhtml

unread,
Apr 21, 2008, 5:21:26 PM4/21/08
to
On Apr 19, 9:02 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> Andrew Dupont wrote:
> > On Apr 17, 10:57 am, Thomas 'PointedEars' Lahn wrote:

> One of the arguments paraded in favour of these libraries is that they
> are examined, worked on and used by very large numbers of people, and so
> they should be of reasonably high quality because with many eyes looking
> at the code obvious mistakes should not go unnoticed. My experience of
> looking at code from the various 'popular' libraries suggests that this
> is a fallacy, because (with the exception of YUI (for obvious reasons))

Not obvious.

There's plenty of bugs YUI. A good number of them are reported in the
bugtracker (public) yet others are reported on the Yahoo internal bug
tracker (Bugzilla). Others may still be unfiled.

I don't 100% agree that the problem is not that the authors aren't
smart enough. A lot of these problems come from the process. Things
like having one guy own such-such piece of code, or the code freezes.
Or testing the happy path of maybe 20% of an object's methods.

> all of the 'popular' library contain numerous obviously stupid mistakes.

Including YUI.

They also have bug trackers. As Andrew pointed out, Prototype does
too.

A fix for the bug that was demonstrated seems to be by simply putting
the &amp; last.

String.prototype.unescapeHTML = function() {
return this.replace(/&lt;/g,'<')
.replace(/&gt;/g,'>')
.replace(/&amp;/g,'&');
};

That would need to be tested out though.

Right?

Garrett

> Richard.

beegee

unread,
Apr 22, 2008, 9:39:54 AM4/22/08
to
On Apr 21, 2:50 pm, Zeroglif <zerog...@gmail.com> wrote:

Thanks for the quotes. I thought, at first, from reading them that I
had been totally wrong about compilation of javascript. Then I read
deeper in the second quote about what the byte code is. And really,
it is not a true compilation. It is still a first pass optimization.
In fact I wouldn't be surprised if the same machine that can interpret
unprocessed javascript, interprets the bytecode.

Bob

Thomas 'PointedEars' Lahn

unread,
Apr 22, 2008, 2:09:44 PM4/22/08
to
beegee wrote:
> Thanks for the quotes. I thought, at first, from reading them that I had
> been totally wrong about compilation of javascript. Then I read deeper
> in the second quote about what the byte code is. And really, it is not a
> true compilation. It is still a first pass optimization.

Winding around your error, are you? It is true compilation, as true as
byte-code compilation in Java is, for example.

> In fact I wouldn't be surprised if the same machine that can interpret
> unprocessed javascript, interprets the bytecode.

Bytecode is platform-independent, of course, because a Virtual Machine
interprets it. As I have said, in that sense at least JavaScript[tm],
and as it turns out JScript also, are compiled languages.


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

VK

unread,
Apr 22, 2008, 4:34:45 PM4/22/08
to
On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Bytecode is platform-independent, of course, because a Virtual Machine
> interprets it. As I have said, in that sense at least JavaScript[tm],
> and as it turns out JScript also, are compiled languages.

???

What is interpreted language then for you? Read next line of code -
Parse for token - Create internal code - Execute - Forgot this code -
Cleared the memory - Moved to the next line? Something like that?
There is no such engine since Enigma and Cyclometer at least :-)

Javascript is being stored and delivered to the engine in the raw text
source code format. The engine naturally compiles it to be able to use
so the engine works with compiled code - but Javascript is not a
compiled language. Try to see the difference, if you can.

P.S. JScript.NET _is_ a compiled language.