Test for null or undefined?

[Matt Kruse]

Yet you disagree that it should be avoided. (!)

Yes. I've tried to explain why, but you refuse to open your mind.
That's okay, I understand.

Ignorant would be more kind, but doesn't always apply.

Well, I guess being a genius is a lonely job.

Have you noticed that every time I say something it pops up later in
one of your posts?

I know, I do it intentionally. I find it amusing.

How many Ninjas does it take to create an XHR object or set opacity?

a) 42
b) 420
c) Over 9,000!!!

Ninja Parade Slips By Town Unnoticed Once Again

So he sells worthless books, perpetuating his fanciful ideas about
browser scripting, lots of neophytes buy in to them, spreading junk
code from one corner of the Web to the next and you don't blame him a
bit.  Who do you blame?

Why must blame be placed? He's making the best of his situation, like
a Rock Star enjoying a #1 hit. Party on, John.

And therein lies the flaw in your thinking.

Ah, finally. I've been looking for it.

Next-best option for what and for whom?  After all of this, you are
still going to use jQuery?

Yes. Someday you'll be wise enough to understand.

Nothing matters does it?

Certainly not to me. But I do find it interesting.

Matt Kruse

 

[David Mark]

Yes. I've tried to explain why, but you refuse to open your mind.
That's okay, I understand.


Well, I guess being a genius is a lonely job.


I know, I do it intentionally. I find it amusing.

I find it annoying.

a) 42
b) 420
c) Over 9,000!!!

Ninja Parade Slips By Town Unnoticed Once Againhttp://www.youtube.com/watch?v=WtR2m20C2YM

One of Resig's stupid Javascript tricks videos would have been more
appropriate.

Why must blame be placed? He's making the best of his situation, like
a Rock Star enjoying a #1 hit.

This is software. It's not a matter of taste.

Party on, John.

Fat, drunk and stupid is no way to go through life, boy.

Ah, finally. I've been looking for it.


Yes. Someday you'll be wise enough to understand.

Some day you will admit your mistake and change. Or you will remain a
buffoon. There's really no middle ground.

[snip]

 

[David Mark]

It means:

1. It is broken.
2. The people charged with fixing it are incapable.
3. It complicates, rather than simplifies


To quote John Resig: "broke is broke."




LOL.  It's been booked, printed and sentenced to life (three strikes
and all.)


You are just inconceivably thick.  Do you normally need to "be
careful" when setting DOM properties?

http://jquery.open2space.com/node/13

http://mindforks.blogspot.com/2008/11/using-attr-for-aria-in-jquery-u...

http://www.nabble.com/attr("href")-giving-full-path-instead-of-re...

Oops, didn't realize that was actually a GG.

http://groups.google.com/group/jquery-en/browse_thread/thread/ea68e18af9f66296#

This post is from a week ago, so it overlaps our recent discussion
about this issue, which is basically a re-hash of an argument from the
fall of 2007.

It starts out:

"I'm wanting to read in the exact string that's contained in an
anchor's href attribute in order to use it as the POST variable list
for an Ajax call to a PHP script, however in IE6 and 7 the string read
from the href attribute ends up being the absolute path, not just the
href attribute. Here's exactly what's happening:

vars = $("a").attr("href");
alert(vars);

<a href="page=2">This should return "page=2"</a>

What I get when running locally in all browsers but IE is what is
expected, an alert box with page=2 in it. In IE, I get "http://
localhost/page=2". Is there some way to get it to behave either one
way or the other in all browser instances? I really don't want to have
to detect for IE, then extract what I want from the string if it is."

Sure, in this example:

vars = document.getElementsByTagName('a')[0].href

But this wasn't posted here. Instead he got this:

"http://www.glennjones.net/Post/809/getAttributehrefbug.htm describes
the issue and gives a solution."

Not exactly, but the solution proposed was better than this:

"$("a")[0].href will probably work consistently."

How elegant, we are to bypass the jQuery "convenience" method as it
doesn't do anything predictable (at least to the uninitiated.) The
docs didn't say anything about that.

