JSLint Reports on last 2 Production Versions of jQuery
in [JavaScript]
|
Prev: FAQ Entry Proposal: What is (function(){ /*...*/ })() ?
Next: FAQ Topic - What is Ajax? (2010-03-01)
From: David Mark on 2 Mar 2010 18:30 lorlarz wrote: > On Mar 2, 2:23 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> David Mark wrote: >>> Garrett Smith wrote: > [snip] >>>> My favorite one is Dojo `it instanceof Array || typeof it == "array"`. >>> Buffoons. I tried to tell them that was ridiculous, but they just >>> carped about providing "proof" (and something about ad hominem attacks). >> "Ridiculous" is a matter of opinion. Fact: It is useless code which is >> downloaded along with the rest of Dojo. Useless code should be removed. >> So far nobody has questioned that principle. >> >> It shows that they did not know what they were doing. >> >> If they've been made aware of the useless code (and apparently you did >> that), then they should probably want to fix it immediately. I know I would. >> >> Do they expect their clients to not recognize it for what it is? Why >> would anyone who knows better use that, knowing that the general >> userbase is using it out of ignorance? >> >> [...] >> -- >> Garrett >> comp.lang.javascript FAQ:http://jibbering.com/faq/ > > I really do not think it is appropriate to discuss the > Dojo library in a jQuery thread. Things are plenty confusing > enough without mixing critiques of different libraries in the > same thread. Coincidentally, the Dojo contributors used to complain about thread compartmentalization as well. But I insisted that was the last thing they should have been worried about. I don't think you should worry about it either.
From: Matt Kruse on 3 Mar 2010 12:15 On Mar 2, 5:18 pm, Peter Michaux <petermich...(a)gmail.com> wrote: > In the past, I seem to remember you weighting the benefits of using > jQuery heavier almost to the point of advocating it was a good idea to > use jQuery. Am I remembering incorrectly or have your opinions of > jQuery deteriorated over time? My opinion of jQuery has deteriorated, yes. I don't care so much about the attr() problems that DM repeatedly points out, but other things worried me more. For example, the response to the selectedIndex discussion really highlighted the skewed perspective the core developers have when trying to solve problems "correctly". Also, I'm seeing more and more people write things "the jQuery way" and ending up with extremely inefficient code. I've spent too much time going back and un-jquery-ifying code to speed it up. Finally, the recent discussion about jquery's xhr implementation kind of blew me away: http://groups.google.com/group/jquery-dev/browse_frm/thread/5e63ab0adf17aabc I hadn't really questioned why jQuery polled the ajax response rather than triggering based on state changes, but I assumed they had some reason. At least it still worked. It turns out that they just didn't know how to fix a memory leak in IE. And when it was pointed out, he initially made a change that showed he really didn't understand scope chains and how leaks are created. And in the second issue in the thread, his quick fixes to the logic were incorrect and needed to be pointed out. I'm not sure he really grasped what was needed or how to construct the logical tests. Yet he was very hasty in making fixes and committing them into the source. Sure seems like development on a whim. No wonder they release so many versions, and always have quick minor updates after big releases to patch the holes. Finally finally, they keep changing the API, removing methods, adding methods, etc. Seemingly at random, depending on their latest design ideas. It's a big moving target that wanders around as they get flashes of inspiration about things that were done well and documented years ago. > What are you using when jQuery is not a good fit? I am using more and more of my own code, which is a bummer. It's more robust and faster, but it takes longer to create and it doesn't get as much testing as a public, open-source library that is heavily used across the web would get. Javascript is a very minor part of what I do, so I can't focus on doing it the way I really would like. But having said all that, I want to say again that I still use jQuery and recommend it. These criticisms are really coming from very experienced js developers who understand all the fine points of the language and implementation. jQuery is a good product for the common Joe Coder, but it will _never_ meet the standards of those who are the true wizards of the language. I don't expect it to. jQuery is good for simple stuff, grabbing elements by selectors, doing things like hiding and showing and animating, etc. That's what I mostly use it for, and that's what I recommend it for. I never recommend writing complex interfaces "in jQuery". I may fall back to its selector engine, and I may add my own methods that are optimized to do what I want, but I don't use the UI components or almost any of the 3rd-party plugins. I don't do things "the jQuery way". I don't focus on writing dense code but instead code that is logical and easy to read and understand. jQuery is javascript for the masses. And it's great for that, IMO. Once you progress beyond that and learn more, you will naturally see its flaws. Then you'll move to something else. Which is great! jQuery is the first step for most people. Without it, they may not move up at all. It serves its purpose, even if imperfect. Matt Kruse
From: David Mark on 3 Mar 2010 19:57 Matt Kruse wrote: > On Mar 2, 5:18 pm, Peter Michaux <petermich...(a)gmail.com> wrote: >> In the past, I seem to remember you weighting the benefits of using >> jQuery heavier almost to the point of advocating it was a good idea to >> use jQuery. Am I remembering incorrectly or have your opinions of >> jQuery deteriorated over time? > > My opinion of jQuery has deteriorated, yes. I don't care so much about > the attr() problems that DM repeatedly points out, but other things > worried me more. Then you really don't understand how these selector engines work. In a word, poorly. > > For example, the response to the selectedIndex discussion really > highlighted the skewed perspective the core developers have when > trying to solve problems "correctly". Sheesh. Who sent you on _that_ errand of mercy? You were ready to suggest some similar BS hack. > > Also, I'm seeing more and more people write things "the jQuery way" > and ending up with extremely inefficient code. And how many times have I warned you about _that_. Are you really suggesting that I only ever mentioned attr and you came up with these new theories on your own? LOL. > I've spent too much > time going back and un-jquery-ifying code to speed it up. Yes, there is a whole industry springing up around fixing bad library-laden scripts. :) > > Finally, the recent discussion about jquery's xhr implementation kind > of blew me away: > http://groups.google.com/group/jquery-dev/browse_frm/thread/5e63ab0adf17aabc I don't even want to know. Enough is enough (and has been for years). IIRC, it does some sort of ridiculous polling. :) > > I hadn't really questioned why jQuery polled the ajax response rather > than triggering based on state changes, but I assumed they had some > reason. :) > At least it still worked. It turns out that they just didn't > know how to fix a memory leak in IE. And when it was pointed out, he > initially made a change that showed he really didn't understand scope > chains and how leaks are created. And in the second issue in the > thread, his quick fixes to the logic were incorrect and needed to be > pointed out. I'm not sure he really grasped what was needed or how to > construct the logical tests. Yet he was very hasty in making fixes and > committing them into the source. Sure seems like development on a > whim. No wonder they release so many versions, and always have quick > minor updates after big releases to patch the holes. Glad you could finally see the light. But why did it take this last debacle to put you over the edge? > > Finally finally, they keep changing the API, removing methods, adding > methods, etc. Seemingly at random, depending on their latest design > ideas. Ah, back to my greatest hits. :) > It's a big moving target that wanders around as they get > flashes of inspiration about things that were done well and documented > years ago. They did something well? Name it. > >> What are you using when jQuery is not a good fit? > > I am using more and more of my own code, which is a bummer. Well, you wrote it. > It's more > robust and faster, but it takes longer to create and it doesn't get as > much testing as a public, open-source library that is heavily used > across the web would get. But as you've seen, the testing hasn't led to anything good as the authors can't really interpret the tests. We've been over this too. > Javascript is a very minor part of what I > do, so I can't focus on doing it the way I really would like. You would really like to use CSS selector queries? Too bad as they are not practical at all. > > But having said all that, I want to say again that I still use jQuery > and recommend it. As usual, you are loopy. > > These criticisms are really coming from very experienced js developers > who understand all the fine points of the language and implementation. And you. :) > jQuery is a good product for the common Joe Coder, but it will _never_ > meet the standards of those who are the true wizards of the language. > I don't expect it to. No, it is a horrible idea for Joe Coder, who needs things to be simplified, not overly complicated (not to mention unpredictable). How can you write this after what you wrote above? > > jQuery is good for simple stuff, grabbing elements by selectors, It is horrible for that and that's all it really does. > doing > things like hiding and showing and animating, etc. The animations have always been sub-standard (and ugly as hell on older or lesser PC's, phones, etc.) > That's what I > mostly use it for, and that's what I recommend it for. You really are insane. > I never > recommend writing complex interfaces "in jQuery". I may fall back to > its selector engine, and I may add my own methods that are optimized > to do what I want, but I don't use the UI components or almost any of > the 3rd-party plugins. Of course not. The add-ons are famously awful. And those were/are a big "selling point", at least among shills. > I don't do things "the jQuery way". Horribly inefficent? Buggy as hell? Slow? What is their one way? > I don't > focus on writing dense code but instead code that is logical and easy > to read and understand. And you don't need jQuery for that. > > jQuery is javascript for the masses. NO. It isn't. It's a lousy script that makes browser scripting much more difficult than it needs to be. Why would the masses clamor for that? > And it's great for that, IMO. Nuts. > Once you progress beyond that and learn more, you will naturally see > its flaws. Then you'll move to something else. Which is great! So you are now using My Library? > jQuery > is the first step for most people. Without it, they may not move up at > all. It serves its purpose, even if imperfect. > The first trip you mean (and it is invariably a bad one). And its only purpose seems to be to discourage people from learning JS and browser scripting.
From: Andrea Giammarchi on 4 Mar 2010 04:10 JSLint does not accept more prepared/expert developers and I don't get all this fuss around JSLint. I have already commented "JSLint The Bad Part" and everybody seems to agree about the fact JSLint is for Junior, is an extra hint during development, but surely it's not the bible. The == null is a JSLint *error*, specs clearly says that there is NO COERCION against null. null == undefined AND null == null are the only TRUE value, everything else compared with null and == will be FALSE. The only thing that JSLint should do to avoid blames against developers that MEANT something, is a bloody flag: /*jslint ignore:true*/ ... the code you meant like that ... /*jslint ignore:false*/ or /*jslint meant:true*/ ... the code you meant like that ... /*jslint meant:false*/ This will make JSLint useful to get all "gotchas" and document or ignore all those piece of code that should be exactly like that. This will make good JS code as jQuery is valid and will make all those developers unable to understand WHY IT'S NOT AN ERROR happy (plus automation against validation) I tried to sign into the JSLint group but AFAIK I am not in yet to propose this change. Regards
From: David Mark on 4 Mar 2010 04:33
Andrea Giammarchi wrote: > JSLint does not accept more prepared/expert developers and I don't get > all this fuss around JSLint. What does that first part mean? > > I have already commented "JSLint The Bad Part" and everybody seems to > agree about the fact JSLint is for Junior, is an extra hint during > development, but surely it's not the bible. It's good for spotting mistakes (like typos), as well as ambiguous and or potentially problematic structures. It's not meant to be a bible. You should be able to interpret the results, else it will just confuse you. > > The == null is a JSLint *error*, specs clearly says that there is NO > COERCION against null. > > null == undefined AND null == null are the only TRUE value, everything > else compared with null and == will be FALSE. You would seem to have (loudly) contradicted yourself. Two (2) warnings, unable to continue. :) |