New jQuery announced!

[Matt Kruse]

Yeah, I told you the new wrappers were slightly improved.  Custom (non-
standard) attribute support is one such improvement.  

To quote yourself:

|You missed that this is obviously broken logic. If one line is
|broken, how do you trust the next (and the thousands that follow that
|one)?

You don't have a clue what the "right" answers are from jQuery as attr
has no defined behavior.

I looked at your documentation for getAttribute() and found even less
documentation then attr(). So I guess returning null in these cases is
just fine, as your method has no defined behavior either.

Pot, Kettle, etc.

Matt Kruse

 

[Matt Kruse]

$('#x').attr('cellspacing') => 5

As this was the only real bug you found [...]

It took me all of 5 minutes to download your code, look at the code,
and easily identify two problems in the logic. By your own strict
standards of testing, you've had two years to spot these easily-
identified problems, yet they have remained unfixed in the publicly
downloadable version.

I'm sure I could find other problems in your code (seeing as how
easily these were found) if I had the desire to look at it, but I
don't.

Matt Kruse

 

[David Mark]

To quote yourself:

|You missed that this is obviously broken logic.  If one line is
|broken, how do you trust the next (and the thousands that follow that
|one)?

No, you have a child-like view of all of this. Missing those two
attributes when I slapped together that list of aliases two years ago
was a silly omission, which I documented here a long time ago (just
never bothered to fix it). Completely botching attributes and
properties in a mess like jQuery's attr method is altogether
different.

I looked at your documentation for getAttribute() and found even less
documentation then attr().

And how many times have I told you that the documentation is
incomplete? But it does not betray a complete lack of understanding
like jQuery's. Last I checked, they defined attr as retrieving
attributes from elements. And, as we know, that's not what it does at
all.

So I guess returning null in these cases is
just fine, as your method has no defined behavior either.

It does have defined behavior. It's a get/setAttribute wrapper that
actually works across all IE versions. The only one of its kind
AFAIK.

Pot, Kettle, etc.

Not even close.

 

[David Mark]

$('#x').attr('cellspacing') => 5

As this was the only real bug you found [...]

It took me all of 5 minutes to download your code, look at the code,
and easily identify two problems in the logic.

You did not identify any problems in the _logic_. That's the
difference.

By your own strict
standards of testing, you've had two years to spot these easily-
identified problems, yet they have remained unfixed in the publicly
downloadable version.

Yes, I've stated repeatedly that I abandoned the project for more
lucrative ventures. So what? It's still light years ahead of
jQuery with _nobody_ working on it.

I'm sure I could find other problems in your code (seeing as how
easily these were found) if I had the desire to look at it, but I
don't.

That's a cop-out. If you really wanted a better jQuery, you would
have participated in this project two years ago (maybe even spotting
those two missing attribute names). But you chose to stick with
jQuery through endless rewrites and now you can't upgrade the stupid
thing because they've mangled backward compatibility.

And I looked up the documentation for getAttribute:-

"The getAttribute function retrieves the value of the specified
attribute of the specified element.
Syntax

v = getAttribute(el, name);

Return Value

The function returns a string or null if the specified attribute does
not exist."

Yep. That's what it does. Now what does attr do again? Can
Resig define it at all?

 

[Matt Kruse]

Custom attributes are not supported by that function

I must have missed that in the documentation. I guess when calling
API.getAttribute() you just don't know what to expect.

I'll bet you don't get that sort of support from the jQuery "team".
Special orders don't upset me.  

Definitely not! Amazing!

I guess there are definite advantages to having your code be used by
only a handful of users. You can make a release quickly and
efficiently without worrying about a release process, backwards
compatibility, compatibility with 3rd party code, test cases,
examples, documentation, and a huge developer/user community. That
must be a big relief. Way to go on that one.

Matt Kruse

 

[Matt Kruse]

No, you have a child-like view of all of this.  Missing those two
attributes when I slapped together that list of aliases two years ago
was a silly omission, which I documented here a long time ago (just
never bothered to fix it).
[...]
And how many times have I told you that the documentation is
incomplete?
[...]

Pot, Kettle, etc.

Not even close.

Right.

I think the point has been sufficiently made for the archives, so I'm
done.

Matt Kruse

 

[David Mark]