After a bit of confusion, the OP added:

"The way I currently have it will not work with javascript turned off
either. I'm doing it this way only because the client is requiring the
user to have Javascript enabled to use the site (it's a backend system
for very specific clients). They want to add all sorts of animations
and effects like everyone wants to do once they see JQuery animations
in action."

jQuery expert @2 replied:

"IE has a second "flag" argument for getAttribute that, when set to 2,
is supposed to get the literal value of the attribute rather than
their special-sauce value.

So, this.getAttribute('href', 2) *should* get the relative href.
(note: no need to do $(this)[0] ; this works just fine)

jQuery uses that flag internally, so .attr('href') should do the same
thing:

var attr = !jQuery.support.hrefNormalized && notxml && special
// Some attributes require a special call on IE
? elem.getAttribute( name, 2 )
: elem.getAttribute( name );

I believe that this works in every case except when the href is set
via JavaScript. In that case, I'm not sure anything can be done."

Except when it doesn't work. Certainly he meant in every case that he
knows about, except when jQuery is used to set the attribute as it
uses the attr method, so there is no telling what to expect from the
DOM after that. GIGO.

And why is a code dissection needed here anyway? Couldn't they have
pointed the OP to the documentation? Perhaps they knew it was as
confused as they are.

OP:

"... I'm pretty sure I'm reading you right, but are you saying that by
all accounts JQuery should account for this and return the string-
literal value of href and not IE's absolute path? If so, it's not
working properly ... That means that if JQuery is supposed to sort
this out for me, it's not. If you meant that I'd absolutely have to
use Javascript's getAttribute(), then I'll try that and see if it
works."

Sure, try "Javascript's getAttribute" that and see if it works. This
is programming by collaborative misunderstanding.

OP:

"After replacing $(this).attr("href") with this.getAttribute("href",
2) I get the same result. If I output the attribute, IE still shows
the absolute path."

All of this flailing to get a consistent result with:

this.href;

Not there yet, but it does have a (more or less) happy ending.

jQuery support:

"Yes, I believe you're reading me right. Strange, though. I'm not able
to reproduce the problem you're having. Take a look here:"

Not strange at all. Neither has mentioned which version of jQuery
they are using and only one has indicated an IE version.

After some more suggestions about parsing URI's (!), the OP finally
figures it out for himself:

"Right, it's not hard, it was just unexpected is all. I guess I've
gotten used to JQuery working the same in "all browsers."

I've got it working now with some old-fashioned Javascript."

Get used to jQuery not working the same in all browsers.

So he has noted a landmine on *his* map. The others seem oblivious
and completely ignorant of the fact that the attr method makes getting
and setting properties *much* more complicated than it needs to be and
leads to code that changes behavior from one version to the next and
is virtually impossible to debug. Wasn't jQuery supposed to save you
from "good old-fashioned Javascript?"

Then this is this ominous coda:

"I experienced the same problem while developing a plugin that does
some tricks with the page content during the ready event. I noticed
that attr('href') works fine if I don't manipulate the body tag
content. IE won't return the correct href attribute if I do so.

The code I used to workaround the problem looks like this:

$('a').attr('xref', function() {
return $(this).attr('href');

});

....
document.body.innerHTML = someContent + document.body.innerHTML;
....

$('a').attr('href', function() {
return $(this).attr('xref');

}).removeAttr('xref');

Hope this helps."

Not by a long shot. Notice the "if I manipulate" (with jQuery)
comment. Again, GIGO. And advising people to add expandos to bridge
the gap in jQuery's attribute logic is obviously ludicrous. Now how
many people will run out and do just that?

Nobody has posted to the thread since, so I assume the issue is
considered closed. Doesn't really matter as they obviously can't
rewrite the attr method (for fear of breaking workarounds based on bad
assumptions.)

So is this really the "next best thing" to DOM properties? And is
this really a viable support group?

 

[Lasse Reichstein Nielsen]

That the arguments object is not created when not used is an unfounded
assumption, or rather wishful thinking on your part in order to support your
argument.

Mmm, no.
I know for certain that at least one ES3 implementation optimizes away
the arguments object creation, and simple tests suggests that others
do the same (speed of calling a function decreases if it contains an
identifier named "arguments", even if it isn't used).

The ECMAScript Specification, Edition 3 Final, widely implemented
as opposed to the ES 4+(!) dreaming, says otherwise.

The specification is not an implementation specification, but a
behavioral specification. If the arguments object isn't referenced,
then the behavior doesn't change if it's not created.

So much for being helpful.

Try it! Add the following to a page and try it in different browsers:

<script type="text/javascript">
function testArgs() {
function f1(a) {
if (true) { return; } else { return arguments.a; }
}
function f2(a) {
if (true) { return; } else { return a.a; }
}

var t0 = new Date();
for (var i = 0; i < 100000; i++) {
f1();
}
var t1 = new Date();
for (var i = 0; i < 100000; i++) {
f2();
}
var t2 = new Date();
return (t1 - t0) / (t2 - t1);
}
window.onload = function(){ alert(testArgs()); };
</script>

My results (approx):
Opera 9.6 : 8
Firefox 3.0.8 : 1
Chrome 2.0.171.0 : 5.5
Safari 4 beta : 8
IE 7 : 1

So three out of five browsers do indeed get slower calling a function that
mentions the arguments object, even if it isn't accessed at all.

So much for being right

/L

 

[Thomas 'PointedEars' Lahn]

Yes. I've tried to explain why, but you refuse to open your mind.
That's okay, I understand.

Maybe it is not so much a matter of his mind closed but of the
all-to-obvious contradiction in your argumentation that I for one don't buy
either.

Why do you insist on using something that you *know* is borken? Why do you
not use (and recommend) something else that you *know* (or should know) to
be working instead? Should such ignorant behavior not carry the mark of
utter incompetence?


PointedEars

 

[Matt Kruse]

Why do you insist on using something that you *know* is borken?

I use Windows, which is extremely broken. I use IE6 in some cases even
though it's as broken as it gets. I use countless web sites that have
major flaws. I've often relied on batch files and hacked scripts that
got jobs done in a very ugly way and were very fragile (even broken at
times) but it was still better than NOT using them. I use lots of
things that I know are broken, because very few things are perfect.

The question isn't just "is it broken?" but rather "do the benefits
outweigh the potential risks?" And in the case of situations where I
use jQuery, they do. Some people who are crippled by analysis and
strict logic can't quite wrap their heads around that, because their
brains require everything to be perfectly logical and optimized in
order to go forward.

 Why do you
not use (and recommend) something else that you *know* (or should know) to
be working instead?

I do not know of a better alternative. If one were available, I would
probably use and recommend it and drop jQuery. I have no particular
attachment to jQuery, personally.

 Should such ignorant behavior not carry the mark of
utter incompetence?

Not at all. It's being realistic. If everyone waited around for
perfectly robust and analytically correct solutions before moving
forward, people wouldn't get anywhere. Just think of how many people
have _died_ while using experimental, imperfect, flawed machines in
the name of science and progress. People know things are broken, but
they use them anyway because it's a way to take a step forward.
Luckily, using broken code won't result in death.

Hell, every time I fly I think of all the things that are potentially
broken. Wires could be bad, maybe there's more ice on the wing than
they realize, maybe a bird will hit the engine, may a cross-wind will
blow the plane off the runway. Who knows? I know the risks, and I know
that driving may actually be "safer". But the benefits outweigh the
risks, so I get on the plane.

It's perfectly reasonable to use a tool because it offers many
benefits, and trust that its flaws will be fixed as you go along and
you'll be better off in the long run. We all do it. You just may
disagree on the benefits vs. risks, and in fact it may NOT be the
right choice for you. But that's not necessarily true for everyone,
because you can't possibly know the situation that everyone finds
themselves in.

Matt Kruse

 

[Matt Kruse]

http://groups.google.com/group/jquery-en/browse_thread/thread/ea68e18...

I just got a chance read this post and the above thread, and it looks
like the OP was confused, but the general issue is relevant.

All of this flailing to get a consistent result with:
this.href;

I'm kind of confused about what you mean, because simply accessing
".href" doesn't return the desired value. That's what the code in attr
() tries to fix.

I'm sure this is obvious to you, but in my version of IE6 with jQuery
1.3.2:

<a href="test.html" id="x">test</a>

document.getElementById('x').href == file:///C:/attr.html
document.getElementById('x').getAttribute('href') == file:///C:/attr.html
document.getElementById('x').getAttribute('href',2) == attr.html
$('#x').attr('href') == attr.html

So, using a simple property getter like this.href is insufficient if
you want to retrieve the actual attribute value of "test.html". The
jQuery attr() method does in fact normalize this so .attr('href')
returns what is expected. Is this not what you would expect?

So is this really the "next best thing" to DOM properties?

Seems like an improvement over simply accessing the property, even if
implemented poorly.

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

I use Windows, which is extremely broken.

That doesn't answer my question at all. For it is not that there are no
qualitatively better, cheaper, freer alternatives.

I use IE6 in some cases even though it's as broken as it gets.

There are alternatives to that, too. FYI, I use IE 6 only for testing, in a
Windows emulation on GNU/Linux at home (on my notebook), and in Standalone
IE, IETester, and Virtual PC at work.

I use countless web sites that have major flaws.

Again, why?

I've often relied on batch files and hacked scripts that got jobs done in
a very ugly way and were very fragile (even broken at times) but it was
still better than NOT using them.

Because it was for a single user (you) or a limited group of users. I can
accept that; I do the same, although at least I do *strive* for perfection
there.

I use lots of things that I know are broken, because very few things are
perfect.

Nobody's perfect. That's no reason or excuse at all to use borken things
*knowingly* and *in spite* of the better alternatives. Especially not if
you are in a position to build better things; however, if you don't think
you are in that position, you are also in no position to make
recommendations in favor of the broken things.

The question isn't just "is it broken?" but rather "do the benefits
outweigh the potential risks?"

I'm afraid you are in no position to assess the potential problems, let
alone the risks, when it comes to jQuery. Your reasoning is much too biased
for that.

I do not know of a better alternative. If one were available, I would
probably use and recommend it and drop jQuery.

But the alternatives have been named here and elsewhere a hundred times or
more, and you have refused to consider them to date.

I have no particular attachment to jQuery, personally.

I wouldn't be so sure about that. The way you unwaveringly *defend* this
junk, which maybe beautifully-looking junk (to me it reads outside as the
junk that it is inside, but there's no accounting for taste), but *junk*
nonetheless, speaks of a very deep personal attachment to it.

Not at all. It's being realistic. If everyone waited around for perfectly
robust and analytically correct solutions before moving forward, people
wouldn't get anywhere.

That argument would be sound if there was no alternative to using jQuery.
But there is.

It's perfectly reasonable to use a tool because it offers many benefits,
and trust that its flaws will be fixed as you go along and you'll be
better off in the long run. We all do it.

I don't do it in spite of knowing about and having a better tool.
Definitely not.


PointedEars

 

[Matt Kruse]

But the alternatives have been named here and elsewhere a hundred times or
more, and you have refused to consider them to date.

I know there are alternatives. But so far none of them have been
"better".

If you're judging purely by code quality or robustness, then sure.
There are better alternatives. But that is ignoring other factors such
as:
a) Documentation
b) Support
c) Examples
d) Simplicity of bringing new developers into the code without
learning a new API
e) Testing
f) Continuous improvement
g) Development time/speed
h) Cost
i) "Approved For Use" by IT/Mgmt

