Recommendations for JavaScript drop-down menu code

[Richard Cornford]

If you're saying this cross-browser JavaScript knowledge
is distributed among the minds of various individuals,

Didn't I write "captured and consolidated _in_ the minds of the
individuals", not distributed among ... ?

then I'd say it's neither captured nor consolidated.

If your 'if' were true then you would be correct.

I feel you're being purposely obtuse here.

Maybe, you are not being very forthcoming with answers to the questions
you are being asked here so you should not expect too much else from
others.

Ok, now I feel like we're just going in circles. Let me
just be crystal clear by asking one simple question:

Which publicly available JavaScript libraries do you
feel are worthwhile to use?

Use for what exactly? Javascript design decisions should be context
driven.

For example, if you context were needing an application framework for
the types of activates that are of interest to a large-ish search engine
provider then YUI could easily be pretty much spot-on for the task. On
the other hand, if you goal was to provide supplementary room heating
for a "target audience" living in a cold climate then making extensive
use of anything built on top of Prototype.js should pump the maximum
amount of extra heat into the user's domestic environment.

Work out what it is you are trying to achieve before you set about
working out how best to achieve it.

Richard.

 

[Brian Adkins]

Didn't I write "captured and consolidated _in_ the minds of the
individuals", not distributed among ... ?


If your 'if' were true then you would be correct.


Maybe, you are not being very forthcoming with answers to the questions
you are being asked here so you should not expect too much else from
others.

I haven't been forthcoming? Do you seriously think that having cross
browser knowledge "captured and consolidated in the *minds* of
individuals" is useful to anyone other than those individuals? I think
many people would correctly infer my intent was to determine if the
knowledge had been consolidated into a form that would be of use to
others - a web site, book, library, etc. Are you suggesting people
interview these individuals?

I don't know why you feel I haven't been forthcoming. After getting
the impression that many people on this newsgroup felt that no
existing JavaScript library was worthwhile to use, I thought I'd start
with a base case and see if there was any library (in active use was
implied) that was worthwhile to use in any context. Getting an answer
to that question has been like pulling teeth!

Maybe you got the impression I was playing games here, but I honestly
wanted to see if any of the regulars here felt any library was
worthwhile.

Yes, you and David keep reiterating that "no one says you have to
write it all yourself", and yet you also won't mention any worthwhile
libraries to use. So, let me ask you, if one doesn't need to "write it
all themselves" - where do you suggest people obtain the code that
they haven't written?

There are certainly people who have stated they felt the only
reasonable course of action was to write all JavaScript code
themselves, so maybe by "nobody" you meant you and a few others.

Use for what exactly? Javascript design decisions should be context
driven.

Naturally. But since my impression was that this group felt all
existing JavaScript libraries were not good enough to use (that
statement has been made multiple times), I simply wanted to know if
you felt any libraries were good enough in any context. And by
library, I think a reasonable person would discount a few lines of
code whipped up for the purpose of this discussion - I was referring
to something on a public web site currently in existence.

For example, if you context were needing an application framework for
the types of activates that are of interest to a large-ish search engine
provider then YUI could easily be pretty much spot-on for the task.

Wow, finally! So, for some contexts, you feel YUI is a worthwhile
library to use. Are there any others? I take it that you feel both
Prototype and JQuery are not worthwhile. Is YUI the only one that is
in your opinion?

On
the other hand, if you goal was to provide supplementary room heating
for a "target audience" living in a cold climate then making extensive
use of anything built on top of Prototype.js should pump the maximum
amount of extra heat into the user's domestic environment.

Work out what it is you are trying to achieve before you set about
working out how best to achieve it.

What I was trying to achieve was to determine a set of JavaScript
libraries that might be worth investing time in researching. The
purpose was clear, but my choice of information source was seriously
misguided.

 

[David Mark]

[snip]

Nothing _requires_ jQuery, obviously.
I have found it useful for:
1) Animation effects

Of course. jQuery's is completely inappopriate for anthing that
requires DOM positioning, CSS manipulation, etc. Everything it does
in those areas relies on the userAgent string.

2) Simplified AJAX interaction

Don't you have your own "AJAX toolkit?"

3) Easily adding :hover effects which IE will understand

If you need a library for hover effects, then perhaps you should skip
the hover effects.

4) Adding some UI improvements to existing pages
5) etc, etc

Those are too non-specific.

I have also found some of the plugins to be extremely useful in
speeding up development of complex UI's.

If the plug-ins are of similar quality, then you are dumping more bad
code on top of an already shaky foundation.

I covered this in another thread. Real cost ($$$) savings.

Your "argument" in the other thread was an oversimplification.

Like?

