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.
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
Questions regarding prototype.js are better to be asked at
http://groups.google.com/group/rubyonrails-spinoffs
Best,
kangax
> 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.
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>
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.
I want popcorn.
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.
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
> 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
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 ;-)
"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, 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.
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.
> 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>
Or this one:
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
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.
Thanks, Gregor and RobG
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.
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
Your are invited to pray here:
http://ejohn.org/blog/state-of-the-secrets/
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>
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".)
> 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.'
> 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.
<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
Almost the same situation with named FunctionExpression:
(function () {
var watch = 0;
(function f() {
alert(watch); //-> native code...
})();
})();
> 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?
No, Lasse, it is "special" object in scope chain created to keep
FunctionExpression name only (ES 13), no bug here.
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
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...
};
> "Special" object? No, it's not:
Excuse me, I was mistaken!
> 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.
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.
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,'&')
| .replace(/</g,'<')
| .replace(/>/g,'>');
| },
| unescapeHTML: function() {
| return this.replace(/&/g,'&')
| .replace(/</g,'<')
| .replace(/>/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('<'.escapeHTML().unescapeHTML()); //alerts "<"
alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
<script>
- and that is pretty bad by anyone's standards (except maybe VK's).
Richard.
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
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>
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.
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.
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.
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('<'.escapeHTML().unescapeHTML()); //alerts "<"
> alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
> <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
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('<'.escapeHTML().unescapeHTML()); //alerts "<"
>> alert('&lt;'.unescapeHTML().escapeHTML()) //alerts "<"
>> <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.
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?