When I factor in all those things, other alternatives become less
appealing. You can argue all you want that it shouldn't be this way,
but it IS, and currently using jQuery is the best decision in some
situations. In other situations, when I consider all the factors, it
is not the best decision. It depends.

I wouldn't be so sure about that.

Oh, I'm sure. I've been very critical of it, even in personal email
conversations with Mr. Resig. I'm pretty sure he doesn't much care for
me, but that's okay.

 The way you unwaveringly *defend* this
junk, which maybe beautifully-looking junk (to me it reads outside as the
junk that it is inside, but there's no accounting for taste), but *junk*
nonetheless, speaks of a very deep personal attachment to it.

If you cannot look beyond the "junkiness" of the code to see the other
possible benefits it might provide, then that's where we differ.

That argument would be sound if there was no alternative to using jQuery.
But there is.

I would genuinely be interested in hearing what you feel the
alternatives are and why they are the "better" choice in different
situations.

Matt Kruse

 

[David Mark]

I just got a chance read this post and the above thread, and it looks
like the OP was confused, but the general issue is relevant.

The OP was (and likely still is confused.) The people who attempted
to help were (and certainly still are) confused. Of course the issue
is relevant (that's why I pointed it out!)

I'm kind of confused about what you mean, because simply accessing
".href" doesn't return the desired value. That's what the code in attr
() tries to fix.

And what is the desired value? From the OP's first post:

"Is there some way to get it to behave either one
way or the other in all browser instances?"

I'm sure this is obvious to you, but in my version of IE6 with jQuery
1.3.2:

<a href="test.html" id="x">test</a>

document.getElementById('x').href == file:///C:/attr.html
document.getElementById('x').getAttribute('href') == file:///C:/attr.html
document.getElementById('x').getAttribute('href',2) == attr.html
$('#x').attr('href') == attr.html

So, using a simple property getter like this.href is insufficient if
you want to retrieve the actual attribute value of "test.html".

Not insufficient. That obviously won't work at all.

The
jQuery attr() method does in fact normalize this so .attr('href')
returns what is expected. Is this not what you would expect?


Seems like an improvement over simply accessing the property, even if
implemented poorly.

LOL. I suggest you re-read it (the thread and the code.) I'm saving
this one in case you ever open your mouth in here about jQuery
again.

 

[David Mark]

Matt Kruse wrote:

[...]

So, using a simple property getter like this.href is insufficient if
you want to retrieve the actual attribute value of "test.html". The
jQuery attr() method does in fact normalize this so .attr('href')
returns what is expected. Is this not what you would expect?

It's all nonsense. It doesn't "normalize" anything. You'd need a
four-dimensional chart to plot the results across browsers, jQuery
versions, element types, etc. Misconceptions like this are why Resig
wants SETI-like unit testing. But it is hard to test something when
you don't understand what it is supposed to do.

Don't forget that there are cases when IE still returns absolute path
even when given "2" flag to `getAttribute` - notably, when an anchor
element is inserted into a document via `innerHTML`:

Of course. That "2" flag is the last thing anyone should count on.
Not a shock that jQuery counts on it for everything.

BTW, the jQuery "rules" regarding href|src do not apply to data or
longdesc (longDesc?) (!)

document.body.innerHTML = '<a href="http://example.com/example">x</a>';
document.getElementsByTagName('a')[0].getAttribute('href', 2);

Yet another IE's `innerHTML` idiocy.

Compounded by yet another jQuery idiocy. It's like they seek out the
mines and purposely jump on them.

 

[Thomas 'PointedEars' Lahn]

I know there are alternatives. But so far none of them have been
"better".

If you're judging purely by code quality or robustness, then sure.
There are better alternatives. But that is ignoring other factors such
as:
a) Documentation
b) Support
c) Examples
d) Simplicity of bringing new developers into the code without
learning a new API
e) Testing
f) Continuous improvement
g) Development time/speed
h) Cost
i) "Approved For Use" by IT/Mgmt

