New jQuery announced!
in [JavaScript]
|
From: "Michael Haufe ("TNO")" on 11 Dec 2009 11:27 On Dec 11, 10:13 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: > > Telling a team that is writing bad code to "just use jQuery" can > instantly improve performance, reduce bugs, and improve cross-browser > support. Is it perfect? No. But it's better than the status quo. And > it's regularly updated, documented, supported, etc. It takes very > little effort to make a big improvement in code quality. That's why > jQuery is valuable. Ever try a code review instead?
From: Matt Kruse on 11 Dec 2009 11:39 On Dec 11, 10:27 am, "Michael Haufe (\"TNO\")" <t...(a)thenewobjective.com> wrote: > Ever try a code review instead? Me: "This code is bad. Fix it." Developers: "???" That was useful. Matt Kruse
From: David Mark on 11 Dec 2009 11:47 On Dec 11, 11:13 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 11, 9:31 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > In my experience, I have found that > > > without such a library the code quality is consistently lower and the > > > number of problems is way higher. > > Sounds like you need new programmers. What could be lower than > > jQuery's code? > > You must live in a bubble. No, I deal with JS and JS developers every day. > > I regularly see code that is much, MUCH worse. Less predictable. Less > robust. Less stable. Take just he basic attr and removeAttr methods. They can't even run the basic gamut of attributes without throwing exceptions. Other cases fail silently. These quirky behaviors vary across browsers _and_ jQuery versions. So, what could be worse than that? Random gibberish? Don't use that either? > > Telling a team that is writing bad code to "just use jQuery" can > instantly improve performance, reduce bugs, and improve cross-browser > support. No, it might create the illusion that they are all suddenly competent. > Is it perfect? No. But it's better than the status quo. It a team is writing bad code, you teach them how to write good code. That's primarily what I do for a living. ;) > And > it's regularly updated, documented, supported, etc. The regular updates are indicative of 60K of JS that has been in endless Alpha for years. That's certainly detrimental to anyone foolish enough to plop a snapshot of their efforts on a Website. Documented? As I mentioned, you can't document what you don't understand. And we've been over their "support" too. Same principle applies. Three strikes. > It takes very > little effort to make a big improvement in code quality. It's like a magic trick! :) > That's why > jQuery is valuable. No, that's why it is poison. > > Now, if you never have to deal with such a situation, then you're in > luck. No wonder you can't see the value in jQuery. You are jumping to conclusions to say the least. > > Think of it this way - When js code quality is at a 1 or 2 on a scale > of 1-10 (10 being best), Easy. Get new programmers. > then introducing jQuery and raising it to a 4 > or 5 with virtually no pain is an obvious win. Not in my book. Looks like a punt. > Versus trying to raise > it to an 8 or 9 with considerable coding, time, cost, coaching, > documentation, testing, etc. All bullshit. What considerable coding? What project are we talking about? These generalizations are just not reality. > In a perfect world we could all set our > sights high to ideal coding practices, but in the real world many > people deal with, lowered expectations helps maintain sanity. No, they help incompetents keep a toe-hold on their precarious positions. It's not good for business in any way, shape or form. I _know_ a lot of code monkeys will tell you (and anyone who will listen) different. > Especially when js code quality is less of a concern compared to > other, bigger problems. I don't know what that means. The typical Website uses ten times the script needed. So code quality concerns are magnified ten times. There is nothing with more power to wreck a site than script (especially of poor to middling quality), so the obvious best strategy is to use as little of it as possible. Therefore, your proposed strategy of starting out with 60K of thoughtless "4 level" code is counter-productive. If it fools code monkeys into thinking they are Ninjas, that will lead to further ruin down the road as things break, libraries are "upgraded" to "fix" them, apps are re-tested (or not) from scratch, etc. I've seen it a thousand times (and we've discussed this almost as many). And exceptions and other land mines are not covered by variations in "code quality". Code can be of poor quality and still work. Code that doesn't work isn't really code at all. It's called trash and there's only one place for it.
From: Matt Kruse on 11 Dec 2009 12:08 On Dec 11, 10:47 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > You must live in a bubble. > No, I deal with JS and JS developers every day. There's no point in going over this again. You cannot relate to those who face development situations and business cases different than yours. There are some really bad projects out there, being completed by really poor developers, at a quality level that is very low. If you never see or touch those, good for you. But they still exist. > Take just he basic attr and removeAttr methods. They can't even run > the basic gamut of attributes without throwing exceptions. Other > cases fail silently. These quirky behaviors vary across browsers > _and_ jQuery versions. So, what could be worse than that? Oh, things can be much worse. > > Is it perfect? No. But it's better than the status quo. > It a team is writing bad code, you teach them how to write good code. If only it were that easy. > > Think of it this way - When js code quality is at a 1 or 2 on a scale > > of 1-10 (10 being best), > Easy. Get new programmers. Of course! Everyone should just fire the people they have and hire the best! > > then introducing jQuery and raising it to a 4 > > or 5 with virtually no pain is an obvious win. > Not in my book. Looks like a punt. It's progress. It's better than it was. Idealism is not always realistic. Sometimes "just make it work" is a lofty goal. > > Especially when js code quality is less of a concern compared to > > other, bigger problems. > I don't know what that means. When the js is running in a pseudo-xhtml document containing invalid markup, elements with multiple duplicated id's, 80k of whitespace bloat, styles and js embedded directly into the tags, css that is not cross-browser, table-based layouts, and spacer gif's... well, jQuery messing up an attr() call condition that will never actually be called seems like a minor concern. But seriously... this is the same old discussion of "don't you understand how bad it can get and why something like jQuery is actually an improvement?!" and there's really no point to it. I'm fine with just seeing it differently than you. Matt Kruse
From: Garrett Smith on 11 Dec 2009 13:42
Matt Kruse wrote: > On Dec 11, 10:27 am, "Michael Haufe (\"TNO\")" > <t...(a)thenewobjective.com> wrote: >> Ever try a code review instead? > > Me: "This code is bad. Fix it." > Looks like a straw code review. Two documents are in order: 1) Code authoring guidelines 2) Code review guidelines The FAQ covers (1) in a general sense. Number 2 would be very helpful for a FAQ note/addendum, to be linked from #postCode. The organization that is making the sorts of messes you described in another post could benefit from making such document. Would you like to work on #2? E.g. | A code review should focus on problems. Saying "the code is bad" is | not a helpful review. | | Rebuttals | The reveiwee may challenge a criticism and... For example, where the markup is invalid, the reviewee will often say: "literal ampersand doesn't cause problems". Or "but the browser detection works." This is where the guidelines doc comes in handy, so you don't have to go over again the importance of eliminating all validator errors, or what sorts of harm is caused by browser detection, using the HTML doctype, etc. The validator results either with green PASS or with one or more errors at which point it is clear that the reviewee's code is not completed to standard. The benefit is that the w3c validation tools can be used to quickly find errors that cause problems. Nobody should have to pore over a long list of validation errors for '&', et al, to find the validation error(s) that could be related to whatever it is that the invalid code created. In that scenario when an HTML error is found to cause a problem, the next task finding when the "error" creeped in, why it is there, what other code is relying on the problematic area, who wrote that other code, where is he now, so a possible fix can be discussed, etc. At this point it is obvious how much of a waste of time using invalid HTML is. Working with invalid code like can be very time consuming. Running the w3c validator is a little extra effort that saves a lot of time. Problems with the code should be clearly explained so that they can be understood. The solutions to the types of code obscenities you described in your other post are usually self-evident. Where they aren't, then further discussion can help find solutions. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |