to learn jQuery if already using prototype
in [JavaScript]
|
From: beegee on 21 Apr 2008 09:44 On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > beegee wrote: > > Uh, no. Do you understand what compilation is? > > Yes, do you? Transforming an english-like higher level programming language coded program into a lower-level programming language coded program for the benefits of speed and size. > > I mean, there are javascript compilers but as far as I've heard, none in > > a browser yet. > > There are JIT-compilers. And what lower level language or instruction set are these JIT- compilers compiling Javascript into to? Setting up a symbol table and transforming to more efficient Javascript in the pre-processing pass of Javascript is not compiling. All modern interpreters do this. Again, there are real compilers for Javascript (Rhino) but they are not in browsers yet although it's possible that FF 3.0 has one. > >> > I think you miss the point. YUI is *supposedly* only "more like > >> > 'Javascript'" (whatever that might be) than Prototype or jQuery in the sense > >> > that its developers *supposedly* knew enough about the programming languages > >> > to unleash their full potential without having to resort to inefficient and > >> > error-prone detours of inventing "classes" and "initializers" where there > >> > are already prototypes and constructors. > > > You certainly do like to argue, don't you. It takes quite a talent to > > obfuscate agreement to point of it sounding like disagreement. > > We don't have an agreement here. Really? Are you saying the creators of YUI do not know enough about javascript to avoid the pitfalls of JQuery and Prototype? I'm the first to admit that YUI has some speed and object model problems but I'm not sure that mocking the libary for only *supposedly* being better than the others without some kind of specifics is really a point view. Bob
From: Zeroglif on 21 Apr 2008 14:50 On 21 ÁÐÒ, 17:44, beegee <bgul...(a)gmail.com> wrote: > On Apr 20, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: > > > beegee wrote: > > > Uh, no. Do you understand what compilation is? > > > Yes, do you? > > Transforming an english-like higher level programming language coded > program into a lower-level programming language coded program for the > benefits of speed and size. Brendan Eich (JavaScript): "Client JavaScript reads source from SCRIPT tag contents, but compiles it into an internal bytecode for faster interpretation." Eric Lippert (JScript): "JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as "compiled" as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode -- the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine."
From: Andrew Dupont on 21 Apr 2008 16:11 On Apr 19, 11:07 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > Who is going to be deciding what 'constructive' means in this context? Each individual on his own. Or, in other words: say what you want to say, and I'll brush off anything I think is unwarranted. I'm not setting conditions for prior restraint here. > You mean that if someone is in a 'minority' then they must be wrong? > That is hardly an attitude that would allow progress through the > adoption of new ideas. I never said anything of the sort. I said the minority need to do more _persuading_. You stated that these libraries were junk as though it were common knowledge. Clearly it isn't common knowledge. > You have not demonstrated that these are questions of taste. The last > time we discussed the prototype.js code here in detail (which was > version 1.6, in November last year) it demonstrated evidence of or its > authors (collectively, as nobody had corrected the code) not > understanding how the code they were writing was going to behave. Seeing > that brings everything into question, form the original design concepts > to every detail of its implementation. And those are not then questions > of taste but the inevitable consequence of evident ignorance among its > developers. I hold that any technology decision is a question of taste. There is no objective "better" in the sense of Ruby vs. Python, or vi vs. emacs; there is only the subjective "better" whichever best serves the user's own needs. Naturally, this does _not_ mean that everything is relative, or that it's not worth having passionate arguments thereabout. I implied as much in my music analogy: friends argue among themselves over which band is "better," but they all realize that taste is the ultimate arbiter. These arguments become tiresome only when people dig trenches and start speaking in absolutes. > How do you know that? It seems likely to me that Thomas was using his > memory of the many (more or less detailed) discussions of Prototype.js > code that have happened here over the past few years to inform a general > assessment of the code. And I submit that is a matter of taste. Bugs are bugs, of course, and we welcome bug reports. But you've gone further than that; you've inferred from "evidence" that code in Prototype does not do what its author means for it to do. > > I think it's far more constructive to say "Most of us > > are not library fans, so you're unlikely to find useful > > answers here," > > That would not be a true statement (at least the second part of it, and > the first part if you take the word 'library' in its most general > sense). Then write your own words. That way they'll be _from the heart_. You know the point I'm trying to make. > > > then point the way to the jQuery mailing list. > > I have read enough of posts on the JQuery groups to be pretty sure > nobody is likely to much understanding their either. There is too much > of the blind leading the blind (and a huge proportion of questions never > seem to get answered at all). > > > That'd accomplish the same goal with far less > > drama. > > Accomplish which goal? Don't you think the OP, if he/she is still > reading this, has not learnt a great deal from this discussion despite > its initial response. There is a lot to be said for the uncensored > exchange of ideas in public. The word "censorship" doesn't come within miles of this thread. I do not own a telecommunications company; I don't have the means or authority to "censor" anyone. I can only imagine the OP was interested in the free exchange of ideas when he asked you why you thought jQuery and Prototype were junk. I'm arguing that he'd have learned far more from a link to a page called "Why I, Richard Cornford, Think Prototype and jQuery Are Junk" than from this low-signal, high-noise snark-off. > > Perhaps the comp.lang.javascript FAQ needs an entry for this, > > then. > > It has been discussed, and a number of draft entries proposed. But there > remains some dispute as to what an appropriate response to the question > should be. From the point of view of someone wanting a better > understanding of javascript or browser scripting who just happens to be > using some 'popular' library then they really would get the best answers > to their questions here, if they could present their questions in > isolation (from all of the unrelated and irrelevant stuff that those > libraries contain). That last sentence is the answer to such a FAQ. Even a link to that question and answer would be more helpful than what has happened in this thread. > > A large portion of those who post on this newsgroup aren't > > participants or even lurkers; > > If they post questions then they are participants. I mean that they weren't participants before their first post. Many posters, I would venture, only come here when they need help, and therefore aren't already familiar with the quirks of the community. > > they come by only when they have problems. They can't > > be expected to catch up on the backstory. > > They can. Expecting someone to do a few web searches before they ask to > be spoon fed is not too unreasonable. Please search this newsgroup for the terms "Prototype" and/or "jQuery" and see how quickly you find a well-summarized critique of either library. > >> In this case we have a very obviously stupid use of user > >> agent string based browser detection to make a decision that > >> would be more logically made with feature detection. > > > Actually, no - no browser implements String#(un)escapeHTML, > > so feature detection would be pointless. We define that > > function earlier in the file, > > Yes, I noticed the other two assignments to the - String.prototype - > later and realised that I was wrong about that. > > > but redefine them for WebKit and IE because the String#replace > > approach is much, much faster in these two browsers (but much, > > much slower in FF and Opera). > > Can you post a test-case that demonstrates that assertion? Historically > IE has been renowned for its lousy performance with string > manipulation, while Mozilla outperformed everyone else in that area. I don't have a test-case. The change was made one year ago by Thomas Fuchs [1]. You're welcome to ask him, though I suspect he'll punch me in the sternum for having dragged him into this. > > But I noticed that the other two escaping/unescaping methods are nothing > like analogous to the two I posted. That is pretty bad in itself because > it means that the same source code is going to have different outcomes > depending on which browser it encounters, and the only way to avoid > falling foul of that would be to explicitly test any application using > the code on each and every browser and with a sufficiently divers set of > data to expose the situations where those inconsistencies might be > problematic. And that is something that is unlikely to actually happen > even in organisations that do do formal QA. After all, you missed the > fact that Safari/IE versions were defective yourselves so how could you > expect web developers who know no more than how to use a library find > the potential issues (or understand them if they did manifest > themselves). Nothing I say in our defense will satisfy you, because you seem to want a level of certitude that I can't guarantee. I could say that we have extensive unit tests, but clearly they were not extensive enough to catch the bug that you pointed out though that bug was noticed in the wild, submitted to our tracker, and patched, and more unit tests were added in the process. This is how open-source software works. I can't guarantee that any of us will write bug-free code on the first pass, any more than you can guarantee that you won't spell another word incorrectly for the rest of your life. instead, we have a testing process meant to ferret out as many self-introduced bugs as possible. When that fails, we rely on the community to file tickets. No doubt you have rolled your eyes by now, so I'll just move on. > > It would be safer to forget about performance in this respect and just > use one set of escaping and unescaping methods. After all, these methods > are not used by the library itself, and are unlikely to be that heavily > used in applications. > > > To be sure, there are other UA sniffs in Prototype that > > hard-liners would decry as unnecessary. > > It is not 'unnecessary' that is the questionable aspect of browser > sniffing, but rather that it is technically baseless and demonstrably > ineffective. You haven't demonstrated that anything is baseless or ineffective; you've only revealed a different set of priorities. You'd rather have 100% guaranteed behavior even if it meant a wildly-varying performance graph across browsers. I'd rather have the reverse. > But I suppose that you would not agree that being able to find an > obvious rookie mistake in less then three seconds of looking (at a > library that is already a good few years old) tends to support the > "junk" assessment. The check-in is only one year old. It is Thomas's bug, but he is no rookie, so I can only surmise that we all make silly mistakes sometimes. Bad luck for him that he managed to stumble upon your Shibboleth Bug(TM). > > A bug was filed on this not too long ago; I believe a > > fix has been checked into trunk and will be in the > > next release. > > Well, it is a pretty simple fix, and I notice that the subject of my > last substantial criticism of the prototype's code has also been > removed. We listen to criticism, we read bug reports, and we constantly search for ways to improve the feedback loop. So does John Resig, by the way, so I'd suggest you file a bug on jQuery's Trac about the "makeArray" mistake. Cheers, Andrew
From: Matt Kruse on 21 Apr 2008 16:54 On Apr 19, 3:06 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > Interestingly I observed Matt Kruse (who is the nearest thing to a > supporter JQuery has among the regular contributors to this group, and > someone who can easily outgun anyone directly involved in JQuery > development when it comes to javascript) Wow, given your view of the jQuery dev team, I'm not sure if that's even close to a compliment ;) > directly asked however was > responsible for the - if ( typeof array != "array" ) - code to own up to > it in a post on the JQuery development group. However, when I checked > back a week later to see if anyone had the intellectual integrity to own > up to their mistake I found that Matt's post had been deleted from the > group. If you're referring to this point: http://groups.google.com/group/jquery-dev/msg/54b54712bd48ec83 then I can still find it. Unfortunately, it hasn't generated any further discussion as I thought it certainly warranted. It's this kind of indifference about truly embarrassing code in the jQuery source that I find most troubling. They seem to be more interested in adding a new CSS3 selector or saving 20 bytes by condensing some code than in correcting bad programming practices. I think John Resig loves Javascript and is probably learning more about it as time goes on, but I suspect that his primary goal of evangelizing jQuery is to enable the writing of more books and attending more speaking engagements. Otherwise I can't comprehend why some of these issues haven't gotten instant attention as I believe they deserve. Matt Kruse
From: Matt Kruse on 21 Apr 2008 17:04
On Apr 21, 3:11 pm, Andrew Dupont <goo...(a)andrewdupont.net> wrote: > We listen to criticism, we read bug reports, and we constantly search > for ways to improve the feedback loop. So does John Resig, by the way, > so I'd suggest you file a bug on jQuery's Trac about the "makeArray" > mistake. I know nothing about Prototype's "feedback loop" but I'll say that my impression of the jQuery loop has been that it is very fond of praise and quick to dismiss or ignore genuine critiques about its core code or design decisions. I've made a number of attempts to make suggestions that I consider to be no-brainers... getting rid of unnecessary browser sniffs, optimizing loops which are extremely inefficient, making the isFunction() function work more more closely to how it was (misguidedly) intended, removing some code that is completely unnecessary (makeArray), and reporting some bugs. I've gotten a lackluster response to most posts, even though I would consider some of these issues to be extremely important in cleaning up the jQuery code, making it faster, and improving its overall quality. I'm quite fond of much of the API that jQuery offers, the coding style that it often enables, and the ease with which it enables new/amateur developers to create working code in the right environments. If I had the time and interest, I would probably be inclined to branch the code into something more solid, fix many of the issues that exist, and remove some of the overloading that makes the API kind of a mess. But since I lack both the time and interest, I'm still trying to push the jquery dev team into improving the code and hopefully bringing jQuery up to par as a library that can withstand the scrutiny of experienced js developers. Even if they would still not choose to use it. Matt Kruse |