OMG, are you living in luserland after all? *You* are the developer, the
expert (in your team, I hope), who apparently needs all that stuff jQuery
offers; are you not capable of providing something better than jQuery that
does the same, after all this time and all these discussions?

When I factor in all those things, other alternatives become less
appealing. You can argue all you want that it shouldn't be this way,
but it IS,

Only because *you* make it so. If you state your case and tell the suits
that what they want is an incredibly bad idea, if you explain why, and if
you offer alternatives to them, maybe some more expensive now but also more
profitable in the mid-term or long-term, they will listen. BTDT.

and currently using jQuery is the best decision in some situations.

Shortsightedness leaving you with the one option of shooting yourself in
the foot, that must be considered the best (and only) option that remains.
Cause and effect. Eliminate the cause, and you will be left with more, and
better options.

In other situations, when I consider all the factors, it
is not the best decision. It depends.
Hmmm.


If you cannot look beyond the "junkiness" of the code to see the other
possible benefits it might provide, then that's where we differ.

I look at jQuery reviews and I am appalled at the utter incompetence that
must be at work there at the jQuery team (if there is such a thing). I look
at jQuery code myself, and the reaction is not much different. I look at
jQuery extensions, and I wonder how anybody can *maintain* that illegible
stuff. I look at code that uses jQuery extensions (ohh, the *display* looks
fine on *this* machine!) and wonder what the heck they were smoking,
replacing what could have been a one-liner that works everywhere with N
lines of gobbledygook that by definition works only in a small subset of
UAs. And then I dare call it junk, inside and outside.