I must have missed that in the documentation. I guess when calling
API.getAttribute() you just don't know what to expect.

Did it say that you can make up any attribute name? Granted, I agree
that it should disallow them in the docs, but then I've stated a
thousand times that the docs were never finished. Last I heard,
somebody was working on updating them and whenever that happens, I'll
post the results.

Definitely not! Amazing!

I guess there are definite advantages to having your code be used by
only a handful of users.

You haven't got a clue (as usual).

You can make a release quickly and
efficiently without worrying about a release process,

What do you know about my release process? I'll tell you that one
thing I always do is to run the script through JSLint. As there are
only a half dozen things it flags, it is easy to spot typos. Now, as
jQuery has so many failings that the lint quits prematurely, it is not
possible to spot typos like this at all.

backwards
compatibility, compatibility with 3rd party code,

All ridiculous. Adding those two alias isn't going to break anything.

test cases,

As you well know, I wrote the proverbial book on attribute-related
test cases:-

http://www.cinsoft.net/attributes.html

examples, documentation,

The documentation for that method is correct (and it has an example).

and a huge developer/user community.

That
must be a big relief. Way to go on that one.

You come off like a petulant child. Just face it, you were wrong all
along. Do I have to go back two years and dig up all of the similar
discussions between you, me and Resig? Didn't I tell you he would
have to rewrite everything _and_ break compatibility badly to "keep
up" with the new browsers (specifically IE8). And didn't I tell you
that feature testing (as used in mine) was the key to avoiding such
problems.

Look at yourself, stuck with a two-year-old version of jQuery, because
they _broke_ compatibility (and fixed almost _nothing_ in doing so).
Way to go, indeed.

 

[David Mark]

[...]

All ridiculous.  Adding those two alias isn't going to break anything.

An addendum, it's OT, but why the hell aren't those two cell*
attributes deprecated? Thinking back, I'm sure I thought they were
(or should have been). They seem strictly decorative to me (and
covered by CSS rules). I know I haven't used them since last century.

 

[Garrett Smith]

[].]]]

That's a silly omission by one person from two years ago.

Sometimes less is more. For example, my dom attributes/property wrapper
source code:-

|

- 0 SLOC and no bugs whatsoever.

:-D

 

[David Mark]

[].]]]

That's a silly omission by one person from two years ago.  

Sometimes less is more. For example, my dom attributes/property wrapper
source code:-

|

- 0 SLOC and no bugs whatsoever.

I'm sure your time machine has never broken down either.

 

[John G Harris]

- 0 SLOC and no bugs whatsoever.

How can you be sure your test code had no bugs in it ?

John

 

[David Mark]

How can you be sure your test code had no bugs in it ?

ISTM you would need imaginary test code for a non-existent wrapper.

 

[Garrett Smith]

How can you be sure your test code had no bugs in it ?

Good point. Code maintenance involves maintenance of tests. The more
code, and especially the more /complicated/ code is going to have more
variables that require testing. SRP, or "do one thing only" is
applicable to methods and also to tests.

I look back on the unit tests I wrote 18 months ago and they are way too
complex. I try and keep the unit tests to one assertion. If there are
two assertions, I break it up and make another test. The result is the
testing becomes clearer. Instead of "test this particular usage
pattern", the test is more pure to what unit testing actually is -
testing the smallest, testable parts of the code.

On the matter of testing, I'd really like something better than YUI
test. There are several problems I've grown too frustrated with. There
are many improvements that coudl be made, if the author would dedicate
the time to it.

 

[David Mark]

Good point. Code maintenance involves maintenance of tests. The more
code, and especially the more /complicated/ code is going to have more
variables that require testing. SRP, or "do one thing only" is
applicable to methods and also to tests.

Yes, and the point that I've made repeatedly regarding get/
setAttribute is that _most_ apps don't need them at all in an HTML
DOM. A very recent example where one could have helped:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557#

For whatever reason, the OP wants to set the value attribute of an
input. Of course, I wouldn't recommend a GP wrapper for this one
case. I don't recommend GP solutions at all. But seeing as GP
solutions are all the rage and you can't expect neophytes to figure
these things out, an interface like this would have helped:-

attr(el, 'value', 'myvalue');

(If it actually works, of course).

