Prev: FAQ Topic - How do I generate a random integer from 1 to n? (2010-04-03)
Next: active (x)html newsgroup?
From: David Mark on 7 Apr 2010 12:22 Matt Kruse wrote: > On Apr 6, 10:36 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> So you are really going to eschew a CSS-only solution for an >> Ajax/jQuery/Live monstrosity, all in the name of IE6? > > Yes, when IE6 is the only supported browser and the functionality is > required. You still wouldn't need jQuery. It sure doesn't seem like the JS blob of choice for an IE6-only environment either (considering its many documented shortcomings in that browser). And God help you when you have to upgrade IE. You do realize that mine made the leap from IE7 to 8 without a hitch (or my lifting a finger). I was so confident (and busy at the time) that I didn't even test it in IE8 until six months after it came out. All 10,000 lines plus add-ons survived. I did have one silly mistake in a test JSON file (not related to the library, which very rightly choked on the malformed JSON). The others spent the whole Beta period in feverish rewrites. Who could have predicted such an outcome? :) > > Your point about the overhead of evaluating a selector in the live() > method is valid. Yes. I am quite sure my OO example would fare better for that and other reasons. > If it creates a performance problem, I would > certainly switch it over to a "normal" event listener and evaluate the > target element with POJS to see if it matches. But as long as it works > well as-is, I see no reason to prematurely optimize. > So "POJS" is a better option than the My Library API? You seem to have jumped from one extreme position to the other.
From: S.T. on 7 Apr 2010 14:05 On 4/6/2010 2:47 PM, David Mark wrote: > I'm sure discerning script authors can see how, despite a little more > typing (never a real concern) .... says the man who replies seven times to the same post.
From: Matt Kruse on 7 Apr 2010 14:01 On Apr 7, 11:22 am, David Mark <dmark.cins...(a)gmail.com> wrote: > So "POJS" is a better option than the My Library API? You seem to have > jumped from one extreme position to the other. This isn't complicated stuff. I don't need to introduce a whole new library into an application that includes jQuery and will continue to include jQuery whether I need it or not. POJS is a better choice. In fact, you correctly point out that the whole concept is ridiculously simple. Adding a mouseover/mouseout event to the body and evaluating the event's target to see if it matches a simple tag/class selector is trivial stuff. Surely I would have it abstracted on my own if I didn't have the jQuery crutch to lean on. And if I had enough time and need to get rid of jQuery, I would probably write that abstraction. What I really want is jQuery Lite. If I ever have the need to do animations, that is a time that I probably will check out ML. jQuery does not do that stuff well, and yours looked promising. ps - You'll be pleased to know that tomorrow I have a "jQuery remediation" meeting where I am going to give instructions to a project about how they are abusing jQuery, writing inefficient code, and unnecessarily doing things in $(document).ready() that cause the whole page to become sluggish. I like jQuery as a tool in my kit, because I use it wisely and know its shortcomings. When in the hands of less experienced developers, it scares me. Matt Kruse
From: Matt Kruse on 7 Apr 2010 14:09 On Apr 7, 1:05 pm, "S.T." <a...(a)anon.com> wrote: > On 4/6/2010 2:47 PM, David Mark wrote: > > > I'm sure discerning script authors can see how, despite a little more > > typing (never a real concern) > > ... says the man who replies seven times to the same post. lol... I got lost in all his replies and just picked one to respond to. Plus, more code written = more opportunity for bugs. That's a given. Apparently, My Library is so easy to develop with, that its author only needs 7 tries to get the code correct and concise! Now THAT is efficient! (j/k of course... kind of) Matt Kruse
From: RobG on 7 Apr 2010 21:51
On Apr 8, 4:09 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: [...] > Plus, more code written = more opportunity for bugs. That's a > given. No, it's not. Do you have statistics showing a correlation between lines of code and number of bugs for pieces of code that provide equivalent functionality or implement equivalent logic? Does less code mean easier debugging? If so, then we should all be writing the most concise, compact code we can as it will lead to fewer bugs and easier maintenance. Can you tell me what this does[1]: function STonoff() { var J, K, Y = (new Date).getFullYear(); document.write("Five years; seven civil days always crossing", " EU Summer Time changes\nYear Spring Autumn"); for (K = -2; K <= 2; K++) { J = Y + K; var D1 = new Date(J, 3, -6); var D2 = new Date(J, 3, 1); var X1 = (D2 - D1) / 86400000; var D3 = new Date(J, 10, -6); var D4 = new Date(J, 10, 1); var X2 = (D4 - D3) / 86400000; document.write("\n", J, " ", StrU(X1, 1, 6), " ", StrU(X2, 1, 6)); } } and if it has bugs, how do you feel about being asked to fix them? Would longer, more verbose code have more bugs, or would it just be easier to read, understand and maintain? It is often the case that unusually lengthy code is a sign that the author doesn't know how to use the language efficiently, but it does not necessarily follow that the code so produced is any more buggy than someone who (perhaps due to over-confidence[2]) writes the most concise code they possibly can. How many times have you seen in the jQuery forum someone posting code that is perfectly functional but they just want it written in fewer lines? I've never seen anyone say "I'd like this written in fewer lines because then it will be less buggy". As far as I can tell, they usually they want it shorter simply because they think it can be. Where long term maintenance is an issue, if the original code was well written, less code usually means it is more difficult to debug and maintain, which is why anyone writing non-trivial code will very quickly adopt guidelines for writing clear, readable code. 1. Apparently it "calculates the difference in 24-hour days between civil dates a week apart, necessarily spanning each EU clock transition". <URL: http://www.merlyn.demon.co.uk/js-date3.htm#DL > 2. I am certainly not accusing you (or anyone else here) of that, but it tends to be the more arrogant and over-confident developers who insist on writing the most concise code they can, to the point of obfuscation. They are a PIA. -- Rob |