I would genuinely be interested in hearing what you feel the
alternatives are and why they are the "better" choice in different
situations.

The alternatives are, among others, to have methods passed an object
reference instead of using a universal wrapper method, to do feature-testing
instead of browser-sniffing or object inference, to write branching code
only when necessary, to modify CSS declarations or to add CSS instead of
finding elements by selector and modifying their style each, and to use
smart event-bubbling instead of mindless listener-adding to each and every
possible element.


HTH

PointedEars

 

[David Mark]

I know there are alternatives. But so far none of them have been
"better".

So lets look at your "fadeOut" question.

Alternative A is to dig up "setOpacity" from the archive. I assume
you know how to use window.setInterval. If not, it is well documented
and well supported.

Alternative Z is to download 50K of gobbledygook called jQuery, dump
it on your sites and pray.

Now, for example, when you find out that you can do a fade out (as
well as other animations) in WebKit with virtually no script at all?
I guess *you* wait for an upgrade, swap out the whole script and re-
test *everything*.

Strange that you would do such a thing. At the rate jQuery is going,
I think you'll be waiting quite a while for that particular
improvement (they will need to fix attr first!)

If you're judging purely by code quality or robustness, then sure.

I'm judging jQuery by the inconceivable level of misunderstanding in
its *latest* incarnation. It is nowhere near competent (or consistent
across browsers or its own releases), let alone robust. Using it can
do nothing but confuse you further and that is clear from your
comments (or lack thereof) regarding the attr method. It's been a
year and a half since I pointed out that very critical and
unquestionably broken code. And Resig doesn't seem to understand
either.

There are better alternatives. But that is ignoring other factors such
as:
 a) Documentation

Read the documentation for the attr method.

 b) Support

Read the support attempt for the attr method (from last week!)

 c) Examples

Read the examples that use the attr method (virtually all of them.)

 d) Simplicity of bringing new developers into the code without
learning a new API

To this day, *you* do not understand the API. Still waiting for your
explanation of what the attr method is supposed to do. Not what it
does, but what you think it is supposed to do. Can you explain that
in terms that *anyone* will understand? Getting and setting DOM
properties was pretty simple to begin with.

 e) Testing

It would take some pretty poor unit tests to allow that attr method to
exist in its current shape (more or less) for *three years*. You
can't write a unit test for something you don't understand.

 f) Continuous improvement

Continuous do-overs. I've got scripts from the year 2000 that are
still in production, have never been touched and, yes, they have fade
effects.

 g) Development time/speed

You can't develop anything with an API you don't understand. There's
no way you can be confident in anything you have ever built with
jQuery (unless you are irretrievably stupid.) And upgrading, re-
testing every time Resig spots another groaner is a supreme waste of
time and money.

 h) Cost

