From: Andrew Dupont on
On Apr 19, 11:02 am, "Richard Cornford" <Rich...(a)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
From: Richard Cornford on
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.


From: Thomas 'PointedEars' Lahn on
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?


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>
From: beegee on
On Apr 16, 12:44 pm, Thomas 'PointedEars' Lahn <PointedE...(a)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
From: Gregor Kofler on
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.

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