From: David Mark on
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
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
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
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
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