See previous.

 i) "Approved For Use" by IT/Mgmt

Not if I've ever been in your shop. Think they have any idea on their
own?

When I factor in all those things, other alternatives become less
appealing. You can argue all you want that it shouldn't be this way,
but it IS, and currently using jQuery is the best decision in some
situations. In other situations, when I consider all the factors, it
is not the best decision. It depends.

Shut up.

Oh, I'm sure. I've been very critical of it, even in personal email
conversations with Mr. Resig. I'm pretty sure he doesn't much care for
me, but that's okay.

Shut up.

If you cannot look beyond the "junkiness" of the code to see the other
possible benefits it might provide, then that's where we differ.


I would genuinely be interested in hearing what you feel the
alternatives are and why they are the "better" choice in different
situations.

And shut up. I've heard enough of your jQuery-induced histrionics for
one lifetime.

 

[Matt Kruse]

OMG, are you living in luserland after all?  *You* are the developer, the
expert (in your team, I hope), who apparently needs all that stuff jQuery
offers; are you not capable of providing something better than jQuery that
does the same, after all this time and all these discussions?

Typical. You can only think in terms of your environment and your
situation, and you assume that everyone else's is the same. I'm a
reasonably intelligent guy. I know how to balance conflicting needs to
arrive at the best possible solution, even if it's not ideal. If there
was an easier, more obvious solution, don't you think I would go for
it? Or do you really think I'm so in love with jQuery that I'll stick
to it no matter what? On the contrary, I've chosen NOT to use it in
some projects because it wasn't the best choice, and I've actually
REMOVED it from projects (replaced with POJS) because it was a
performance problem. It all depends.

Only because *you* make it so.  If you state your case and tell the suits
that what they want is an incredibly bad idea, if you explain why, and if
you offer alternatives to them, maybe some more expensive now but also more
profitable in the mid-term or long-term, they will listen.  BTDT.

Oh, of course. I'll just tell it to the suits! Easy! Genius! (Do you
think we all work in a Dilbert office? heh)

The alternatives are, among others, to have methods passed an object
reference instead of using a universal wrapper method, to do feature-testing
instead of browser-sniffing or object inference, to write branching code
only when necessary, to modify CSS declarations or to add CSS instead of
finding elements by selector and modifying their style each, and to use
smart event-bubbling instead of mindless listener-adding to each and every
possible element.

Okay, those are alternative programming tactics. And obvious. But none
of them are _jQuery_ alternatives. Nobody chooses jQuery because of
its internal technical genius (I hope). They choose it because it
offers a convenient API and a layer of abstraction over things they
don't want to spend hours figuring out and creating - and does so in a
finished, documented, tested, and supported package. That matters. An
"alternative" to jQuery must address those needs. That is what is
lacking from so many arguments that recommend "ditching" jQuery but
suggest no good alternatives that offer the things that made people
choose jQuery to begin with.

Now, do you have a packaged library ready to distribute to a team of
20, half of them in India, which incorporates these concepts? Is it
documented with examples, so they can get help if needed? Is it
tested? How much time do I have to allocate to teach each person how
to use the library? When the project gets handed off to another team,
how much cost will be involved with them learning the API and
debugging? Oh, and what's the licensing on this code? Has it been
approved for use in internal apps by IT, or do I have to begin the
approval process?

No? See, then you don't have an alternative.

Matt Kruse

 

[Matt Kruse]

And shut up.  I've heard enough of your jQuery-induced histrionics for
one lifetime.

Indeed, and I have grown tired of your childish comedy routine.

"Look at this, it fails for some users during the day! You don't know
why? You're stupid."
"What would happen if I did X with the attr() method? You don't know?
And you use this junk? You're stupid."
"Can you describe what this code is intended to do? No? You're
stupid."
"Look at these idiots in this thread. I know what they're doing wrong,
but they don't deserve the answer. They're stupid."

I've tried to have an intelligent exchange with you, but it is
obviously a waste of time. This is why jQuery is successful. Because
people like you - who may actually have technical knowledge and
recommendations that would be helpful - are often complete assholes
and it's just easier to ignore you.