I dislike the get/set being in one function (it's not like that in My
Library), but these new wrappers were originally designed to replace
Dojo's similar methods. Better would be (from My Library):-

API.setAttribute(el, 'value', 'myvalue');

-or-

E('myid').setAttribute('value', 'whatever');

So, depending on the audience, such wrappers can be useful. Certainly
they are a requirement for a CSS selector query engines, parsers,
serializers, etc. All of the "major" libraries have some sort of half-
hearted attempts.

As for the other methods, outside of a test page, you virtually never
need removeAttribute. But hasAttribute is occasionally needed (and
spottily supported). An example is form serialization.

http://www.cinsoft.net/attributes.html

 

[Garrett Smith]

I didn't look at the source closely enough. I thought they got rid of
accessing properties of elements and went purely to get/setAttribute.
I was incorrect. Disappointing.


Indeed, which has been David's criticism for a long time. It looks
like Resig still doesn't get it.

Didn't John Resig just make a post on jquery-dev about how he refuses to
read comp.lang.javascript?

It is hard to understand anything when the thing that is to be
understood is intentionally ignored.

$(':checkbox[name=foo]').run("this.checked==true");
run() is obviously a little eval wrapper that I plugged into jQuery.

That sounds dangerous.

Not if you know what you are doing. I use it for very simple things,
to avoid lots of anonymous functions.

Such as?

Documented well

The w3c standards are at least as well documented.

Lots of examples

There are some examples in HTML 4 spec.

Printed material available for developers to read from
Books?

An active support community

ciwas, ciwah, c.l.js.

Active development and bug fixing

Modern browsers have fixed many standards-related bugs in the past 10 years.

Supported by various editors and environments
etc

What do you want the library code to do?

If you're just a stand-alone developer choosing the best tool, jQuery
may not be the best pick. If you're trying to organize a team of 10-20
developers, some onshore some offshore, all of differing experience
levels, who all need to touch the js of the webapp, then having a tool
like jQuery is very important. 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. jQuery sure has its problems, and
it's not a perfect solution, but it's way better than the other
alternatives I've found. When I find a better option, I'll switch.

That is where code reviews and pair programming come into play.

Code reviews do many things. They force the person who is doing the
review to look closely and understand th code. That right there is a
huge benefit because now two people understand the code. Code reviews
find bugs before they ship. This avoids QA churn. Code reviews can cause
the person writing the code scrutinize check their work more carefully
knowing someone is going to be scrunitize the work.

I once did blocking code reviews for the offshore team. Their HTML and
CSS ath te start of the project was awful. Towars the end, they were
much better than the in house guys. It was a huge success. Unfortunately
the inhouse people were fucking lazy. The laziness was demonstrated by
their hiring brows people overseas for sub-standard wage to do their
work while they took "OOO" or "WFH" days which were actually vacation
(Disneyland, etc).

The benefits of code reviews are also benefits for Pair. Now sometimes
pair is a waste of time, but it can be extremely productive. Pair may
include a little goofing, but usually not much.

A lot of people get nervious about code review but like pair. I guess it
depends who you are working with or who is revieing your code. The
decision to choose one over the other comes down to preference and
logistics (kind of hard to remotely pair).

Even if jQuery is used, there should be code reviews or pair. And for
code reviews with jQuery, it woul make sense to advise against using the
inefficient ready function, the inefficient selectors, the attr or
removeAttr functions, the inefficient animation. Possibly a bette way to
use jQueyr woul be:-

var el = document.getElementById("redBox");
wrappedEl = jQuery(el)[0];

This, at least, would avoid the initial inefficiency of finding the element.

The next step would be writing code that actually does something useful
to fulfill requirements.

That would be great, but I have no desire to write it. I know what
problems I have with jQuery, and I code around them. If I were being
paid for it, I would certainly write such an article

What is the reason for having jQuery in the first place?

The patterns jQuery encourages are:

1) wait for document ready,
2) select some nodes,
3) do something with nodes (add event callbacks, etc).

The design I have always favored is:
1) add an event callback to document
2) in the callback, if the target is something were' innterested in,
act accordingly (delegate to the relevant factory, etc).