Like attaching event handlers to every anchor element in a document.
jQuery's design encourages such things and DOM-challenged developers
take full "advantage." Never mind that it creates an inefficient mess
behind the scenes.

In many cases, I know all my users personally.

How many of them would notice subtle problems like memory leaks. How
many are psychic? One of my main points is that you are buying future
trouble.

What if an organization does not have dedicated Javascript
programmers?

If an organization does not employ JavaScript developers, then it
shouldn't be developing Web applications. Certainly it shouldn't
bother with hover effects and animations. When these frill features
go awry, there will be nobody there to deal with the issues.

On the contrary, I think the design is quite intuitive and exactly
what I am often looking for.

I am talking about the code design. As for the API, all you have
found is a false sense of security.

I disagree. Not using some of a 26kb library is unimportant to me.

Again with the 26K figure. It is almost 50K minified. It doesn't
make sense to compare file weights after compression as compression is
not always available. All things equal, it is five times as large as
a 10K library or two 5K style sheets, etc. Adding compression to the
comparison is just a way for library developers to confuse and mislead
those who don't know any better.

No, but it sure makes it easier. To do it from scratch would be
complex.

Hardly. Here is jQuery's hover function:

hover: function(f,g) {

// A private function for handling mouse 'hovering'
function handleHover(e) {
// Check if mouse(over|out) are still within the same parent element
var p = e.relatedTarget;

// Traverse up the tree
while ( p && p != this ) try { p = p.parentNode; } catch(e) { p =
this; };

// If we actually just moused on to a sub-element, ignore it
if ( p == this ) return false;

// Execute the right function
return (e.type == "mouseover" ? f : g).apply(this, [e]);
}

First, it relies on jQuery's inefficient event normalization to
provide the related target. Then it walks all the way to the document
node in most cases. The try/catch is a bit of a mystery too. As is
the use of apply, when call would do.

Complicated? No. Inefficient and inappropriate for most hover
effects? Yes.

I'm quite familiar with browser sniffing arguments.

Your "arguments" indicate that you don't understand the implications
of browser sniffing.

If you want to support every browser on the planet, then perhaps you
shouldn't use jQuery. They make their browser support claims quite
clear.

There is a big difference between supporting "every browser on the
planet" and supporting just the newer versions of IE, Safari, Opera
and Firefox. Clearly jQuery is inappropriate for use on the public
Internet. And what you fail to realize is that jQuery can easily
break as the versions are updated (a constant happening for the latter
three.) The reliance on browser sniffing marries you to whatever
versions were tested during development, so your Intranet is far from
future-proof.

I'm not concerned with any browsers not on their supported list, so it
doesn't bother me.

And what will you tell your IT department when they want to
standardize on a newer browser? It might bother them if the rollout
is held up because the new version breaks jQuery.

Sacrificing a (very) small (perhaps non-existent) set of potential
customers in order to reduce development time, decrease bugs, increase
usability, and reduce overall cost is a good business decision.

You just repeat the same nonsense over and over. You apparently
haven't heard a word I have said.

Thank you. Delusion has apparently been working quite successfully for
me for many years!

Success is relative.

You are wrong, sir. I'll avoid telling you repeatedly.

That would be nice. I am getting tired of reading and responding to
the same worthless opinions and non-arguments over and over again.

 

[Matt Kruse]

Of course. jQuery's is completely inappopriate for anthing that
requires DOM positioning, CSS manipulation, etc. Everything it does
in those areas relies on the userAgent string.

I agree with your criticisms, but I again must point out that it has
never been a problem for me. I suspect that the quality of the code
and logic in the library will improve before I find a case where it
would be a problem.

Like attaching event handlers to every anchor element in a document.

One thing I don't like about jQuery is the push to add all kinds of
handlers and stuff on the page load. I've found problems with that
approach, especially for internal webapps where "unobtrusive"
javascript is not a concern. But I do like the ability to use CSS
selectors to apply handlers to specific things after the page loads.
I've used this often to improve existing pages where altering the HTML
source is not simple or in some cases possible.

If an organization does not employ JavaScript developers, then it
shouldn't be developing Web applications.

That's quite an over-statement. Most web-development organizations I
know of don't have dedicated js programmers.

Again with the 26K figure. It is almost 50K minified.

Packed it is 26k. If you're concerned about file size.

Hardly.

Not the hover function itself, but attaching it to certain elements
via CSS selectors.

Matt Kruse

 

[David Mark]

I agree with your criticisms, but I again must point out that it has
never been a problem for me. I suspect that the quality of the code
and logic in the library will improve before I find a case where it
would be a problem.

You already have problems if you use jQuery on the public Internet.
And what makes you think it will improve? How long has it been out?
Look at the issues I cited in the other thread and realize that most
are trivial to fix. Of couse, the problem of patching bugs is
augmented by the sloppy coding style.

One thing I don't like about jQuery is the push to add all kinds of
handlers and stuff on the page load. I've found problems with that
approach, especially for internal webapps where "unobtrusive"
javascript is not a concern. But I do like the ability to use CSS

There is nothing wrong with seperating behavior from markup. It is a
good strategy for internal or external applications.

selectors to apply handlers to specific things after the page loads.

If your app needs to attach multiple handlers, there are standard ways
of doing that. Using CSS selectors is counter-intuitive. Use jQuery
long enough and you become conditioned to design for what you perceive
as its strengths (e.g. saving you a few lines of code.) Furthermore,
putting jQuery's event handling logic between your elements and their
handlers is inefficient. This is especially true of the often-cited
hover handler.

I've used this often to improve existing pages where altering the HTML
source is not simple or in some cases possible.

There ia nothing wrong with that. But you don't need jQuery to do
it. In fact, jQuery will typically lead you to a solution that is
less than optimal.

That's quite an over-statement. Most web-development organizations I
know of don't have dedicated js programmers.

They don't have to be dedicated (just competent.)

Packed it is 26k. If you're concerned about file size.

You are deliberately side-stepping the issue. The compressed size is
not relevant. You can't compare it to other assets unless you
compress them as well, so it is more useful to compare uncompressed
sizes. It is more accurate as well as compression is not universally
available. Furthermore, it is a bad idea to manually compress
scripts. That is handled by the Web server, only after a negotiation
with each client.

Not the hover function itself, but attaching it to certain elements
via CSS selectors.

Doesn't it give you pause when you refer to CSS selectors with regard
to DOM queries?

 

[Matt Kruse]

They don't have to be dedicated (just competent.)

Even that is quite rare.

You are deliberately side-stepping the issue. The compressed size is
not relevant.

I didn't say compressed, I said packed. Using http://dean.edwards.name/packer/

Doesn't it give you pause when you refer to CSS selectors with regard
to DOM queries?

Not at all. It's a logical way to select elements in the DOM for
manipulation. It's fantastic.

Of course, you don't need jQuery to use CSS selectors. There are other
libs and even stand-alone functions that use the same approach. Why do
you not like the approach?

Matt Kruse

 

[David Mark]

Even that is quite rare.

And jQuery isn't helping the situation. Instead of trying to become
competent, developers learn how to use somebody else's incompetent
code.

I didn't say compressed, I said packed. Usinghttp://dean.edwards.name/packer/

I thought you might be referring to that. But who in their right mind
would use that thing? HTTP compression is widely supported. Even
without that, dial-up users don't need extra help compressing text
files (the modems take care of it.)

Not at all. It's a logical way to select elements in the DOM for
manipulation. It's fantastic.

It makes little sense to me. Even less sense after looking at the
jQuery code that implements it. I thought jQuery converted its CSS
selector queries into XPath queries when possible. After glancing at
that code again, it doesn't appear to be the case.

Of course, you don't need jQuery to use CSS selectors. There are other
libs and even stand-alone functions that use the same approach. Why do
you not like the approach?

It makes no sense to me to pass CSS selector syntax to a function that
queries the DOM. And much of what jQuery (and Prototype) do in this
regard is of little practical use.

 

[Richard Cornford]

I haven't been forthcoming?
Corrrect.

Do you seriously think that having cross browser knowledge
"captured and consolidated in the *minds* of individuals"
is useful to anyone other than those individuals?

It is of more use to others than not having it.

I think many people would correctly infer my intent was
to determine if the knowledge had been consolidated into a
form that would be of use to others - a web site, book,
library, etc.

And it hasn't. All the information is availed but not consolidated.

Are you suggesting people interview these individuals?

Why not? What do you think you are doing at the moment?

I don't know why you feel I haven't been forthcoming.

The ratio of questions asked to answers given.

After getting the impression that many people on this
newsgroup felt that no existing JavaScript library was
worthwhile to use,

Try to remember what it is you have been shown here. It is almost
trivial to pick a library and find plenty of examples of code that has
been written where if the individual who wrote that code had understood
what they were doing they never would have written it (assuming that
they are sane). We are not talking subjective judgments or questions of
design or style here but instead specific things that technical
knowledge alone would have prevented. For example, in an earlier post I
showed an example from dojo where the HTML mark-up for a SCRIPT element
had been split up using a number of concatenation operations. As soon as
someone understands why they might be doing this (and I mean really
understands, not jut believes some old wife's tale, or slavishly
reproduces someone else's mystical incantation) they will do it
differently.

Thus when you see these things being done in the way it is done in dojo
(and many other places) it is reasonable to infer that the individual
responsible did not understand what they were doing, and so did not have
the relevant knowledge. And in the case of a community effort, like
dojo, the existence of such code implies that the most knowledgeable
person involved does not have this knowledge.

Should it be surprising that when observing that the people writing
theses libraries lack basic browser scripting knowledge that there
should then be extreme reticence is recommending that anyone use the
products of such self-evidently ignorant authors?

There is also the matter of considering what it may have been that these
authors would have produced if they had taken the time to learn browser
scripting before prematurely assuming themselves qualified to write
there libraries. The question of what changes to the designs of these
libraries would have followed from gaining the additional experience of
scripting web browsers. This is particularly pertinent when you observe
that the people who do have this experience are not creating large scale
general purpose and instead have totally different notions of what is
appropriate in browser script design.

I thought I'd start with a base case and see if there was
any library (in active use was implied) that was worthwhile
to use in any context.

To which the answer was always going to be 'none', because javascript
design decisions should be context driven, which would not be the case
if they could be context independent.

Getting an answer
to that question has been like pulling teeth!

Only because you insist that that question should have an answer when
the rational response is to ask you to qualify the context (which is
what has happened).

Maybe you got the impression I was playing games here,
but I honestly wanted to see if any of the regulars here
felt any library was worthwhile.

But you did not explain what there libraries were supposed to be
worthwhile for, even though you were asked.

Yes, you and David keep reiterating that "no one says you
have to write it all yourself", and yet you also won't
mention any worthwhile libraries to use.

Didn't I put quite a lot of effort into explaining that those are not
the only two alternatives?

So, let me ask you, if one doesn't need to "write it
all themselves" - where do you suggest people obtain the
code that they haven't written?

If you spend your time looking for libraries the results will either be
your finding libraries or your not finding them. My design strategy
would have me looking for independent task-specific modules and finding
those in many places, including the archives for this group.

There are certainly people who have stated they felt the
only reasonable course of action was to write all
JavaScript code themselves,

No there are not.

so maybe by "nobody" you meant you and a few others.

No, it means nobody sane.

Naturally.

So isn't it understandable that you would not get recommendations
without first stating the context.

But since my impression was that this group felt all
existing JavaScript libraries were not good enough
to use (that statement has been made multiple times),

There are certainly very good reasons for question the fitness of many
available libraries for any task. You will recall that I have
demonstrated in this thread that dojo includes code that falls into the
mystical incantation style of programming, and clear evidence of its
authors either not understanding the basics of javascript or not being
rational.

I simply wanted to know if you felt any libraries were
good enough in any context.

And I have proposed two contexts for which particular libraries would be
well suited. And indeed it is the very design flaws in Prototype.js that
make it well suited in the context of wanting to have the user's
computer run hot.

And by library, I think a reasonable person would discount
a few lines of code whipped up for the purpose of this
discussion - I was referring to something on a public web
site currently in existence.


Wow, finally! So, for some contexts, you feel YUI is a
worthwhile library to use.

Well yes. YUI was designed as an application framework for a search
engine provider, so if you are a search engine provider looking for an
application framework it could be 100% suited to your context.

Are there any others?

Yes, there are many competently written single task/context libraries
that are entirely fit for the single task/context for which they were
written.

I take it that you feel both
Prototype and JQuery are not worthwhile.

I think Prototype.js has an inherently stupid design. JQuery is not code
that I have really looked at, though the snippets of it posted here do
not suggest competence on the part of its author.

Is YUI the only one that is
in your opinion?

That is not what I said, or even implied.

What I was trying to achieve was to determine a set of JavaScript
libraries that might be worth investing time in researching.

Of the libraries discussed here the only one that is worth researching
is YUI, unless you want examples of code written by people who don't
really understand what they are doing. But YUI is not a panacea. The
further you move away from the context for which it was designed the
less suited it will be to that context.

The purpose was clear,

Not really, that last sentence was the first time you asked for
"libraries that might be worth investing time in researching", which is
a very different criteria from any previously mentioned.

but my choice of information source was
seriously misguided.

This certainly is not the place to ask questions if you insist on
getting only pre-defined answers.

Richard.

 

[Brian Adkins]

Not really, that last sentence was the first time you asked for
"libraries that might be worth investing time in researching", which is
a very different criteria from any previously mentioned.

Ok, if you feel that "worthwhile" and "worth investing time in
researching" are "very different" concepts, I think I can see why
we're having difficulty communicating, and we're likely to have
continued communication difficulties. I'll assume responsibility for
the miscommunication, and move on to new and wonderful JavaScript
threads of discussion free of the term "library".

Brian