Matt Kruse

ps - Good luck with your book.

 

[Thomas Allen]

Indeed, and I have grown tired of your childish comedy routine.

"Look at this, it fails for some users during the day! You don't know
why? You're stupid."
"What would happen if I did X with the attr() method? You don't know?
And you use this junk? You're stupid."
"Can you describe what this code is intended to do? No? You're
stupid."
"Look at these idiots in this thread. I know what they're doing wrong,
but they don't deserve the answer. They're stupid."

You forgot the parts where he called you a "buffoon."

Thomas

 

[David Mark]

Indeed, and I have grown tired of your childish comedy routine.

"Look at this, it fails for some users during the day! You don't know
why? You're stupid."

Never said that at all. This is what I said:

"LOL. If you can't figure *that* out, then perhaps you need to take a
step back and reevaluate your position."

I'll go a step further and state for the record that you *are* stupid
if you can't figure that out. You only had to analyze one line of
code for one browser.

"What would happen if I did X with the attr() method? You don't know?
And you use this junk? You're stupid."

First you said you don't use it, but that was naive as jQuery uses it
internally. Then I asked you to explain why this method is simpler or
more concise or easier to understand than getting and setting DOM
properties. That explanation is still pending.

These work the same in all known browsers and likely always will:

el.src;
el.href;
el.data;
el.longDesc
el.onclick;

Go ahead and "cheat" if you want (analyze the code, which shouldn't be
necessary for a simple API and is impossible to expect from a
neophyte) and give me the jQuery equivalent. This is hardly
esoterica.

Bonus:

Which of these is correct in jQuery (again, go ahead and "cheat.")

$(el).attr('onclick', 'alert("test");');
$(el).attr('onclick', function() { alert("test"); });

I know you are big on gathering empirical data. I suggest you get out
the graph paper, multiple colored markers, etc. and dig in for a long
night. Never mind the code, look at the *results*. Or just admit that
you were a complete prat for recommending something you don't know how
to use and certainly don't understand.

Or you could just look at the code. As you stated, it ain't rocket
science (it's not *any* sort of science.) Of course, that begs the
question as to why it hasn't been fixed in three years, despite my
handing you the solution on a silver platter.

For an essay, explain why most HTML applications do not need the get/
setAttribute methods at all. Very strange that jQuery relies on them
in some situations and not others and that those situations appear to
be based on random observations and misconceptions.

"Can you describe what this code is intended to do? No? You're
stupid."

Never said that either. But if you mean the attr method, I would say
it takes a very foolish individual to rely on something they can't
explain. I don't mean explain the code, explain the *rules*. See the
jQuery documentation for a completely vague and confused account of
what somebody thinks it does.

"Look at these idiots in this thread. I know what they're doing wrong,
but they don't deserve the answer. They're stupid."

Don't be an idiot. I reported this issue to John Resig himself in the
fall of 2007. The fact that people are still stumbling over it today
is not my fault. I am not even a member of that group. Why didn't
you chime in?

I've tried to have an intelligent exchange with you, but it is
obviously a waste of time. This is why jQuery is successful.

For some reason I'm reminded of Ted Stryker from "Airplane." He's
up! No, he's down! He's all over the place. What an asshole!

Because
people like you - who may actually have technical knowledge and
recommendations that would be helpful - are often complete assholes
and it's just easier to ignore you.

Then stick your head back in the sand. You are the one who asked me
for help. Now you don't want it. See above.

 

[David Mark]

You forgot the parts where he called you a "buffoon."

Nobody likes a snitch, townie.

 

[Thomas Allen]

Nobody likes a snitch, townie.

Nobody likes an insult, socially inept dipshit.

Thomas

 

[David Mark]

Nobody likes an insult, socially inept dipshit.

Yeah, you should have thought of that before you blew in here and
insulted me (perhaps you forgot about that.) I see from another
thread that you now want my advice on "Javascript libraries." Don't
hold your breath.