|
From: Andrew Dupont on 19 Apr 2008 21:33 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('<'.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
From: Richard Cornford on 20 Apr 2008 00:07 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('<'.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.
From: Thomas 'PointedEars' Lahn on 20 Apr 2008 07:24 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 20 Apr 2008 12:35 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 20 Apr 2008 15:10
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 |