to learn jQuery if already using prototype
in [JavaScript]
|
From: Matt Kruse on 22 Apr 2008 17:16 On Apr 22, 3:34 pm, VK <schools_r...(a)yahoo.com> wrote: > On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...(a)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. > 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. I hate to agree with VK, but I do. The terms "compiled" and "interpreted" to refer to programming languages are both vague and don't have exact meanings to begin with. They are just labels. Javascript is interpreted rather than compiled because the raw source code is delivered to the end user. Of course it is turned into a machine-readable form before execution - all languages are. Else the term "interpreted language" would be meaningless. Javascript is not pre-compiled into byte code which is then delivered to the client's VM to execute (typically). Is there a standard javascript bytecode definition that all javascript VM's will execute identically? In contrast, a language like Java is considered to be a "compiled" language because you can deliver the pre-compiled .class files, even though they still require a VM to execute, but compiled code is not the original source. The line there is even blurry because you _can_ deliver the source and have it compiled "on the fly". In the end, the discussion of the labels "compiled" and "interpreted" is pointless because the reality of how it works is known. Especially when the terms do not have "scientific" meanings and are open to interpretation. Matt Kruse
From: Thomas 'PointedEars' Lahn on 22 Apr 2008 17:38 Matt Kruse wrote: > On Apr 22, 3:34 pm, VK <schools_r...(a)yahoo.com> wrote: >> On Apr 22, 10:09 pm, Thomas 'PointedEars' Lahn <PointedE...(a)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. >> 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. > > I hate to agree with VK, but I do. Your loss. > Javascript is not pre-compiled into byte code which is then delivered to > the client's VM to execute (typically). Typically (JavaScript[tm] and JScript would cover, say, 95% of the market of ECMAScript-compliant script engines), it is. You appear to have overlooked the quotations by their inventors. > Is there a standard javascript bytecode definition that all javascript > VM's will execute identically? There isn't even *a* "javascript VM" to begin with. All JavaScript[tm] engines will have to use SpiderMonkey or Rhino; for the former, we now have its inventors assertion that there is a bytecode specification; for the latter, since it is Java-based, we can assume it has. All JScript and JScript .NET engines would have to be that which Microsoft provides with the Microsoft Script Engine (since it's closed source), so no surprise there either. > The terms "compiled" and "interpreted" to refer to programming languages > are both vague and don't have exact meanings to begin with. They are just > labels. This is simply wrong. RTFM. > [...] In the end, the discussion of the labels "compiled" and > "interpreted" is pointless because the reality of how it works is known. Parse error. > Especially when the terms do not have "scientific" meanings and are open > to interpretation. No, see above. But what matters here (if it matters at all; to remind you, the cause of this subthread was a website that compared Prototype.js to Java and jQuery to Ruby) is that JavaScript and JScript code is compiled *first*. This does not apply to all languages that are finally interpreted. What the both of you seem to overlook is that compilation and interpretation can complement each other. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Richard Cornford on 22 Apr 2008 20:39 On Apr 21, 10:21 pm, dhtml wrote: > On Apr 19, 9:02 am, Richard Cornford 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. Who is talking about bugs? Take this code from the dojo library:- | if( | elem == null || | ((elem == undefined)&&(typeof elem == "undefined")) | ){ | dojo.raise("No element given to dojo.dom.setAttributeNS"); | } The rules for javascirpt dictate then whenever the - (elem == undefined) - expression is evaluated (that is, whenever - elem == null - is false) the result of the expression must be false, and so the - (typeof elem == "undefined") - expression just cannot ever be evaluated. The bottom line is that if the author of that code had understood javascript when writing it the whole thing would have been:- if(elem == null){ dojo.raise("No element given to dojo.dom.setAttributeNS"); } - or possibly:- if(elem){ dojo.raise("No element given to dojo.dom.setAttributeNS"); } - as there should be no issues following from pushing other primitive values that have falseness through the exception throwing path as well null and undefined. The first is not a bug; it does exactly what it was written to, and does it reliably and consistently. But it is a stupid mistake on the part of its 'programmer', and survived in the dojo source for long enough to be observed because nobody involved with dojo knew enough actual javascript to see that it was a stupid mistake and correct it. YUI may contain bugs but it does not contain this type of stupid mistake because at least one person (and it only takes one) knows javascript well enough to be able to see this type of thing and stop it (presumably at source by ensuring any potential transgressors become better informed bout the language they are using). Now JQuery contains the infamous - ( typeof array != "array" )- stupid mistake, and Prototype.js (at least version 1.6 (which is not that long ago)) contained the attempt to conditionally employ function declarations that only worked by coincidence. Neither of those are bugs as such (they don't stop the respective code from 'working' (at least to the limited degree to which it is designed to 'work')), but they are precisely the type of stupid mistake that follows from code authors having a minimal understanding of the language they are using. And where those authors are part of a collective they don't speak for the knowledge of the specific author responsible but instead indicate the level of understanding of the _most_ knowledgeable person involved. <snip> > A fix for the bug that was demonstrated seems to be by > simply putting the & last. > > String.prototype.unescapeHTML = function() { > return this.replace(/</g,'<') > .replace(/>/g,'>') > .replace(/&/g,'&'); > }; > > That would need to be tested out though. No it does not need to be test, it is correct. The general rule is that the character significant in escaping needs to be processed first when escaping and last when unescaping. > Right? Absolutely. It is a simple bug, and a mistake that in my experience is made by nearly every programmer who comes to the issues of encoding/escaping for the web for the first time (pretty much no matter what their previous level of experience in other areas). It is something that I have learnt to double check, habitually, and that is the reason that I spotted it so quickly. Richard.
From: Richard Cornford on 22 Apr 2008 20:39 Matt Kruse wrote: >On Apr 19, 3:06 pm, Richard Cornford 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 ;) Well, you know that I like to call things the way that I see them ;-) They need you a lot more than you need them. >> 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. <snip> That is odd. I can see your post from my computer at home but still not from work. I cannot believe that our firewall is capable of being sufficiently subtle as to be censoring a single post in a thread (and certainly not without messing the rest of the page up in the process). It does have some very silly aspects to its configuration, like we cannot view the MSDN page on the - responseXML - property of HTTP XML request objects because of its URL contains the character sequence made from the last two letters of "response" and the first letter of "XML", but that sort of thing should not come into this case. Richard.
From: Richard Cornford on 22 Apr 2008 20:39
Andrew Dupont wrote: > On Apr 19, 11:07 pm, Richard Cornford wrote: >> Who is going to be deciding what 'constructive' means in >> this context? > > Each individual on his own. Maybe, but there are circumstances were the best advice possible is to delete something and start again from scratch, but most individuals who hear that advice don't regard it is constructive when they do. > Or, in other words: say what you want to say, and I'll > brush off anything I think is unwarranted. Presumably you mean you will brush off anything that you regard as unwarranted? > I'm not > setting conditions for prior restraint here. Requiring what you get to be "constructive" is not a condition? >> 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_. OK. Why, what is in it for them? > You stated that these libraries were junk I very much doubt that I did. > as though it were common knowledge. If I had it would not be because it was common knowledge, but rather because it was the case. > Clearly it isn't common knowledge. There are lots of things that are true but are not common knowledge. And that is even if you are not taking 'common knowledge' as referring to what is commonly know by ordinary people (ordinarily people mostly being people who have no idea what javascript is in the first place, and little interest in knowing). >> 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. Decisions suggest an informed process of deciding. Otherwise we may be dealing with no more than the accumulated outcome of sequences of random influences, misconceptions and learnt incantations. If someone writes:- <script type="javascript"> var url = " ... "; ... document.write('<scr'+'ipt type="javascript" src="'+url+'"></scr'+'ipt>'); </script> - there are things about that that are not a question of taste at all. That the mark-up is invalid is an objective fact. That there are two unnecessary concatenation operations is a fact, and that the apparent justification for those additional concatenation operations has missed the point is also a fact. Some decisions to do things, or not to do things are not a question of taste, but rather the consequences of understanding. > There is no objective "better" in the sense of Ruby vs. > Python, or vi vs. emacs; Maybe, but there is an objective "better" in the sense of using:- if(elem == null){ dojo.raise("No element given to dojo.dom.setAttributeNS"); } - in place of:- if( elem == null || ((elem == undefined)&&(typeof elem == "undefined")) ){ dojo.raise("No element given to dojo.dom.setAttributeNS"); } - because the latter is just silly in comparison to the former (as they both have precisely the same outcome). > there is only the subjective "better" - whichever best > serves the user's own needs. There seems to be an unfortunate tendency among web developers to lose site of who the "user" actually is. The user (for web developers) is the poor sod looking at an alarming little grey box with yellow 'warning' triangle just above their web browser's window that says "Your browser does not support AJAX" and wondering what the hell they are expected to do about it (get it tickets for the next match or something?). > 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. Thomas's memory is a matter of taste? > Bugs are bugs, Not really. There are bugs and there are bugs. A typo in the middle of a large block of code is something that can happen to anyone, and it could also easily be missed by others reviewing that code. A glaring error in something that experience would teach you to always double check and also should be exposed in any reasonable testing is something else entirely. > 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. No, I said that the evidence was that Prototype.js was (at least in November last year) only doing what was (apparently) expected by coincidence; that it had not actually been programmed to do what it was doing. I also implied that were that evidence existed it was reasonable to question the understanding of javascript that informed all of the design decisions that occurred prior to that code being written; such as the underlying design approach and the resulting API. (I have also pointed out that Prototype.js is incredibly slow at doing pretty much anything complex) >>> 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. I did. > That way they'll be _from the heart_. No they would not. They would be from the head. > You know the point I'm trying to make. Not really. <snip> >> ... . 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. Well this is Usenet so there is no censorship. > I do not own a telecommunications company; I don't have > the means or authority to "censor" anyone. You would not have the means to censor Usenet even if you did own a telecommunications company. > 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. He (do you have any evidence that he is a 'he'?) did not ask me anything. <snip> >> ... . 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. It is already in the FAQ in as many words. > Even a link to that question and answer would be more > helpful than what has happened in this thread. Not really. The OP is not asking for specific information on javascript, and there is no code to post in relation to the question. The question asked was along the lines of "having learnt something about Prototype.js should I then spend some time learning something about JQuery". To which the direct answer appears to have been "no" (if a little more strongly/colourfully expressed). My answer, in as far as I answered the question at all, was 'learn javascript and browser scripting first and then you can make up your own mind'. >>> 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. And they weren't human before they were conceived. > Many posters, I would venture, only come here when they > need help, and therefore aren't already familiar with the > quirks of the community. There is no need to "venture" that, it is self-evidently true. >>> 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" What are you expecting? You give a library the same name as a significant aspect of the language it written in and then cannot find specific references to it in the archives of a newsgroup dedicated to that language. It was a predictably bad choice of name. > and/or "jQuery" and see how quickly you find a well-summarized > critique of either library. Who said finding that sort of thing out was going to be quick? I bet the search would still turn out to be informative even if it could not be instantaneous. <snip> >> 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. He won't have to. I will just dismiss this as yet another unsubstantiated rumour. <snip> >>> 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 How would you expect me to demonstrate the lack of any technical foundation for UA string based browser sniffing? I can hardly point to something that doesn't exist and say "there is the absence of any technical foundation for all to see". Of course if there was any technical foundation then that could be pointed at quite easily, but as the navigator.userAgent string is a reflection of the HTTP User Agent header then any such direction must lead to the definition of the header in the HTTP specification, and that definition pretty much says that the User Agent header is an arbitrary sequined of zero or more characters that is not even required to be consistent from one request to the next (i.e. that it is not specified as being a source of information at all). > or ineffective; Does that need to be demonstrated (again)? It is known that web browsers use User Agent headers that are indistinguishable form the default UA header of IE, so how could it be effective to discriminate between browsers using the UA string whenever two different browsers use UA headers that are indistinguishable? > you've only revealed a different set of priorities. > You'd rather have 100% guaranteed behavior I would certainly rather have consistent and predictable behaviour before worrying about performance. > even if it meant a wildly-varying performance > graph across browsers. Where is the evidence for "wildly-varying"? I don't think escaping/unescaping methods are going to be used frequently enough for their specific performance to mattered that much at all. If you used them internally, or they were fundamental to using the library in the first place then their performance would be much more significant. > I'd rather have the reverse. So you would not be certain what the code was going to do, but you would know that whatever it did it would take about the same amount of time to do it wherever it was running? I certainly do not have a taste for that design philosophy. >> 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, Hansom is as hansom does. But that was not really my point. One of the things that gets proposed as a justification for libraries of this sort (a reason for their not being junk by virtue of what they are) is that with many individuals contributing there are plenty of eyes looking at the code to be able to find these sorts of things and fix them up front. But if it takes me three seconds to find what nobody else had noticed then it must be the case that there is nobody involved looking with my eyes. > 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). Bad luck for everyone else who manage to let it pass unnoticed. >>> 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. That all sounds very 'marketing-speak'. > So does John Resig, by the way, so I'd suggest you file a bug > on jQuery's Trac about the "makeArray" mistake. Why? Polishing the handrails on the Titanic may have made it more appealing to look at but didn't change the rate at which it sank after the design flaw coincided with the iceberg. Richard. |