This second type of design is much simpler and much more efficient.
There is not any query selector, no looping through each and every node.
No waiting for "ready". The only thing that happens while the page is
loading is a event handlers (click, etc) get attached.

Consider what jQuery actually does with ready, and then with:-

var el = jQuery("redBox")[0];

- compared to what happens with:-

var el = document.getElementById("redBox");

- or:-

if(hasClass(target, "ape-calendar")) {
Calendar.getById(target.id);
}

jQuery's ID Command checks each element to see if the ID matches the id
specified. The overhead of matching every element is proportional to the
size of the document. The larger the document, the slower jQuery will be
at matching. This is a much less efficient than document.getElementById.

Looping through the dom during page load can temporarily lock up the UI.
Google search had that problem for a few days but they seem to have
removed that feature.

The jQuery css selector ID matcher could use getElementById, but then it
would not match mutliple IDs. I don't see the point in matching multiple
IDs, but then again, I don't see much point in jquery at all. Perhaps
someone can explain it to me.

A piece of code should exist to solve a problem. In the case of jQuery
selector, the problem solved is finding an element.

The jQuery approach is much more complicated and much slower. It also
requires a significantly large dependency.

 

[Garrett Smith]

Yes, and the point that I've made repeatedly regarding get/
setAttribute is that _most_ apps don't need them at all in an HTML
DOM. A very recent example where one could have helped:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557#

For whatever reason, the OP wants to set the value attribute of an
input. Of course, I wouldn't recommend a GP wrapper for this one

No, the solution provided in the thread, using defaultValue, is shorter,
faster. there is no abstraction code download, debug, maintain, and test.

 

[Garrett Smith]

[...]
ng is a event handlers (click, etc) get attached.

Consider what jQuery actually does with ready, and then with:-

var el = jQuery("redBox")[0]

correction:
var el = jQuery("#redBox")[0];

 

[David Mark]

[...]
ng is a event handlers (click, etc) get attached.

Consider what jQuery actually does with ready, and then with:-

   var el = jQuery("redBox")[0]

correction:
     var el = jQuery("#redBox")[0];

One other correction:-

jQuery("#redBox")[0] == document.getElementById('redBox');

They don't have a single element abstraction, so the wrappedEl
mentioned previously was just a plain node reference.

I agree with the points made. It's even worse when you consider that
jQuery uses QSA for some browsers and its own attribute-botching BS
for others. Similar XPath-based forks exist in other "major"
libraries as well. There are lots of cases (some demonstrated
recently) where the two forks will diverge, even in HTML DOM's (XML/
XHTML are certainly out of the question if consistency is desired).

In a nutshell, the "silver bullet" solutions just make basic concepts
harder to grasp (see the recent jQuery Summit on Attributes), less
consistent across browsers and prone to obscure errors (especially
when new browser versions are released). Handing these scripts (and
accompanying books) to neophytes is not likely to turn out well. And
expecting the authors of these things to gain understanding one "show
me" at a time is dreaming.

 

[Garrett Smith]

Matt Kruse wrote:
Matt Kruse wrote:
| obviously the attr() method is meant to only set string attributes.

[...]
ng is a event handlers (click, etc) get attached.

Consider what jQuery actually does with ready, and then with:-
var el = jQuery("redBox")[0]

correction:
var el = jQuery("#redBox")[0];

One other correction:-

jQuery("#redBox")[0] == document.getElementById('redBox');

They don't have a single element abstraction, so the wrappedEl
mentioned previously was just a plain node reference.

Yep. wrappedEl was a very misleading variable name. The second example
using - var el - got it right.

 

[Garrett Smith]

[snip]

It would appear that this was intended as a bug workaround, and that
reading the selectedIndex property is all that's required. Still, it's a
strange thing to do, and could very well be optimized away by a minifier
tool or by the JS engine itself.

A workaround, but to what problem?

<body onload ="alert(document.getElementById('c').selected)">
<select id="x">
<option id="a">a</option>
<option id="b">b</option>
<option id="c" style="visibility: hidden;" selected>c</option>
<option id="d">d</option>
</select>

In Safari, the 'c' is selected, the alert is - true - and when the
select is expanded, the 'c' option is blacked out.

Perhaps someone can demonstrate what the workaround actually fixes.

One more time: Can anyone demonstrate the problem that the workaround
exists for?