Javascript Library

345 views
Skip to first unread message

shapper

unread,
Oct 28, 2007, 8:48:04 PM10/28/07
to
Hello,

I would like to use a javascript library to simplify my coding
process.
I know a few: JQuery, Dojo, Yahoo UI, ...

Which one do you advice me to use?

Thanks,
Miguel

Thomas 'PointedEars' Lahn

unread,
Oct 28, 2007, 8:50:22 PM10/28/07
to
shapper wrote:
> I would like to use a javascript library to simplify my coding
> process. I know a few: JQuery, Dojo, Yahoo UI, ...
>
> Which one do you advice me to use?

Until further notice: yours.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Peter Michaux

unread,
Oct 28, 2007, 10:14:51 PM10/28/07
to

This question comes up frequently on comp.lang.javascript. There is
currently a thread that shows the feeling of many of the regulars here
that none of these libraries will do...

<URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/0939ea42f3f7647f/7913289a7a41be97#7913289a7a41be97>

Peter

Brian Adkins

unread,
Oct 29, 2007, 11:26:09 AM10/29/07
to
On Oct 28, 8:50 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> shapper wrote:
> > I would like to use a javascript library to simplify my coding
> > process. I know a few: JQuery, Dojo, Yahoo UI, ...
>
> > Which one do you advice me to use?
>
> Until further notice: yours.

Richard, do you still assert that no one is saying "write it all
yourself"?

David Mark

unread,
Oct 29, 2007, 11:55:33 AM10/29/07
to

I don't see Richard in this thread. Regardless, your library does not
have to be 100% self-written. IIRC, Richard stated something to that
effect in the other "please recommend a library" thread.


Matt Kruse

unread,
Oct 29, 2007, 12:01:37 PM10/29/07
to

There are pros and cons to each, but I recommend jQuery. It is
powerful, compact, easy to understand, and has an active support
community.

Matt Kruse

David Mark

unread,
Oct 29, 2007, 12:25:44 PM10/29/07
to
On Oct 29, 12:01 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Oct 28, 7:48 pm, shapper <mdmo...@gmail.com> wrote:
>
> > I would like to use a javascript library to simplify my coding
> > process.
> > I know a few: JQuery, Dojo, Yahoo UI, ...
> > Which one do you advice me to use?
>
> There are pros and cons to each, but I recommend jQuery. It is

The first two are right out. Why take the time to learn an API that
has terrible code behind it. People would be better off spending time
writing their own terrible code. At least they would learn something
worthwhile in the process.

> powerful, compact, easy to understand, and has an active support
> community.

Powerful perhaps, but the copy I have here is 82K. Perhaps it would
lose 30K or so minified.

Having recently looked over the code, I can tell you it is poorly
written and full of mistakes. Any time saved coding will come back to
you in maintenance and trouble-shooting.

Matt Kruse

unread,
Oct 29, 2007, 12:47:33 PM10/29/07
to
On Oct 29, 11:25 am, David Mark <dmark.cins...@gmail.com> wrote:
> The first two are right out. Why take the time to learn an API that
> has terrible code behind it. People would be better off spending time
> writing their own terrible code.

Learning the API takes, perhaps, a few hours. Even if it does have
terrible code behind it (it does not), the improvement in end result
will still be beneficial to most, because most are already writing
terrible code that doesn't even have the benefit of working most of
the time.

> Powerful perhaps, but the copy I have here is 82K. Perhaps it would
> lose 30K or so minified.

There is a minified download option. Check it out.

> Having recently looked over the code, I can tell you it is poorly
> written and full of mistakes.

Without any examples or real critiques to back up that broad
statement, it's worthless.

I've been writing javascript for over 10 years, and I've seen poorly
written code. jQuery is not poorly written. Nor is it "full of
mistakes".

I can see things in the code that I would change and improve, and a
number of them are actually already in as tickets for changes in
future versions. No free collaborative effort is without its problems.

Would you also throw out the Wikipedia as "junk" because you find an
article with technical errors?

> Any time saved coding will come back to
> you in maintenance and trouble-shooting.

My real-world experience differs from your hypothesis. I can measure
the _huge_ benefits of using jQuery in real dollars, and it is
significant.

I'd love to hear about your experience with jQuery and the maintenance
and trouble-shooting that you were required to do.

Matt Kruse

David Mark

unread,
Oct 29, 2007, 1:42:36 PM10/29/07
to
On Oct 29, 12:47 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Oct 29, 11:25 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > The first two are right out. Why take the time to learn an API that
> > has terrible code behind it. People would be better off spending time
> > writing their own terrible code.
>
> Learning the API takes, perhaps, a few hours. Even if it does have
> terrible code behind it (it does not), the improvement in end result

Run it through JSLint. Then search it for "userAgent." Then look at
the logic that tests for a function. That's three strikes right
there.

> will still be beneficial to most, because most are already writing
> terrible code that doesn't even have the benefit of working most of
> the time.

How is it beneficial to swap one's own terrible code for the terrible
code of another. Is it easier to debug somebody else's code?

>
> > Powerful perhaps, but the copy I have here is 82K. Perhaps it would
> > lose 30K or so minified.
>
> There is a minified download option. Check it out.

Isn't that what I said? Running it through a minifier will lose about
30K. I just tried it here and my estimation was almost exactly right.

>
> > Having recently looked over the code, I can tell you it is poorly
> > written and full of mistakes.
>
> Without any examples or real critiques to back up that broad
> statement, it's worthless.

Try searching this very newsgroup for jQuery. You will find lots of
examples.

>
> I've been writing javascript for over 10 years, and I've seen poorly

Lots of people can make that claim. How many of them are competent to
script browsers?

> written code. jQuery is not poorly written. Nor is it "full of
> mistakes".

Then despite your vast experience with JavaScript, you still don't get
it.

>
> I can see things in the code that I would change and improve, and a
> number of them are actually already in as tickets for changes in

That's comforting.

> future versions. No free collaborative effort is without its problems.
>
> Would you also throw out the Wikipedia as "junk" because you find an
> article with technical errors?

That is an odd comparison.

>
> > Any time saved coding will come back to
> > you in maintenance and trouble-shooting.
>
> My real-world experience differs from your hypothesis. I can measure
> the _huge_ benefits of using jQuery in real dollars, and it is
> significant.

And how would you quantify the benefits of "using jQuery" in dollars?

>
> I'd love to hear about your experience with jQuery and the maintenance

Having read the script, I concluded it was worthless. Therefore, I do
not use it.

> and trouble-shooting that you were required to do.
>

By the same token, I do not have to trouble-shoot it.

Matt Kruse

unread,
Oct 29, 2007, 3:00:13 PM10/29/07
to
On Oct 29, 12:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
> Run it through JSLint.

Which is about as useful as validating HTML. Great for academic
purposes, perhaps it will catch a few errors, etc.
But in the end it doesn't matter if code passes analytics, just if it
accomplishes the goal or not. My goal never includes "pass
validation". Validation is merely a tool to reach my goal, when
needed.

> Then search it for "userAgent."

Browser sniffing is not encouraged, and in some cases in jQuery it is
really unnecessary. There are cases where it is beneficial.
Rather than writing lengthy logic to solve for every possible case,
you can write shorter logic to solve for a subset of cases you care
about.
It's not ideal, but it is a strategy. The amount of browser sniffing
in jQuery is minimal.

> Then look at the logic that tests for a function.

It may not be perfect, but have you ever come across a real-world case
where it has failed for you?

Me neither.

> How is it beneficial to swap one's own terrible code for the terrible
> code of another. Is it easier to debug somebody else's code?

jQuery's code is not terrible. It is a substantial improvement over
most javascript code written by average developers. In my experience.

> > There is a minified download option. Check it out.
> Isn't that what I said? Running it through a minifier will lose about
> 30K. I just tried it here and my estimation was almost exactly right.

The packed version is 26kb. Plenty small.

> > > Having recently looked over the code, I can tell you it is poorly
> > > written and full of mistakes.
> > Without any examples or real critiques to back up that broad
> > statement, it's worthless.
> Try searching this very newsgroup for jQuery. You will find lots of
> examples.

But why should I look up past examples? You said you recently looked
over the code and found that it was poorly written and full of
mistakes.
Surely you could provide some examples from your recent investigation?

> > I've been writing javascript for over 10 years, and I've seen poorly
> Lots of people can make that claim. How many of them are competent to
> script browsers?

I'm not sure "lots of people can make that claim". I consider myself
to be very knowledgeable about Javascript development, and I disagree
with your conclusions. Surely not everyone who disagrees with you is
categorically an amateur?

> > written code. jQuery is not poorly written. Nor is it "full of
> > mistakes".
> Then despite your vast experience with JavaScript, you still don't get
> it.

What don't I get? You are not providing any actual arguments. You
might as well just say "You're stupid!" and stick your tongue out.

Further, have you considered that perhaps it is you who just doesn't
get it?

> > Would you also throw out the Wikipedia as "junk" because you find an
> > article with technical errors?
> That is an odd comparison.

Perhaps. The point is, just because you notice a few flaws in
something does not mean it is worthless. It merely means it has flaws.
Which means it was probably developed by humans. If your goal is
perfection, you'll never find it.

> > My real-world experience differs from your hypothesis. I can measure
> > the _huge_ benefits of using jQuery in real dollars, and it is
> > significant.
> And how would you quantify the benefits of "using jQuery" in dollars?

#1:
(Previous time to develop functionality) - (current time to develop
similar functionality) = Time Savings
Time Savings * Pay Rate = Money Saved

#2:
(Number of JS bugs before) - (Number of JS bugs now) = Bug Savings
(Bug Savings) * (Avg Time to Fix JS Bugs) * Pay Rate = Money Saved

Consider the effects of introducing jquery to a large development
team:
1) Reduced time implementing similar functionality as before
2) Reduced number of bugs
3) Improvement of UI because developers have access to pre-made
plugins
4) Less time needed to write functionality from scratch and research
browser quirks
5) No problem reports from any end users

Now, how are you arguing that using jquery is not a huge benefit?

You would recommend that we stop using it and start coding from
scratch?

> > I'd love to hear about your experience with jQuery and the maintenance
> Having read the script, I concluded it was worthless. Therefore, I do
> not use it.

Then how would you know anything about an increase in maintenance
caused by using jQuery?
Can you quote the experience of anyone else who has used it and found
it to be a maintenance problem?
Or hell, can you quote anyone who has used it and found it to be a bad
decision for any reason?
Do you have any real-world experience with it?
If not, how do you possibly feel justified in criticizing it?

Matt Kruse

David Mark

unread,
Oct 29, 2007, 5:42:48 PM10/29/07
to
On Oct 29, 3:00 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Oct 29, 12:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Run it through JSLint.
>
> Which is about as useful as validating HTML. Great for academic

Invalid markup is certainly not useful.

> purposes, perhaps it will catch a few errors, etc.

In jQuery's case, virtually every line will have a problem (or
multiple problems.) That indicates a slap-dash effort.

> But in the end it doesn't matter if code passes analytics, just if it

It matters for the people who have to maintain it. And since you are
relying on these people, it matters to you.

> accomplishes the goal or not. My goal never includes "pass
> validation". Validation is merely a tool to reach my goal, when
> needed.

I don't know what that means. If you write invalid markup and messy
script, you invite problems.

>
> > Then search it for "userAgent."
>
> Browser sniffing is not encouraged, and in some cases in jQuery it is
> really unnecessary. There are cases where it is beneficial.

It is never beneficial.

> Rather than writing lengthy logic to solve for every possible case,
> you can write shorter logic to solve for a subset of cases you care
> about.

Which you could do without parsing the userAgent string.

> It's not ideal, but it is a strategy. The amount of browser sniffing
> in jQuery is minimal.
>

Hardly. It is woven into many important low-level functions. Here is
a particularly stupid snippet from the get/setAttribute wrapper called
attr:

} else if ( jQuery.browser.msie && name == "style" )
return jQuery.attr( elem.style, "cssText", value );

Do you have any idea how many agents jQuery will identify as IE? Do
you have any idea how trivial it is to properly feature detect IE's
broken get/setAttribute functionality?

Forget that for the moment, why is this function passing a style
object to itself? Its first parameter is supposed to be an element.
Later in the same function, it becomes apparent (that the author is
out of his mind.)

// IE elem.getAttribute passes even for style
else if ( elem.tagName ) {
...
// elem is actually elem.style ... set the style
} else {


There couldn't be a more critical function in the entire library and
it is pure gibberish. Even the comments are senseless. There are
several additional sniffs in this same function.

if ( jQuery.browser.msie && /href|src/.test(name) && !
jQuery.isXMLDoc(elem) )
return elem.getAttribute( name, 2 );

Just what sort of XML document runs script in IE? Certainly not an
XHTML document. Realize that this absurd line of code is evaluated
every time jQuery looks at an element's attribute.

Then there is this gem:

// Certain attributes only work when accessed via the old DOM 0 way
if ( fix[name] ) {
if ( value != undefined ) elem[fix[name]] = value;
return elem[fix[name]];

This demonstrates a stunning lack of understanding of attributes (and
IE's problems with them.) Where's the sniff (or feature detect) for
IE? This IE-specific workaround runs on everything.

Still in the same function:

else if ( value == undefined && jQuery.browser.msie &&
jQuery.nodeName(elem, "form") && (name == "action" || name ==
"method") )
return elem.getAttributeNode(name).nodeValue;

No comment for this magic spell, so there is no telling what it is
trying to do. One thing is certain. This code will run on lots of
non-IE agents.

It gets worse.

if ( value != undefined ) {
if ( name == "type" && jQuery.nodeName(elem,"input") &&
elem.parentNode )
throw "type property can't be changed";
elem.setAttribute( name, value );
}

Another example of confusing attributes with properties. This is also
an IE-specific workaround with no sniff (or feature detect.)

And just when you think you have seen every conceivable miscue (all in
a single function mind you.)

if ( name == "opacity" && jQuery.browser.msie ) {
if ( value != undefined ) {
// IE has trouble with opacity if it does not have layout
// Force it by setting the zoom level
elem.zoom = 1;

What in God's name do opacity (and other styles) have to do with
attributes?

That's enough of that function. Keep in mind that the code therein is
called constantly by jQuery. Unfortunately for those who rely on
jQuery, it is error-prone, confused, inefficient and convoluted. The
design (and documentation) is of such poor quality that it is an
assault on the senses of anyone unfortunate enough to glance at it.

And speaking of opacity. In the curCSS function:

if (prop == "opacity" && jQuery.browser.msie) {
ret = jQuery.attr(elem.style, "opacity");
return ret == "" ? "1" : ret;
}

So any agent that identifies as IE and will be re-routed to the attr
function, which has nothing to do with style, but does contain more
sniffing and some IE-specific DirectX twiddling, which will have no
(positive) effect on non-IE agents.

It would seem that querying style rules would be almost as critical to
querying attributes in a library like jQuery. Yet, in this same
function you find this gem:

// A helper method for determining if an element's values are broken
function color(a){
if ( !jQuery.browser.safari )
return false;

var ret = document.defaultView.getComputedStyle(a,null);
return !ret || ret.getPropertyValue("color") == "";
}

This is the author's idea of a feature detect for getComputedStyle.
Why Safari-like browsers are excluded is a mystery. After that
inauspicious start, it blunders into the defaultView, getComputedStyle
and getPropertyValue properties with the impunity of somebody who
hasn't got a clue as to what they are doing.

It goes on and on. From the clean function:

if ( jQuery.browser.msie ) { // String was a <table>, *may* have
spurious <tbody>
if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
tb = div.firstChild && div.firstChild.childNodes;

div *may* have a firstChild property.

>From the same function:

// IE can't serialize <link> and <script> tags normally
jQuery.browser.msie && [1, "div<div>", "</div>"]

You have to keep in mind while reading this stuff that
jQuery.browser.msie is meaningless on the Web. It isn't of much use
on an Intranet either, unless you use the same version and
configuration of IE forever.

>From merge:

// Also, we need to make sure that the correct elements are being
returned
// (IE returns comment nodes in a '*' query)
if ( jQuery.browser.msie ) {
for ( var i = 0; second[i]; i++ )
if ( second[i].nodeType != 8 )
first.push(second[i]);
} else

Same problem different function. What if some agent that doesn't
identify as IE has the same problem? Also note how hard it is to
follow with all of the missing brackets.

More madness:

var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";

Obviously you should just check (or set) them both. What happens if
IE8 switches gears on this? And what of an IE-spoofing agent that
doesn't use "styleFloat?"

// Check to see if the W3C box model is being used
boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",

That could have far-reaching implications. A quick search found it in
an attempt to measure the viewport:

return this[0] == window ?
jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
Math.max(document.documentElement["client" + name],
document.body["client" + name]) ||
document.body["client" + name] :
this[0] == document ?
Math.max( document.body["scroll" + name], document.body["offset" +
name] ) :
h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
this.css( n, h.constructor == String ? h : h + "px" );

I characterized this as a "million monkey" project earlier and I want
to take a moment to apologize to monkeys everywhere. I think even a
single monkey could write a better solution to this very common
problem. Certainly there are many better solutions floating around on
the Internet.

And boxmodel can also be observed in the positioning code:

// IE adds the HTML element's border, by default it is medium which is
2px
// IE 6 and IE 7 quirks mode the border width is overwritable by the
following css html { border: 0; }
// IE 7 standards mode, the border is always 2px
if ( msie ) {
var border = jQuery("html").css("borderWidth");
border = (border == "medium" || jQuery.boxModel &&
parseInt(version) >= 7) && 2 || border;
add( -border, -border );
}
There are so many misconceptions here it is hard to know where to
begin. Suffice to say that the clientLeft/Top properties hold the
needed information in IE.

In the same function:

// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table cells
if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
border( offsetParent );

Apparently, in the jQuery universe there is only Opera, Mozilla,
Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
believe the comments) adds borders when it shouldn't. So this logic
excludes everything the author has ever heard of that isn't Opera.

Speaking of Mozilla. Does this look like a good indication of Mozilla-
based browsers?

mozilla: /mozilla/.test(userAgent) && !/(compatible|
webkit)/.test(userAgent)

Why not call that the everything-under-the-sun property?

Getting back to border issue, in the mozilla-and-newer-Safari-only
(and oddly named) border function:

add( jQuery.css(elem, "borderLeftWidth"), jQuery.css(elem,
"borderTopWidth") );

What an outrage. The author apparently never heard of clientLeft/Top.

Backing up to where boxModel was first spotted, this is deja vu:

styleFloat: jQuery.browser.msie ? "styleFloat" : "cssFloat",

Yes, this logic is repeated just three lines below the first instance.

Moving on. In the ready function:

if ( jQuery.browser.mozilla || jQuery.browser.opera )
document.removeEventListener( "DOMContentLoaded", jQuery.ready,
false );

So if it is virtually any agent, assume there is a document object (a
fair assumption) and assume that it has a removeEventListener method
(an outrageous assumption.) Why the event listener needs to be
removed at all is another interesting question. The comments
mentioned memory leaks.

Here is the flip-side of this in bindReady:

// If Mozilla is used
if ( jQuery.browser.mozilla || jQuery.browser.opera )
// Use the handy event callback
document.addEventListener( "DOMContentLoaded", jQuery.ready,
false );

So two of the four browsers that the author knows of are known to
support DOMContentLoaded. Of course, it wouldn't hurt to add this
listener for everything. Come to think of it, he did (unknowingly)
add it for virtually everything.

You've got to love the comments. "Use the handy event callback" may
be the least informative one yet. Here's another interesting one from
makeArray:

// Need to use typeof to fight Safari childNodes crashes
if ( typeof a != "array" )
for ( var i = 0, al = a.length; i < al; i++ )
r.push( a[i] );
else
r = a.slice( 0 );

And why would you pass an array to a "makeArray" function anyway?
This reminds me of the function test code, which was blistered in
another recent "jQuery is a joke" thread.

Enough is enough. If you use jQuery after reading this, you are
deserve everything you get.

> > Then look at the logic that tests for a function.
>
> It may not be perfect, but have you ever come across a real-world case
> where it has failed for you?
>
> Me neither.

Asked and answered? I still want to know what reak-world you are
from.

>
> > How is it beneficial to swap one's own terrible code for the terrible
> > code of another. Is it easier to debug somebody else's code?
>
> jQuery's code is not terrible. It is a substantial improvement over
> most javascript code written by average developers. In my experience.
>

Ten years, according to a previous post, and you haven't learned a
thing. And who cares how it stacks up to "average developers?" If
you take an average JavaScript developer and give them this mess to
play with, are you really empowering them to write competent
applications?

I didn't think so either.

> > > There is a minified download option. Check it out.
> > Isn't that what I said? Running it through a minifier will lose about
> > 30K. I just tried it here and my estimation was almost exactly right.
>
> The packed version is 26kb. Plenty small.

Really? Define packed. Minified it is roughly 50K. GZIP doesn't
enter into it (unless you can't comprehend why it is silly to compare
file sizes after compression.) How small would a 20K library be after
compression? Regardless, you shouldn't manually compress JavaScript
files.

>
> > > > Having recently looked over the code, I can tell you it is poorly
> > > > written and full of mistakes.
> > > Without any examples or real critiques to back up that broad
> > > statement, it's worthless.
> > Try searching this very newsgroup for jQuery. You will find lots of
> > examples.
>
> But why should I look up past examples? You said you recently looked
> over the code and found that it was poorly written and full of
> mistakes.

Sure did.

> Surely you could provide some examples from your recent investigation?

Sure could.

>
> > > I've been writing javascript for over 10 years, and I've seen poorly
> > Lots of people can make that claim. How many of them are competent to
> > script browsers?
>
> I'm not sure "lots of people can make that claim". I consider myself
> to be very knowledgeable about Javascript development, and I disagree
> with your conclusions. Surely not everyone who disagrees with you is
> categorically an amateur?

What you consider yourself to be is hardly relevant. If you use and
recommend jQuery, then you are worse than an amateur. You are doing a
disservice to anyone who is unfortunate enough to use your creations
or listen to your advice.

>
> > > written code. jQuery is not poorly written. Nor is it "full of
> > > mistakes".
> > Then despite your vast experience with JavaScript, you still don't get
> > it.
>
> What don't I get? You are not providing any actual arguments. You

You don't get JavaScript, browser scripting, etc.

> might as well just say "You're stupid!" and stick your tongue out.
>

If you use or advocate jQuery after today, you are stupid.

> Further, have you considered that perhaps it is you who just doesn't
> get it?

I've looked at that. I don't think so.

>
> > > Would you also throw out the Wikipedia as "junk" because you find an
> > > article with technical errors?
> > That is an odd comparison.
>
> Perhaps. The point is, just because you notice a few flaws in
> something does not mean it is worthless. It merely means it has flaws.

A few flaws?!

> Which means it was probably developed by humans. If your goal is
> perfection, you'll never find it.
>

Finding a library was never my goal. Regardless, there is a big
difference between competent and perfect.

> > > My real-world experience differs from your hypothesis. I can measure
> > > the _huge_ benefits of using jQuery in real dollars, and it is
> > > significant.
> > And how would you quantify the benefits of "using jQuery" in dollars?
>
> #1:
> (Previous time to develop functionality) - (current time to develop
> similar functionality) = Time Savings
> Time Savings * Pay Rate = Money Saved

Oversimplification.

>
> #2:
> (Number of JS bugs before) - (Number of JS bugs now) = Bug Savings
> (Bug Savings) * (Avg Time to Fix JS Bugs) * Pay Rate = Money Saved
>

You've got lots of bugs and future maintenance issues. Perhaps you
didn't know about a lot of them before today. And if you can't write
relatively bug-free code without jQuery (God knows you can't with it),
then perhaps you should consider another line of work.

> Consider the effects of introducing jquery to a large development
> team:

[snip considerations]

>
> Now, how are you arguing that using jquery is not a huge benefit?
>

I didn't read the considerations. I am tired of hearing about
jQuery. It sucks. Case closed.

> You would recommend that we stop using it and start coding from
> scratch?

Why do library-advocates invariably see just those two choices? Do
whatever you want.

>
> > > I'd love to hear about your experience with jQuery and the maintenance
> > Having read the script, I concluded it was worthless. Therefore, I do
> > not use it.
>
> Then how would you know anything about an increase in maintenance
> caused by using jQuery?

You don't have to be psychic to see what lies ahead for your team.

> Can you quote the experience of anyone else who has used it and found
> it to be a maintenance problem?

I really don't talk to jQuery users. They tend to babble on and on
about nothing.

> Or hell, can you quote anyone who has used it and found it to be a bad
> decision for any reason?

I don't think I need to quote anyone at this point.

> Do you have any real-world experience with it?

You are repeating yourself.

> If not, how do you possibly feel justified in criticizing it?

See above.

Jeff North

unread,
Oct 30, 2007, 7:50:50 AM10/30/07
to
On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
<dmark....@gmail.com>
<1193694168.9...@22g2000hsm.googlegroups.com> wrote:

Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?
-- -------------------------------------------------------------
jnor...@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------

Evertjan.

unread,
Oct 30, 2007, 8:13:17 AM10/30/07
to
Jeff North wrote on 30 okt 2007 in comp.lang.javascript:

> Thank you for the insightful review of jQuery.
> Could you please tell me where I can get a copy of your js library?
>

What and to who are you replying, Jeff?

[please always quote on usenet]

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Douglas Crockford

unread,
Oct 30, 2007, 9:16:56 AM10/30/07
to
Peter Michaux wrote:
> On Oct 28, 5:48 pm, shapper <mdmo...@gmail.com> wrote:
>> Hello,
>>
>> I would like to use a javascript library to simplify my coding
>> process.
>> I know a few: JQuery, Dojo, Yahoo UI, ...
>>
>> Which one do you advice me to use?
>
> This question comes up frequently on comp.lang.javascript. There is
> currently a thread that shows the feeling of many of the regulars here
> that none of these libraries will do...

I would urge many of the regulars to reconsider their positions. Some of the
Ajax libraries have gotten quite good lately. They eliminate most of the browser
inconsistencies, relieving one of the major pain points in browser programming.
And they shift the level of programming up a level, so that you can focus more
on your application, and less on the browser's many limitations.

The biggest problems with the libraries are that there are too many of them, and
that there are some problems with the browser architecture (particularly with
security) that are unsolvable, given the current state of standards and browser
implementations.

It looks like the too many problem will solve itself with a shake out. I am
predicting that the winners of the shake out will be Dojo and YUI because they
are the best supported and documented.

Good use of an Ajax library can improve your productivity and improve the
portability of your application. The library makers scramble when every new
browser ships to find the workarounds for the new bugs and gotchas. They are
much better at that game than you want to be.

Matt Kruse

unread,
Oct 30, 2007, 10:32:03 AM10/30/07
to
On Oct 30, 8:16 am, Douglas Crockford <nos...@sbcglobal.net> wrote:
> It looks like the too many problem will solve itself with a shake out. I am
> predicting that the winners of the shake out will be Dojo and YUI because they
> are the best supported and documented.

They are both huge monster libraries, though, and that is not a
selling point.

I've recently seen Dojo killed from several projects because it was
too huge, confusing, and slow.

Matt Kruse


David Mark

unread,
Oct 30, 2007, 10:50:20 AM10/30/07
to
On Oct 30, 7:50 am, Jeff North <jnort...@yahoo.com.au> wrote:
> On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
> <dmark.cins...@gmail.com>

>
> <1193694168.952251.143...@22g2000hsm.googlegroups.com> wrote:
>
> Thank you for the insightful review of jQuery.
> Could you please tell me where I can get a copy of your js library?

You cannot. Though I have recently considered posting the basic
essentials as a foundation for those who wish to write their own
libraries.

Message has been deleted

David Mark

unread,
Oct 30, 2007, 11:48:21 AM10/30/07
to
On Oct 30, 9:16 am, Douglas Crockford <nos...@sbcglobal.net> wrote:
> Peter Michaux wrote:
> > On Oct 28, 5:48 pm, shapper <mdmo...@gmail.com> wrote:
> >> Hello,
>
> >> I would like to use a javascript library to simplify my coding
> >> process.
> >> I know a few: JQuery, Dojo, Yahoo UI, ...
>
> >> Which one do you advice me to use?
>
> > This question comes up frequently on comp.lang.javascript. There is
> > currently a thread that shows the feeling of many of the regulars here
> > that none of these libraries will do...

Certainly not jQuery or Dojo. I haven't looked into YUI very deeply,
but then YUI is just a big container for lots of little modules, so
the "should I use YUI" question is too vague. Should one use the YUI
tree widget? I would say no. Should one use the YUI events module?
I would say maybe. If it is stand-alone, efficient and employs no
browser sniffing, then perhaps.

>
> I would urge many of the regulars to reconsider their positions. Some of the
> Ajax libraries have gotten quite good lately. They eliminate most of the browser

It seems to me that Ajax would be an optional module for a general
purpose JavaScript library. That's one of the many problems with
jQuery, Prototype and the like.

> inconsistencies, relieving one of the major pain points in browser programming.

But if they do so with browser sniffing, then you mortgage your future
by relying on them.

> And they shift the level of programming up a level, so that you can focus more
> on your application, and less on the browser's many limitations.
>

But at what cost? Many of the popular libraries have their own
limitations. Some support only a handful of modern browsers. Most
rely on userAgent parsing to work around browser limitations. Is it
useful to invest time learning the limitations of a library, only to
have those limitations change every time a new browser version
appears?

> The biggest problems with the libraries are that there are too many of them, and

And all of them try to do everything. None masters all, so developers
end up using multiple libraries, which leads to triple-digit page
weights, namespace collisions, etc.

> that there are some problems with the browser architecture (particularly with
> security) that are unsolvable, given the current state of standards and browser
> implementations.

I assume you are talking about Ajax issues.

>
> It looks like the too many problem will solve itself with a shake out. I am
> predicting that the winners of the shake out will be Dojo and YUI because they
> are the best supported and documented.

I understand why you endorse YUI, but have you looked at the Dojo
source?

You obviously know ECMAScript/JavaScript very well. I assume you are
also well-versed in DOM variations and page optimization issues.
Would you recommend using the heavy YUI widgets on a site that isn't
Yahoo!?

>
> Good use of an Ajax library can improve your productivity and improve the

There needs to be a differentiation between "Ajax library" and
"JavaScript library." Too many developers think JavaScript
enhancements and Ajax are the same thing.

> portability of your application. The library makers scramble when every new

Portability to what? Libraries like Dojo, jQuery, ProtoType, etc.
aren't particularly backwards compatible, nor do they support a
significant number of current agents. And due to their reliance on
browser sniffing, they are not future-proof.

> browser ships to find the workarounds for the new bugs and gotchas. They are
> much better at that game than you want to be.

They are pretty weak at it from what I have seen. Who wants to rely
on third-parties to reevaluate their delusional inferences every time
a new browser is released?

Matt Kruse

unread,
Oct 30, 2007, 12:12:56 PM10/30/07
to
On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
> > Could you please tell me where I can get a copy of your js library?
> You cannot.

Why not?

> Though I have recently considered posting the basic
> essentials as a foundation for those who wish to write their own
> libraries.

I would encourage you to do so. Please provide full documentation,
test suites, examples, and support as well.

Matt Kruse


David Mark

unread,
Oct 30, 2007, 12:55:12 PM10/30/07
to
On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Could you please tell me where I can get a copy of your js library?
> > You cannot.
>
> Why not?

Because I don't want to give it to him.

>
> > Though I have recently considered posting the basic
> > essentials as a foundation for those who wish to write their own
> > libraries.
>
> I would encourage you to do so. Please provide full documentation,
> test suites, examples, and support as well.

Why would you care?

vbgunz

unread,
Oct 30, 2007, 1:21:57 PM10/30/07
to

there needs to be a DOM library. anyone know of one?

Evertjan.

unread,
Oct 30, 2007, 1:25:46 PM10/30/07
to
vbgunz wrote on 30 okt 2007 in comp.lang.javascript:

> there needs to be a DOM library.

Why?

> anyone know of one?

Doug Miller

unread,
Oct 30, 2007, 1:27:39 PM10/30/07
to
In article <1193763312.3...@22g2000hsm.googlegroups.com>, David Mark <dmark....@gmail.com> wrote:
>On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
>> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> > > Could you please tell me where I can get a copy of your js library?
>> > You cannot.
>>
>> Why not?
>
>Because I don't want to give it to him.

So sell it. <g>

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

David Mark

unread,
Oct 30, 2007, 1:48:37 PM10/30/07
to
On Oct 30, 1:27 pm, spamb...@milmac.com (Doug Miller) wrote:

> In article <1193763312.381969.138...@22g2000hsm.googlegroups.com>, David Mark <dmark.cins...@gmail.com> wrote:
>
> >On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
> >> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> > > Could you please tell me where I can get a copy of your js library?
> >> > You cannot.
>
> >> Why not?
>
> >Because I don't want to give it to him.
>
> So sell it. <g>

I have, in the past, considered selling JavaScript libraries and
widgets, but it seems to me that too many people are giving them
away. Factor in that most potential customers are unable to evaluate
code quality and you get a pretty lousy market outlook.

Matt Kruse

unread,
Oct 30, 2007, 2:46:55 PM10/30/07
to
On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> > > > Could you please tell me where I can get a copy of your js library?
> > > You cannot.
> > Why not?
> Because I don't want to give it to him.

Why not? What would it hurt?

> > I would encourage you to do so. Please provide full documentation,
> > test suites, examples, and support as well.
> Why would you care?

Because maybe I would switch to it if it was better than what I'm
already using.

Until a better alternative _actually exists_, people will continue to
use the library that they find best suited for their task.

Your argument sounds like:
1. All libraries suck
2. I know the better way to do it
3. I have a library that is better than any other out there
4. You can't have it

It's really a pretty simple question that the critics here never want
to answer:

Let's say a group of developers are building a webapp that needs some
Javascript development. There is no in-house library to start with,
and all of the developers are just average at javascript, at best.
What would be your recommendation? I see some possibilities:

1. Use a freely-available library that isn't perfect, but has lots of
examples, speeds up development, and doesn't appear to break in any
cases
2. Write everything from scratch, which might be lower quality than
the libraries and take too long
3. Hire a competent developer to write everything from scratch, which
again might take too long and may not be an option financially
4. Make a post to comp.lang.javascript asking which library to use and
be told that they all suck, and awesome library code exists but you
can't have it.
5. ???

In a real case like this, how would you recommend that people proceed?

Matt Kruse

Thomas 'PointedEars' Lahn

unread,
Oct 30, 2007, 4:07:38 PM10/30/07
to
vbgunz wrote:
> there needs to be a DOM library. anyone know of one?

For example, I have been distributing http://PointedEars.de/scripts/dhtml.js
as free software under the GPL v2 (or later) for almost five years now, and
I update it frequently (as the build version indicates) with regard to
backwards-compatibility to previous versions. What it still lacks is a
decent Web site (there is only a directory index), but it is documented
inline, and can be found by and with search engines.


HTH

David Mark

unread,
Oct 30, 2007, 4:09:02 PM10/30/07
to
On Oct 30, 2:46 pm, Matt Kruse <m...@mattkruse.com> wrote:
> On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > > Could you please tell me where I can get a copy of your js library?
> > > > You cannot.
> > > Why not?
> > Because I don't want to give it to him.
>
> Why not? What would it hurt?

What makes you think that modules developed for my own use would be
appropriate for somebody else? I already mentioned that perhaps I
will post some of the low-level reusable functions. If and when I
find the time to document them for the masses, I will do so.

>
> > > I would encourage you to do so. Please provide full documentation,
> > > test suites, examples, and support as well.
> > Why would you care?
>
> Because maybe I would switch to it if it was better than what I'm
> already using.

I think you misunderstand my intention. I have no plans to publish
the next free library. I might post some low-level functions, which
could be of interest to people who need a foundation to start their
own libraries.

>
> Until a better alternative _actually exists_, people will continue to
> use the library that they find best suited for their task.
>

I don't think jQuery is suited for any task (same goes for Prototype
and Dojo.) People who ask about those libraries in here rarely
mention a specific task anyway. They know they want to sell an "Ajax
site", but they don't want to learn how to script a browser.

> Your argument sounds like:
> 1. All libraries suck
> 2. I know the better way to do it
> 3. I have a library that is better than any other out there
> 4. You can't have it

You just don't get it. There is no single library that is appropriate
for every task. That is what jQuery, Prototype, etc. try to be and
they fail miserably at it. I build modules from reusable functions
that are specific to the task at hand. Yes, some of these modules
mirror the functionality that is lumped together in the publicly
available libraries. No, I didn't make the sort of ridiculous
mistakes that cripple these libraries. And no, I am not interested in
publishing and supporting my codebase as a free library. Sorry.

>
> It's really a pretty simple question that the critics here never want
> to answer:
>
> Let's say a group of developers are building a webapp that needs some
> Javascript development. There is no in-house library to start with,
> and all of the developers are just average at javascript, at best.
> What would be your recommendation? I see some possibilities:
>
> 1. Use a freely-available library that isn't perfect, but has lots of
> examples, speeds up development, and doesn't appear to break in any
> cases

What library do you know of that fits that description?

> 2. Write everything from scratch, which might be lower quality than
> the libraries and take too long

I am tired of hearing the "write everything from scratch" argument.
That is not the only other choice.

> 3. Hire a competent developer to write everything from scratch, which
> again might take too long and may not be an option financially

A competent developer would not write everything from scratch.

> 4. Make a post to comp.lang.javascript asking which library to use and
> be told that they all suck, and awesome library code exists but you
> can't have it.

For the last time, there is no "magic bullet" general purpose library
that is suitable for all tasks.

> 5. ???
>
> In a real case like this, how would you recommend that people proceed?
>

Real in the sense that you made it up? These "real" people should
proceed to either hire competent developers or learn JavaScript
themselves. In the latter case, the FAQ would be a good starting
point. If neither of these works for them, perhaps they shouldn't
write a Web app at all.

Matt Kruse

unread,
Oct 30, 2007, 4:38:45 PM10/30/07
to
On Oct 30, 3:07 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> For example, I have been distributinghttp://PointedEars.de/scripts/dhtml.js

> as free software under the GPL v2 (or later) for almost five years now

this.isIE4DOM = typeof document.all == "object" && !this.isOpera;

Really?

Matt Kruse


Jeff North

unread,
Oct 30, 2007, 5:00:32 PM10/30/07
to
On Tue, 30 Oct 2007 14:54:20 -0000, in comp.lang.javascript Matt Kruse
<ma...@mattkruse.com>
<1193756060....@o3g2000hsb.googlegroups.com> wrote:

>| On Oct 29, 4:42 pm, David Mark <dmark.cins...@gmail.com> wrote:
>| > [jQuery criticisms]


>| > Enough is enough. If you use jQuery after reading this, you are
>| > deserve everything you get.
>|

>| Thank you for your detailed reply. I am going to investigate these
>| things further and find out if jQuery can be improved.
>|
>| I haven't done an extensive look "under the hood" of jQuery, but I
>| have looked at some of the code. I've also noticed examples of
>| questionable code, but I assumed there was a reason for them doing
>| things the way they do. I've never had a problem with jQuery not
>| functioning correctly. As long as I see the expected behavior right
>| now, the underlying code can be streamlined and improved. All the
>| issues you mention can be fixed and improved while still maintaining
>| the same API, making the library more solid without the end-user even
>| knowing about the changes.


>|
>| > If
>| > you take an average JavaScript developer and give them this mess to
>| > play with, are you really empowering them to write competent
>| > applications?
>|

>| I still think so, yes. Having a developer program to the API to
>| simplify their development is a good thing. It's a layer over the low-
>| level stuff, but that enables them to be much more productive. If
>| there is a problem found in the library behavior, it can be fixed.


>|
>| > If you use or advocate jQuery after today, you are stupid.
>|

>| I will continue to use it and advocate it. I'll also try to improve
>| it.
>|
>| I guess I'm stupid.


>|
>| > > (Previous time to develop functionality) - (current time to develop
>| > > similar functionality) = Time Savings
>| > > Time Savings * Pay Rate = Money Saved
>| > Oversimplification.
>|

>| Really?


>|
>| > > You would recommend that we stop using it and start coding from
>| > > scratch?
>| > Why do library-advocates invariably see just those two choices?
>|

>| Because library-critics rarely provide any real answers or
>| suggestions. Just criticisms.
>|
>| It's easy to question everything. It's much harder to provide a real
>| answer.
>|
>| I have little respect for people who constantly bitch about what
>| everyone else provides for free to the world, yet never actually
>| provide anything themselves.
>|
>| If everyone else is doing it wrong, and you know how to do it right,
>| why don't you show the world how it should be done? Those who are the
>| supposed "experts" that bash everyone else rarely put their own
>| libraries and code up for public consumption and criticism. I have
>| respect for people like Peter who is obviously an intelligent and
>| knowledgeable contributor to this group and has also put his own
>| library out there. If the more vocal critics would do the same,
>| perhaps these other "horrible" libraries would die out and the world
>| would be a better place.
>|
>| Matt Kruse

Couldn't agree more.
What better place (c.l.j.) to show novice programmers the correct way
to code and also provide a resource of a robust library.

Thomas 'PointedEars' Lahn

unread,
Oct 30, 2007, 5:20:19 PM10/30/07
to

If you had quoted properly and would have used common sense, you would have
known that it is there for backwards compatibility to previous versions of
the library. If you would have looked further, you would have found the
value being used in the current version only sparsely, where it does little
to no harm. You may rest assured that I will continue to review and, where
necessary, refactor the code on a regular basis.

Thomas 'PointedEars' Lahn

unread,
Oct 30, 2007, 5:33:35 PM10/30/07
to
Thomas 'PointedEars' Lahn wrote:
> [...] You may rest assured that I will continue to review

> and, where necessary, refactor the code on a regular basis.

I would like to add that any constructive feedback regarding my code
between review cycles is appreciated of course. Thank you in advance.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Doug Miller

unread,
Oct 30, 2007, 6:09:09 PM10/30/07
to
Free stuff is often worth not much more than the price paid. If yours is
enough better than the free stuff, your market might be larger than you think.

David Mark

unread,
Oct 30, 2007, 6:50:19 PM10/30/07
to
On Oct 30, 6:09 pm, spamb...@milmac.com (Doug Miller) wrote:

> In article <1193766517.521764.170...@y42g2000hsy.googlegroups.com>, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> >On Oct 30, 1:27 pm, spamb...@milmac.com (Doug Miller) wrote:
> >> In article <1193763312.381969.138...@22g2000hsm.googlegroups.com>, David Mark
> > <dmark.cins...@gmail.com> wrote:
>
> >> >On Oct 30, 12:12 pm, Matt Kruse <m...@mattkruse.com> wrote:
> >> >> On Oct 30, 9:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> >> > > Could you please tell me where I can get a copy of your js library?
> >> >> > You cannot.
>
> >> >> Why not?
>
> >> >Because I don't want to give it to him.
>
> >> So sell it. <g>
>
> >I have, in the past, considered selling JavaScript libraries and
> >widgets, but it seems to me that too many people are giving them
> >away. Factor in that most potential customers are unable to evaluate
> >code quality and you get a pretty lousy market outlook.
>
> Free stuff is often worth not much more than the price paid. If yours is
> enough better than the free stuff, your market might be larger than you think.
>

But don't you think a large portion of that market would just steal
the code?

Brian Adkins

unread,
Oct 30, 2007, 8:17:56 PM10/30/07
to
On Oct 30, 4:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Oct 30, 2:46 pm, Matt Kruse <m...@mattkruse.com> wrote:
> > On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> > Your argument sounds like:
> > 1. All libraries suck
> > 2. I know the better way to do it
> > 3. I have a library that is better than any other out there
> > 4. You can't have it
>
> You just don't get it. There is no single library that is appropriate
> for every task.

The several recent threads about JavaScript libraries has seemed quite
confrontational to me. I'm sure I've contributed to that myself, so I
apologize. Maybe it was perceived that I was being difficult on
purpose, but I can say that it was out of frustration, and not out of
intent. I feel it's an important topic though, so I'd like to give
everyone the benefit of the doubt and try to work through what I think
are some communication issues.

David, is it possible you're misunderstanding Matt's intention? It may
be that he's not looking for a single library to be used for every
task, but is simply interested in being able to leverage preexisting
code written by others. Isn't this a common desire for programmers? If
we begin a networking project which requires C programming, we don't
start by developing a TCP/IP library, right?

For example, if someone wanted to utilize regular expressions in
Common Lisp, one option would be to write their own regular expression
library, and another option would be to simply use CL-PPCRE. There is
a web site: http://www.weitz.de/cl-ppcre/ which provides
documentation, etc. This library has received great reviews from the
Common Lisp community. It's important for newcomers to Common Lisp to
be aware that such libraries exist to avoid reinventing the wheel.

In the other thread, I was truly trying to discover if a similar
situation existed in the JavaScript world i.e. well known public
libraries that are worthwhile to use. Do you think it's reasonable for
JavaScript programmers (of any level) to be interested in reusing
preexisting code written by others in this way - not to shield them
from learning JavaScript, but to simply save some coding/testing/
debugging time?

> > 2. Write everything from scratch, which might be lower quality than
> > the libraries and take too long
>
> I am tired of hearing the "write everything from scratch" argument.
> That is not the only other choice.

Maybe there have been multiple "from scratch" posts because that
phrase has a different meaning with different people. I think other
people have been frustrated from this as well. I won't speak for Matt,
but when I see "write everything from scratch", I think the author is
referring to writing code themselves instead of utilizing preexisting
code from other sources.

So, when several people make the assertion that "you don't have to
write everything from scratch" or "you don't have to write it all
yourself", but don't provide a means for accomplishing that (i.e. a
source of preexisting code), it sounds like a circular argument and is
frustrating - for both parties I expect.

> > 4. Make a post to comp.lang.javascript asking which library to use and
> > be told that they all suck, and awesome library code exists but you
> > can't have it.
>
> For the last time, there is no "magic bullet" general purpose library
> that is suitable for all tasks.

I doubt that anyone would disagree with that statement. I also agree
that the larger a library is, the greater the possibility that you
won't need a large portion of it for a particular task. I think it's
probably common for people to inquire about large, general purpose
libraries such as Prototype, JQuery, Dojo, YUI, etc. because those are
the only ones they're familiar with because of the "press" they
receive.

It's possible that they aren't looking for that in particular (e.g. a
large bloated library), but feel the only way they can reuse
preexisting code written by others is by utilizing one of them, and so
are interested in trying to determine if learning/using one is a good
investment.

> > In a real case like this, how would you recommend that people proceed?
>

> These "real" people should
> proceed to either hire competent developers or learn JavaScript
> themselves.

Do you think learning JavaScript and utilizing someone else's
preexisting code is mutually exclusive? I'm not trolling, it's a
serious question. In every other language I've developed in
(Assembler, C, C++, Java, Ruby, Common Lisp, etc.) I've utilized
libraries written by others - not to avoid learning those languages,
but to be efficient. JavaScript running in a browser has some
challenges those other languages don't share with respect to library
use, but in principle, I would still think the benefits of library use
would apply.

tony.gurnick

unread,
Oct 30, 2007, 9:00:05 PM10/30/07
to
you could also argue that an "Ultimate Javascript Library" that I cant
have is infinitley more useless than a badly coded, in-efficient
library that I can have.

Richard Cornford

unread,
Oct 30, 2007, 10:11:13 PM10/30/07
to
Douglas Crockford wrote:
> Peter Michaux wrote:
>> On Oct 28, 5:48 pm, shapper wrote:
>>> Hello,
>>>
>>> I would like to use a javascript library to simplify
>>> my coding process.
>>> I know a few: JQuery, Dojo, Yahoo UI, ...
>>>
>>> Which one do you advice me to use?
>>
>> This question comes up frequently on comp.lang.javascript.
>> There is currently a thread that shows the feeling of many
>> of the regulars here that none of these libraries will do...
>
> I would urge many of the regulars to reconsider
> their positions.

Urgings would not be nearly as effective as sound reasoned arguments.

> Some of the Ajax libraries have gotten quite good lately.

That is a matter of opinion. One of the things that seems absent from
'Ajax libraries' is the middle layer between the XML HTTP requests and
the user interface; the layer that manages the coordination of the two
independent sources of asynchronous input (the user's actions and the
XML HTTP responses). Increasingly I am seeing web sites 'handling' the
issues in that area by switching to synchronous XML HTTP requests, which
is such a bad idea that 'Ajax libraries' really should not offer an
option to do synchronous requests.

> They eliminate most of the browser inconsistencies,

No they don't, and they don't even appear to be trying to as most pick a
small set of 'supported' browsers and will just fall apart if exposed to
anything outside of that set.

> relieving one of the major pain points in browser
> programming. And they shift the level of programming up
> a level, so that you can focus more on your application,
> and less on the browser's many limitations.

Maybe, but in some cases that shift may just be an abdication of
responsibility for the cross-browser issues.

> The biggest problems with the libraries are that there
> are too many of them,

I would say that a bigger problem is that these libraries are being
created by individuals who have not yet taken the time to learn
javascript, let alone browser scripting, and so are inevitably making
design mistakes, which then become entrenched because fixing them would
offend people already using the libraries.

> and that there are some problems with the browser
> architecture (particularly with security) that are
> unsolvable, given the current state of standards and
> browser implementations.

That is not really a problem with the libraries, except maybe some of
them make it easy to provoke security issues.

> It looks like the too many problem will solve itself with
> a shake out.

Probably, but not necessarily driven by rational criteria.

> I am predicting that the winners of the shake out will be
> Dojo and YUI because they are the best supported and
> documented.

You might be right, and it might be 'support' and 'documentation' that
decide the question, but that outcome would be a tragedy given how
utterly atrocious dojo actually is. There are just too many examples of
code like:-

| if(
| elem == null ||
| ((elem == undefined)&&(typeof elem == "undefined"))
| ){
| dojo.raise("No element given to dojo.dom.setAttributeNS");
| }

- in dojo for anyone to regard its authors as anything other than inept.
You know the logic of that code as well as I do, and can see that the
final - (typeof elem == 'undefined') - just cannot ever be evaluated,
and that the (elem == undefined) expression can only have one result
whenever it is evaluated (making its evaluation pure runtime overhead to
no purpose). It is a basic failure to understand javascript, and the
fact that it is there for all to see means that it marks the panicle of
javascript understanding among all the contributors to the dojo code.
This has obvious implications for the nature of 'support' available, and
where the authors don't actually understand the code they are writing
you also have to wonder how useful their documentation of their code
will prove.

> Good use of an Ajax library can improve your productivity
> and improve the portability of your application.

Can and will are not the same thing, and that action is not the only way
of achieving that outcome.

> The library makers scramble when every new browser ships

I bet they do, at least if it is a new version of one of the browsers
they chose to recognise in the first place. Most of the attempts to
handle multiple browsers that I have seen in this code is extremely
brittle and won't adapt at all well to changes in those browsers.

> to find the workarounds for the new bugs and gotchas.
> They are much better at that game than you want to be.

Better is very relative. If there is one thing that is obvious in the
common library's code it is that their authors have little knowledge of
cross-browser techniques, are not particularly good at pinning down the
cause and effect relationships of the issues they encounter and are
stuck in a mindset where each new browser/issue means another branch in
their code. With the bulk of that branching driven by browser sniffing.

Richard.

Peter Michaux

unread,
Oct 30, 2007, 10:51:53 PM10/30/07
to
On Oct 30, 5:17 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> On Oct 30, 4:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Oct 30, 2:46 pm, Matt Kruse <m...@mattkruse.com> wrote:
> > > On Oct 30, 11:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> > > Your argument sounds like:
> > > 1. All libraries suck
> > > 2. I know the better way to do it
> > > 3. I have a library that is better than any other out there
> > > 4. You can't have it
>
> > You just don't get it. There is no single library that is appropriate
> > for every task.
>
> The several recent threads about JavaScript libraries has seemed quite
> confrontational to me. I'm sure I've contributed to that myself, so I
> apologize. Maybe it was perceived that I was being difficult on
> purpose,

This is why I gave the logging example "library." It is not clear what
size, scope, and purpose of code you want to reuse and the criteria
keeps changing yet you still want an answer. If any size, scope and
purpose is sufficient then the logging example is sufficient. If the
size, scope and purpose matter even a bit then they must be specified
and you will get a much more useful answer.


> but I can say that it was out of frustration,

I was more confused than frustrated when I started JavaScript but had
similar discussions when I first participated in comp.lang.javascript.
This newsgroup is the only public online community that I've found
where the regulars generally do not recommend using the big name
libraries. Most of the other communities are dedicated to a particular
library so it is no surprise that they recommend a library.

Since the beginning for me, I could see the discussions on
comp.lang.javascript contained more valid information about JavaScript
and browser scripting than those other forums. That got me thinking
"those surly, rude, socially incapable programmers must know
something." I don't really think those adjectives apply quite as much
as I initially thought. It is good that at least somewhere on the
internet there are a group of people that aren't afraid to call it
like they see it and hurt some feelings.

When I've been involved with other online communities related to
libraries, I get a sense of "I don't want to learn JavaScript and if
we all band together and keep telling each other we are doing a good
job we will be fine." Generally criticism is not welcome in large
doses. The Prototype library group is a perfect example. That library
initially augmented Object.prototype which is about the worst possible
namespace you could append properties if you care about namespace
clashes and for-in enumerations (no I don't buy the hasOwnProperty()
stuff.) In the end the Prototype group saw the wisdom that others were
offering by telling them to stop doing that. But in the mean time
there were battles and arguments about it. The Prototype community
were defending their flag of honour and critics were derided and
labeled heretics. It took a long time to make that change. That
library is slowly changing it's ways. The library still augments other
built-in objects and it has caused problems with new browser releases,
the library is still distributed in one huge file and does all sorts
of contortions with the language. Do you want to wait for them to fix
that stuff too? You could learn JavaScript and write your own library
perfectly applicable to your situation without any of their legacy
restrictions far faster than they can change.


> and not out of
> intent. I feel it's an important topic though,

Code reuse is an important topic.


> so I'd like to give
> everyone the benefit of the doubt and try to work through what I think
> are some communication issues.
>
> David, is it possible you're misunderstanding Matt's intention? It may
> be that he's not looking for a single library to be used for every
> task, but is simply interested in being able to leverage preexisting
> code written by others. Isn't this a common desire for programmers? If
> we begin a networking project which requires C programming, we don't
> start by developing a TCP/IP library, right?

Starting a JavaScript project without a library is not quite like
starting a C project without TCP/IP library or stdlib or something
similarly fundamental. Even for a big project, the JavaScript library
code that you would need to write would be only a few thousand lines.
This is part of the reason so many JavaScript libraries exist: the
entry cost is low. To start a C project with no libraries would mean
tens of thousands of lines of libraries to write and I'd say those
libraries would be individually far more complex than any of the
JavaScript libraries. You would literally be operating at the bit
level at times and writing malloc would be no treat I'm sure.


> For example, if someone wanted to utilize regular expressions in
> Common Lisp, one option would be to write their own regular expression
> library, and another option would be to simply use CL-PPCRE. There is

> a web site:http://www.weitz.de/cl-ppcre/which provides


> documentation, etc. This library has received great reviews from the
> Common Lisp community. It's important for newcomers to Common Lisp to
> be aware that such libraries exist to avoid reinventing the wheel.

There are different priorities in browser scripting than the tasks for
which other languages are used. For example, code size matters much
more in browser scripting and perhaps doesn't matter much at all in
most other tasks.


> In the other thread, I was truly trying to discover if a similar
> situation existed in the JavaScript world i.e. well known public
> libraries that are worthwhile to use.

You can easily find people that will answer yes. There must be a
reason you stayed here.


> Do you think it's reasonable for
> JavaScript programmers (of any level) to be interested in reusing
> preexisting code written by others in this way - not to shield them
> from learning JavaScript, but to simply save some coding/testing/
> debugging time?

I first used YUI to learn many things. I've read some jQuery code and
ext to learn how they do CSS selectors. Using those libraries as
educational resources has been helpful.

The fundamental libraries seem to be for events and Ajax. Really with
those two libraries you can build everything else quite easily. I
wrote my own event and Ajax libraries (roughly based on the YUI API)
and you can even find them available on the web. It has worked out
much better than using one of the big name libraries. I still receive
emails from the YUI and Prototype ticket systems for tickets I created
over a year and a half ago. I didn't have time to wait for that long.
I also don't have any of the bloat of features that I don't use and
don't even think are a good idea to use.

Even if I had used a publicly available library for events and Ajax, I
have never had the opportunity to reuse widgets like a tabbed pane,
drop down menu, etc in my job. The main reason is I always need custom
features. High level components are just less reusable. However with a
base events library is it very easy to write a custom widget that has
exactly the necessary functionality and nothing more. The widgets I've
written have typically been a tenth the size of publicly available
widgets that do many things but not what I need.


> > > 2. Write everything from scratch, which might be lower quality than
> > > the libraries and take too long
>
> > I am tired of hearing the "write everything from scratch" argument.
> > That is not the only other choice.
>
> Maybe there have been multiple "from scratch" posts because that
> phrase has a different meaning with different people. I think other
> people have been frustrated from this as well. I won't speak for Matt,
> but when I see "write everything from scratch", I think the author is
> referring to writing code themselves instead of utilizing preexisting
> code from other sources.

Using preexisting code probably means different things to different
people.


> So, when several people make the assertion that "you don't have to
> write everything from scratch" or "you don't have to write it all
> yourself", but don't provide a means for accomplishing that (i.e. a
> source of preexisting code), it sounds like a circular argument and is
> frustrating - for both parties I expect.
>
> > > 4. Make a post to comp.lang.javascript asking which library to use and
> > > be told that they all suck, and awesome library code exists but you
> > > can't have it.
>
> > For the last time, there is no "magic bullet" general purpose library
> > that is suitable for all tasks.
>
> I doubt that anyone would disagree with that statement. I also agree
> that the larger a library is, the greater the possibility that you
> won't need a large portion of it for a particular task. I think it's
> probably common for people to inquire about large, general purpose
> libraries such as Prototype, JQuery, Dojo, YUI, etc. because those are
> the only ones they're familiar with because of the "press" they
> receive.
>
> It's possible that they aren't looking for that in particular (e.g. a
> large bloated library), but feel the only way they can reuse
> preexisting code written by others is by utilizing one of them, and so
> are interested in trying to determine if learning/using one is a good
> investment.

Sometimes they might not like the answer they receive.

> > > In a real case like this, how would you recommend that people proceed?
>
> > These "real" people should
> > proceed to either hire competent developers or learn JavaScript
> > themselves.
>
> Do you think learning JavaScript and utilizing someone else's
> preexisting code is mutually exclusive?

You need to understand JavaScript to use any of the publicly available
big name libraries. The more you understand and the more you look
around then I think the code in the libraries becomes less appealing.

At the next level above whether or not a library works or not is how
does it work. Libraries generally encourage particular style of
programming. jQuery is a good example. "Find stuff and do stuff to
it." I experimented with jQuery for a while and read examples on the
web. With jQuery, it is so easy (just characters of code) to find
stuff that people do it all the time. jQuery seems to have encouraged
it's users to write inefficient code. This is a problem beyond the
actual bugs and hacks that are in jQuery that may break with new
browser releases and may not have any substitutable solutions at all
when they do (eg the window.onload problem) due to the code that the
library has encouraged.


> I'm not trolling, it's a
> serious question. In every other language I've developed in
> (Assembler, C, C++, Java, Ruby, Common Lisp, etc.) I've utilized
> libraries written by others - not to avoid learning those languages,
> but to be efficient. JavaScript running in a browser has some
> challenges those other languages don't share with respect to library
> use, but in principle, I would still think the benefits of library use
> would apply.

There is a feeling that the average ability of library writers in
JavaScript/browser scripting is far lower than the average abilities
of programmers in other languages/contexts. This is likely due where
JavaScript programmers come from in life. Without stats I would guess
less have computer science degrees and more are self-taught. This
makes your comparison less apples-to-apples as the libraries in the
other languages may have been more worthy of reuse.

Peter

Brian Adkins

unread,
Oct 30, 2007, 11:26:40 PM10/30/07
to
On Oct 30, 10:51 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Oct 30, 5:17 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > The several recent threads about JavaScript libraries has seemed quite
> > confrontational to me. I'm sure I've contributed to that myself, so I
> > apologize. Maybe it was perceived that I was being difficult on
> > purpose,
>
> This is why I gave the logging example "library." It is not clear what
> size, scope, and purpose of code you want to reuse and the criteria
> keeps changing yet you still want an answer. If any size, scope and
> purpose is sufficient then the logging example is sufficient. If the
> size, scope and purpose matter even a bit then they must be specified
> and you will get a much more useful answer.

I'm sorry Peter, but if you continue to insist that what you provided
was a realistic solution to my question (regardless of how ill-formed
you may have felt it was), I think it may be difficult for us to have
a conversation. I noticed you put "library" in quotes, so maybe you
sensed it was not a reasonable solution also.

If you honestly feel that you would consider creating a web site, for
example, to offer that code to the public as a "library", then I
apologize, but I seriously doubt that is the case. Do you now
understand why I included "publicly available" as a criteria?

Anyway, if any library/module authors who were proud of their code
were reading any of these threads, I expect they would have mentioned
their offerings by now, so we're probably beyond beating a dead horse
at this point, I think it's probably a bloody pulp :)

> When I've been involved with other online communities related to
> libraries, I get a sense of "I don't want to learn JavaScript

I believe you, and others, may have projected that attitude onto
people who don't share it. That's probably where the "straw man"
arguments keep coming from - not from maliciousness, but from not
bothering to actually understand where people are coming from and
simply assuming.

> Code reuse is an important topic.

Do you reuse code from others? If so, what are the sources of code
that you've found valuable.

> The fundamental libraries seem to be for events and Ajax. Really with
> those two libraries you can build everything else quite easily. I
> wrote my own event and Ajax libraries (roughly based on the YUI API)
> and you can even find them available on the web.

Well, why the heck didn't you mention those instead of the logger
thing ?! :) What's the URL?

> It has worked out
> much better than using one of the big name libraries. I still receive
> emails from the YUI and Prototype ticket systems for tickets I created
> over a year and a half ago. I didn't have time to wait for that long.
> I also don't have any of the bloat of features that I don't use and
> don't even think are a good idea to use.

If I end up writing a lot of code myself, that's fine, but it doesn't
make sense to reinvent the wheel if you don't have to. I have to say
the effort to have a dialog here has been much more than any other
newsgroup. Discovering some valuable, time saving libraries for Common
Lisp was straightforward.

> > Maybe there have been multiple "from scratch" posts because that
> > phrase has a different meaning with different people. I think other
> > people have been frustrated from this as well. I won't speak for Matt,
> > but when I see "write everything from scratch", I think the author is
> > referring to writing code themselves instead of utilizing preexisting
> > code from other sources.
>
> Using preexisting code probably means different things to different
> people.

Yes, but "preexisting code from other sources" should be pretty clear,
even in this crowd, right? "preexisting" => "it has already been
written"
"from other sources" => "I didn't write it"

Brian

Matt Kruse

unread,
Oct 30, 2007, 11:54:24 PM10/30/07
to
On Oct 30, 3:09 pm, David Mark <dmark.cins...@gmail.com> wrote:
> What makes you think that modules developed for my own use would be
> appropriate for somebody else?

Do you think you are solving extremely unique problems?

> I think you misunderstand my intention. I have no plans to publish
> the next free library. I might post some low-level functions, which
> could be of interest to people who need a foundation to start their
> own libraries.

I assume you have assembled your low-level functions into high-level
functionality at some point, so surely you have developed enough
functionality to accomplish complex tasks. Why not post all the code
you have - even if undocumented - as a great jump-start to anyone want
to assemble those pieces into something they would find useful?

> You just don't get it. There is no single library that is appropriate
> for every task. That is what jQuery, Prototype, etc. try to be and
> they fail miserably at it.

I think you misjudge the intent. IMO, these libraries intend to be a
solid framework that combine low-level reusable functions with an
intuitive API. They don't try to solve every problem. They give the
developer a different set of tools to use. Tools which are often more
compact, easier to use, and provide good browser abstraction.

Inserting jquery.js into a page will do nothing for you. It's just a
tool. You still need to write code.

How is this approach any different from your own set of low-level
functions? Libraries like jQuery just assemble the most often-used set
of tools and give them a consistent API. In under 30k of code, you
have a large set of functionality that you know will always be
available without having to piece together various functions to do
exactly what you want. How is that bad?

> And no, I am not interested in
> publishing and supporting my codebase as a free library. Sorry.

Which is ridiculous. So you have nothing to really offer anyone except
bashing the solutions others are developing. Great approach!

> I am tired of hearing the "write everything from scratch" argument.
> That is not the only other choice.

What _is_ the other choice? Could you be more specific?
If you don't get a library or set of functions from someone else, will
it magically write itself?

> For the last time, there is no "magic bullet" general purpose library
> that is suitable for all tasks.

I don't see anyone claiming that there is.

But there are general purpose libraries that provide a set of tools
and framework that will be beneficial in many common tasks.

Matt Kruse

Peter Michaux

unread,
Oct 31, 2007, 12:32:55 AM10/31/07
to
On Oct 30, 8:26 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> On Oct 30, 10:51 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 30, 5:17 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > The several recent threads about JavaScript libraries has seemed quite
> > > confrontational to me. I'm sure I've contributed to that myself, so I
> > > apologize. Maybe it was perceived that I was being difficult on
> > > purpose,
>
> > This is why I gave the logging example "library." It is not clear what
> > size, scope, and purpose of code you want to reuse and the criteria
> > keeps changing yet you still want an answer. If any size, scope and
> > purpose is sufficient then the logging example is sufficient. If the
> > size, scope and purpose matter even a bit then they must be specified
> > and you will get a much more useful answer.
>
> I'm sorry Peter, but if you continue to insist that what you provided
> was a realistic solution to my question (regardless of how ill-formed
> you may have felt it was)

No offense but it was ill formed and that has been the problem all
along. Other respondents tried to get you to specify your requirements
but it hasn't happened. I was just giving an extreme example that
satisfied your request perhaps prompting a refined request. Please
state the exact specifications of the type of code you would like to
reuse and for what purpose.


> I think it may be difficult for us to have
> a conversation. I noticed you put "library" in quotes, so maybe you
> sensed it was not a reasonable solution also.

It was intended to be obviously unreasonable. It is for debug logging
after all. That isn't even done in production code.


> If you honestly feel that you would consider creating a web site, for
> example, to offer that code to the public as a "library", then I
> apologize, but I seriously doubt that is the case.

You are right. I wouldn't.


> Do you now
> understand why I included "publicly available" as a criteria?

Your specs keep changing and several people have pointed to this
problem. Is a having a website the only way to be satisfactorily
public? Does having a website mean a library is better?


> Anyway, if any library/module authors who were proud of their code
> were reading any of these threads, I expect they would have mentioned
> their offerings by now, so we're probably beyond beating a dead horse
> at this point, I think it's probably a bloody pulp :)
>
> > When I've been involved with other online communities related to
> > libraries, I get a sense of "I don't want to learn JavaScript
>
> I believe you, and others, may have projected that attitude onto
> people who don't share it.

I was fresh meat and equally new to other communities and to
comp.lang.javascript. I don't have any personal connections to anyone
programming in JavaScript. I was relatively unbiased. That was the
impression I got especially in the Rails/Prototype community where
there is a movement to hide all JavaScript in Ruby wrappers.


> That's probably where the "straw man"
> arguments keep coming from - not from maliciousness, but from not
> bothering to actually understand where people are coming from and
> simply assuming.
>
> > Code reuse is an important topic.
>
> Do you reuse code from others? If so, what are the sources of code
> that you've found valuable.

comp.lang.javascript faq and faq notes
comp.lang.javascript archives
google.com search results
YUI and other libraries

All are just educational resources for me. After I understand the
problem I write my own version specific to my task with the API I
like.

The most important page I've read about doing browser scripting well
is

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

but I haven't used any of that code as is.


> > The fundamental libraries seem to be for events and Ajax. Really with
> > those two libraries you can build everything else quite easily. I
> > wrote my own event and Ajax libraries (roughly based on the YUI API)
> > and you can even find them available on the web.
>
> Well, why the heck didn't you mention those instead of the logger
> thing ?! :)

I was being an ass, making a mild joke and also a point to try to get
a better question from you so that you would get a more useful answer.


> What's the URL?

http://forkjavascript.org

It works for me in my work situation and the way I handle degradation
paths.


> > It has worked out
> > much better than using one of the big name libraries. I still receive
> > emails from the YUI and Prototype ticket systems for tickets I created
> > over a year and a half ago. I didn't have time to wait for that long.
> > I also don't have any of the bloat of features that I don't use and
> > don't even think are a good idea to use.
>
> If I end up writing a lot of code myself, that's fine, but it doesn't
> make sense to reinvent the wheel if you don't have to. I have to say
> the effort to have a dialog here has been much more than any other
> newsgroup. Discovering some valuable, time saving libraries for Common
> Lisp was straightforward.

Perhaps "valuable, time saving libraries" are readily available in the
Common Lisp world but not in the JavaScript world.


> > > Maybe there have been multiple "from scratch" posts because that
> > > phrase has a different meaning with different people. I think other
> > > people have been frustrated from this as well. I won't speak for Matt,
> > > but when I see "write everything from scratch", I think the author is
> > > referring to writing code themselves instead of utilizing preexisting
> > > code from other sources.
>
> > Using preexisting code probably means different things to different
> > people.
>
> Yes, but "preexisting code from other sources" should be pretty clear,
> even in this crowd, right? "preexisting" => "it has already been
> written"
> "from other sources" => "I didn't write it"

Somewhere communication has broken down. It seems you think you have
clearly stated your library specs. You've assumed people will imply
the same things you have implied in you requirements but that hasn't
appeared to be the case. What do you want? Do you need a large user
base for the library? Do you need tutorials and documentations? Do you
need code that works on IE4 or cell phones or only in Opera 9? Do you
want event and Ajax libraries or do you only need to be able to
validate form inputs? Do you need code that has a larger chance of
working in future browsers or browser you have not tested? Do you have
a perfectionist in you that just can't stand seeing bad practices in
code that works now but likely will cause you grief down the road?
Perhaps you are writing a website for lower income people or people in
the third world with very slow connections so download times matter
more? Are you writing as site for blind people? Perhaps you are
writing for an internal app behind a login? How much money do you have
for development and testing? Does a particular library style/syntax
appeal to you? Is your website mission critical like a banking site or
is it a hobby site? If a bug appears how quickly will you need it
fixed in the library code? How do you weight all these requirements?
Some of these requirements will automatically negate YUI, Dojo,
Prototype, jQuery etc. There are likely people on comp.lang.javascript
that work in a wide variety of these situations so their priorities
will vary from yours and impact their answers if left to implications.

If you like the answers you receive or not is a different story and
apparently so far you haven't liked them.

I don't think that many people in JavaScript/browser scripting are
pleased with the missing aggregation of knowledge. At least an
outstanding book should exist. Currently it takes a newcomer an
unreasonably long time to gather all the information. The really
knowledgeable developers are busy working which pays much more money
than book writing.

Right now what I would like the most is an example from Richard
Cornford about how he implements and documents his library style with
an interface having several implementations. It is quite clear after
his explanation but an example may show some subtle things he has
learned working with such a library system.

Peter

Brian Adkins

unread,
Oct 31, 2007, 1:12:50 AM10/31/07
to
On Oct 31, 12:32 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Oct 30, 8:26 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> It was intended to be obviously unreasonable.

Thank you for your honesty.

> > Do you reuse code from others? If so, what are the sources of code
> > that you've found valuable.
>

> YUI and other libraries

Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.

> I was being an ass

Agreed.

> Perhaps "valuable, time saving libraries" are readily available in the
> Common Lisp world but not in the JavaScript world.

Gee, do you think that's the question I've been vainly trying to get
answered? But Peter, how can you make that conjecture without a spec,
requirement or context? That's a joke - don't answer it.

> Somewhere communication has broken down.

Yes.

> It seems you think you have
> clearly stated your library specs.

Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.

> You've assumed people will imply
> the same things you have implied in you requirements but that hasn't
> appeared to be the case.

Wrong, and you know it, as you admitted with respect to your little
game with the logging code. You knew that was ridiculous, yet you
couldn't think of something that wasn't? Peter, you act as if the
question was so vague as to imply there were far too many answers to
post, and yet the only thing mentioned in hundreds of posting is that
YUI might be worth checking out. Imagine if I had provided a detailed
set of requirements - the options would have been narrowed from 1 to
0.

> Currently it takes a newcomer an
> unreasonably long time to gather all the information.

I wonder why that is? ;)


Doug Miller

unread,
Oct 31, 2007, 7:37:43 AM10/31/07
to
Well, sure, if you're silly enough to post it someplace where it can be
downloaded without paying for it first.

Peter Michaux

unread,
Oct 31, 2007, 8:24:37 AM10/31/07
to
On Oct 30, 10:12 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> On Oct 31, 12:32 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 30, 8:26 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > It was intended to be obviously unreasonable.
>
> Thank you for your honesty.
>
> > > Do you reuse code from others? If so, what are the sources of code
> > > that you've found valuable.
>
> > YUI and other libraries
>
> Care to name even one in addition to YUI. Don't worry about
> requirements, specs, contexts. Since YUI is the only one folks have
> offered up, I'm just curious if another exists. Even a small one
> that's used by more than a handful of people would be good.

I already offered mine and the code in the group's faq notes. Also
checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse. Google
will help you find them. I don't know if any of them will be helpful
with your task at hand.


> > It seems you think you have
> > clearly stated your library specs.
>
> Peter, only an idiot would think that I had clearly stated "library
> specs", or more importantly that it was my intention to do so, so I
> must assume that you consider me an idiot. There will be no Christmas
> card forthcoming.
>
> How can you miss something so simple? I am^H^Hwas simply trying to get
> a feel for which "preexisting code written by people other than me" is
> worthwhile to consider using in future projects before I reinvent the
> wheel myself. Does that make sense to you? It makes sense to others.
> Does it seem like a reasonable quest? It does to others.

But "reasonable scope" and "any scope" have both been part of the
requirements. Its been a moving target.

People are very reluctant to give such general recommendations. There
must be a reason for being so cautious.

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse. You can at least use reuse the code educationally.


> Really - ask some people at your workplace as a poll. This group is
> biased beyond hope at this point. Just ask them, "Hey, some guy on
> comp.lang.javascript asked whether there were any publicly available
> JavaScript libraries that were worthwhile to use. So he's an idiot,
> right? I mean, he didn't even provide a spec or set of requirements
> for that question! How can we possibly interpret that question without
> a spec. So, really, he's an idiot, right? There was no context to
> guides us or anything." Something like that. Let me know how it goes.
>
> > You've assumed people will imply
> > the same things you have implied in you requirements but that hasn't
> > appeared to be the case.
>
> Wrong, and you know it,

Actually I think that has been the problem.


> as you admitted with respect to your little
> game with the logging code. You knew that was ridiculous, yet you
> couldn't think of something that wasn't?

That is how difficult the question was.


> Peter, you act as if the
> question was so vague as to imply there were far too many answers to
> post, and yet the only thing mentioned in hundreds of posting is that
> YUI might be worth checking out.

Take something from that.


> Imagine if I had provided a detailed
> set of requirements - the options would have been narrowed from 1 to
> 0.

If you had said form validation then YUI would not have been
mentioned. If you said event libraries it might.


> > Currently it takes a newcomer an
> > unreasonably long time to gather all the information.
>
> I wonder why that is? ;)

When new, it is difficult to even know the questions to ask. That was
a big problem for me.

I don't know if it will help with your task I think you should use YUI
for a while.

Peter

beegee

unread,
Oct 31, 2007, 9:44:49 AM10/31/07
to
On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:

> I don't know if it will help with your task I think you should use YUI
> for a while.
>

I have been using YUI for almost two years. I use the Tree, Panel,
Container, Menu, Event modules and at times have used the Connection
(AJAX) module. They are all solid and do not obfuscate the language
like JQuery, Prototype etc. The documentation is good and the code is
so well written that tweaks to the library are easy to make. I have
used the datatable module for one project and have backed off a bit
because it is lacking in a few features that seem essential to me (the
ability to load from local XML for one).

There are two downsides to this library that I can see. One is that
if you are using many modules on a page, the load is slow although YUI
has an experimental Loader module that may help with this. The other
downside is that some of their releases have been backwardly
incompatible and though they provide extensive notes as to most of
these backward incompatibilities, it is a pain with a large site.

I have come to believe lately that there are no real helpful AJAX
libraries and that the task of cobbling together your own AJAX object
or set of functions is pretty easy and the best solution.

But hey, you want some real library nastiness, try creating javascript
proxies for .NET web services. We should all be grateful for
mootools,jquery,prototype,yui,dojo and on and on, excuse the incorrect
capitalization.

Bob

Brian Adkins

unread,
Oct 31, 2007, 10:43:54 AM10/31/07
to
On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:
> I already offered mine and the code in the group's faq notes.

I did bother to check http://www.jibbering.com/faq/ before posting and
didn't find anything. That site mentions faq_notes here:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

but I didn't see your code there, nor were you listed as a
contributor, so maybe there's another set of "group's faq notes"
somewhere?

> Also
> checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse.

Thanks

> It seems now you've made it concrete and want to know if there is
> *any* code at all worth reusing with no other requirements at all.

That's been that case for quite some time. I proceeded as follows:

1) it seems people here think all libraries suck
*therefore*
2) I wonder if there is *any* code that can be recommended

If the responses showed that there were many libraries worth looking
into, then I naturally would need to ask a more specific question, but
that has hardly been the case.

> There is almost an infinite amount of JavaScript code available. Use
> google to find code related to your task and evaluate the code if it
> is worth reuse.

Peter, I don't understand why you made this statement. The purpose in
asking a question such as the one I asked is to avoid spending an
"infinite" amount of time evaluating code, but instead to attempt to
gain from the experience of others. The value of the experience of
other people can range from harmful to helpful, but it can sometimes
narrow down the search to a feasible set of candidates nonetheless.

> That is how difficult the question was.

I'm still waiting for the workplace poll results ;)

Thomas 'PointedEars' Lahn

unread,
Oct 31, 2007, 11:20:50 AM10/31/07
to
beegee wrote:
> On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:
>> I don't know if it will help with your task I think you should use YUI
>> for a while.
>
> I have been using YUI for almost two years. I use the Tree, Panel,
> Container, Menu, Event modules and at times have used the Connection
> (AJAX) module. They are all solid and do not obfuscate the language
> like JQuery, Prototype etc. The documentation is good and the code is
> so well written that tweaks to the library are easy to make. I have
> used the datatable module for one project and have backed off a bit
> because it is lacking in a few features that seem essential to me (the
> ability to load from local XML for one).

The important question is: Could the UI features they provide generally
display without client-side script support, do they degrade gracefully?
If the answer to that is no, then they are not suited for general use.

> But hey, you want some real library nastiness, try creating javascript
> proxies for .NET web services.

That there is someone who does a (bad) thing even worse and therefore
the (bad) thing was good is a loser's argument, or IOW a logical fallacy.

> We should all be grateful for mootools,jquery,prototype,yui,dojo and
> on and on, excuse the incorrect capitalization.

No, "we" should not, with *maybe* the exception of YUI. And if you had
cared to consider the arguments already provided, you would know why.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Peter Michaux

unread,
Oct 31, 2007, 12:41:08 PM10/31/07
to
On Oct 31, 7:43 am, Brian Adkins <lojicdot...@gmail.com> wrote:
> On Oct 31, 8:24 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > I already offered mine and the code in the group's faq notes.
>
> I did bother to check http://www.jibbering.com/faq/ before posting and
> didn't find anything. That site mentions faq_notes here:http://www.jibbering.com/faq/faq_notes/faq_notes.html

There are many code snips on those pages and on the pages to which
they link. You have to at least want to see the code for which you
search. For example, the FAQ has three functions for trimming string
whitespace without using regular expressions.

function LTrim(str) {
for (var k=0; k<str.length && str.charAt(k)<=" " ; k++) ;
return str.substring(k,str.length);
}
function RTrim(str) {
for (var j=str.length-1; j>=0 && str.charAt(j)<=" " ; j--) ;
return str.substring(0,j+1);
}
function Trim(str) {
return LTrim(RTrim(str));
}


Perhaps you have a particular format in which you need to see the code
libraries you are after. That could be baggage you carry coming from
another programming language and development style. There is no
established CPAN or PEAR for JavaScript. There is an attempt called
JSAN but that hasn't gained much traction and likely has not been
evaluated by many regulars here so has not been even a candidate for
recommendation in this thread. The baggage you carry could prevent you
from finding what you are after.


> but I didn't see your code there, nor were you listed as a
> contributor, so maybe there's another set of "group's faq notes"
> somewhere?

There is only one set.

> > It seems now you've made it concrete and want to know if there is
> > *any* code at all worth reusing with no other requirements at all.

There is plenty in the group faq and faq notes. There is plenty in the
group archives. There is plenty on the web. There is plenty in the big
name libraries. It may not be in the finalized "library" format you
have been after at certain times in these threads but if you've
removed that requirement then there is plenty. It should be clear now
that there is not some ready made library that can be handed to the
newcomer that is "approved" for reuse in all situations. That is
either unfortunate or impossible.


> That's been that case for quite some time. I proceeded as follows:
>
> 1) it seems people here think all libraries suck

They don't. They do see many flaws in the big name libraries and
prefer to use their own libraries. Some people use their own libraries
as modules they use as is and release versions to themselves. Some
people use their libraries as cut and paste resources.


> *therefore*
> 2) I wonder if there is *any* code that can be recommended

I hope it is quite clear now that there is at least some code that can
be recommended and this question can die. The trim examples above are
enough to show there is some code that can be recommended.


> If the responses showed that there were many libraries worth looking
> into, then I naturally would need to ask a more specific question, but
> that has hardly been the case.
>
> > There is almost an infinite amount of JavaScript code available. Use
> > google to find code related to your task and evaluate the code if it
> > is worth reuse.
>
> Peter, I don't understand why you made this statement. The purpose in
> asking a question such as the one I asked is to avoid spending an
> "infinite" amount of time evaluating code

Just because there is an plethora of JavaScript on the web to evaluate
it doesn't mean you have to spend much time evaluating it. You can
look at the first few hits that google returns and that is usually
sufficient.


>, but instead to attempt to
> gain from the experience of others.

Much advice has been offered.


> The value of the experience of
> other people can range from harmful to helpful, but it can sometimes
> narrow down the search to a feasible set of candidates nonetheless.
>
> > That is how difficult the question was.
>
> I'm still waiting for the workplace poll results ;)

I'm not asking.

Peter

RobG

unread,
Oct 31, 2007, 3:35:45 PM10/31/07
to

I think your question was answered fairly quickly and thoroughly.
Peter pointed you to an existing thread, others chimed in with
opinions on major libraries within a couple of days and others
responded with their opinions of those libraries. Which goes back to
why you won't see them recommended here.

I suggest you lurk for awhile in news groups related to the libraries
you'd like to try and see if you like what you see.


> Really - ask some people at your workplace as a poll. This group is
> biased beyond hope at this point. Just ask them, "Hey, some guy on
> comp.lang.javascript asked whether there were any publicly available
> JavaScript libraries that were worthwhile to use. So he's an idiot,
> right? I mean, he didn't even provide a spec or set of requirements
> for that question! How can we possibly interpret that question without
> a spec. So, really, he's an idiot, right? There was no context to
> guides us or anything." Something like that. Let me know how it goes.

There is certainly an attitude that the standard of code in most
general libraries is not very high and that the time and effort
required to learn the library may be better spent writing a bespoke
framework. Those opinions will be supported by examples if you ask
(there are some in threads from your OP). So while you may not like
the attitude, there is a sound reason for the bias.

But don't be discouraged, the bottom line is that those who like and
use libraries are probably using news groups dedicated to those
libraries. That is because most libraries introduce their own API
that masks the underlying built-in javascript objects and methods and
the W3C DOM API, so it is a bit pointless asking questions in a
general javascript news group.

Those who are regulars here mostly don't use libraries because they
have decided not to (most probably because they don't like what's on
offer) and are therefore unlikely to recommend one.


--
Rob

David Mark

unread,
Oct 31, 2007, 6:17:54 PM10/31/07
to
On Oct 30, 9:00 pm, "tony.gurnick" <tony.gurn...@googlemail.com>
wrote:

> you could also argue that an "Ultimate Javascript Library" that I cant
> have is infinitley more useless than a badly coded, in-efficient
> library that I can have.

There is no such thing as an "Ultimate JavaScript Library." Clearly
you can't have what doesn't exist. However, as noted several times,
there are other options besides using code that is known to be lousy.

John Resig

unread,
Oct 31, 2007, 6:34:36 PM10/31/07
to
Yawwwwnnnnn.... this is, quite possibly, the most inane set of
ramblings set up by someone who has obviously never created a
JavaScript library of any kind, nor has used JavaScript code in any
sort of production environment.

I'll reply to your alleged critiques to the code below.

To start with, jQuery only supports the following browsers:
- IE 6+
- Firefox 2+
- Opera 9
- Safari 2+

Anything outside that jurisdiction is not guaranteed to work. But
considering that that selection is something like 99% of all browsers
(and considering that the selection of supported browsers is "good
enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's
safe to say that we've made a good choice.

> Hardly. It is woven into many important low-level functions. Here is
> a particularly stupid snippet from the get/setAttribute wrapper called
> attr:
>
> } else if ( jQuery.browser.msie && name == "style" )
>
> return jQuery.attr( elem.style, "cssText", value );
>
> Do you have any idea how many agents jQuery will identify as IE?

The ones we care about?

> Do
> you have any idea how trivial it is to properly feature detect IE's
> broken get/setAttribute functionality?


Pray tell! I must've missed the boolean property that tells me that
it's broken as all get out.

> Forget that for the moment, why is this function passing a style
> object to itself?

The .attr() function can be a little futzy (it's long due for a
rewrite). For now, it's written this way to keep all attribute/css
special-case logic contained to a single location.

> if ( jQuery.browser.msie && /href|src/.test(name) && !
> jQuery.isXMLDoc(elem) )
> return elem.getAttribute( name, 2 );
>
> Just what sort of XML document runs script in IE? Certainly not an
> XHTML document. Realize that this absurd line of code is evaluated
> every time jQuery looks at an element's attribute.


Huh? That gets the interpreted value of an attribute, only in IE, and
only if it isn't within an XML document (and only for the href and src
attributes - which are the ones that have the specific URL-
interpretation problems).

> Then there is this gem:
>
> // Certain attributes only work when accessed via the old DOM 0 way
> if ( fix[name] ) {
> if ( value != undefined ) elem[fix[name]] = value;
> return elem[fix[name]];
>
> This demonstrates a stunning lack of understanding of attributes (and
> IE's problems with them.) Where's the sniff (or feature detect) for
> IE? This IE-specific workaround runs on everything.


This has nothing to do with being IE-specific, or not. Look at the fix
object - it contains a number of properties (both CSS and regular
attribute) that need to be re-written or defer to another attribute.
(For example, this is also used to fix cases where a user
types .attr("readonly") instead of .attr("readOnly")).

> Still in the same function:
>
> else if ( value == undefined && jQuery.browser.msie &&
> jQuery.nodeName(elem, "form") && (name == "action" || name ==
> "method") )
> return elem.getAttributeNode(name).nodeValue;
>
> No comment for this magic spell, so there is no telling what it is
> trying to do.

The action and method attributes can be overwritten in IE, like so:
<form>
<input type="text" id="action"/>
</form>

Thus, this code handles that case and gets the correct value, special.

> One thing is certain. This code will run on lots of
> non-IE agents.


It only runs on the ones that we care about - but apparently this
mythical, ultra-popular, StrawMan v1.0 is all the rage these days.

> if ( value != undefined ) {
> if ( name == "type" && jQuery.nodeName(elem,"input") &&
> elem.parentNode )
> throw "type property can't be changed";
> elem.setAttribute( name, value );
> }
>
> Another example of confusing attributes with properties. This is also
> an IE-specific workaround with no sniff (or feature detect.)


This was done completely intentionally - we don't support dynamically
changing the type attribute on input elements, since it causes an
exception to be thrown in IE (we would rather have a consistent code
base, across all browsers that we support, than have problems arise
later for users).

> And just when you think you have seen every conceivable miscue (all in
> a single function mind you.)
>
> if ( name == "opacity" && jQuery.browser.msie ) {
> if ( value != undefined ) {
> // IE has trouble with opacity if it does not have layout
> // Force it by setting the zoom level
> elem.zoom = 1;
>
> What in God's name do opacity (and other styles) have to do with
> attributes?


See above.

> That's enough of that function. Keep in mind that the code therein is
> called constantly by jQuery. Unfortunately for those who rely on
> jQuery, it is error-prone, confused, inefficient and convoluted.

Error-prone? Doubtful. Where's your test suite-backed attribute/css
manipulation code, I'd love to see it!

Inefficient, possibly. We've already made a number of optimizations
wherever possible - but many of the checks can't be circumvented.

Convoluted - sure. As I mentioned before, it's due for a re-write.

> The
> design (and documentation) is of such poor quality that it is an
> assault on the senses of anyone unfortunate enough to glance at it.


Sigh. Where's your ultra-documented, totally-awesome, perfect-in-every-
way JavaScript library? That's what I thought - you don't have one,
nor does one exist.

> And speaking of opacity. In the curCSS function:
>
> if (prop == "opacity" && jQuery.browser.msie) {
> ret = jQuery.attr(elem.style, "opacity");
> return ret == "" ? "1" : ret;
>
> }
>
> So any agent that identifies as IE and will be re-routed to the attr
> function, which has nothing to do with style, but does contain more
> sniffing and some IE-specific DirectX twiddling, which will have no
> (positive) effect on non-IE agents.


See above - it works for everything that we support. We make no
illusions as to otherwise.

> It would seem that querying style rules would be almost as critical to
> querying attributes in a library like jQuery. Yet, in this same
> function you find this gem:
>
> // A helper method for determining if an element's values are broken
> function color(a){
> if ( !jQuery.browser.safari )
> return false;
>
> var ret = document.defaultView.getComputedStyle(a,null);
> return !ret || ret.getPropertyValue("color") == "";
>
> }
>
> This is the author's idea of a feature detect for getComputedStyle.
> Why Safari-like browsers are excluded is a mystery. After that
> inauspicious start, it blunders into the defaultView, getComputedStyle
> and getPropertyValue properties with the impunity of somebody who
> hasn't got a clue as to what they are doing.


Wow. WowWowWow. Spoken like a true babe! It's damn simple to detect it
in all browsers but Safari. In Safari 2, in an element that is
display: none, getComputedStyle() returns null. In Safari 3, it
returns a style object, but within with all values return "" (which
may, or may not, be a valid return value - it's impossible to tell!).
Thus, you have to check for the existence of the computed color value
(which will always exist) and if it's empty, then we're inside a
corrupted element.

> It goes on and on. From the clean function:
>
> if ( jQuery.browser.msie ) { // String was a <table>, *may* have
> spurious <tbody>
> if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
> tb = div.firstChild && div.firstChild.childNodes;
>
> div *may* have a firstChild property.


Yes? Your point? IE can, sometimes, not auto-generate a <tbody>
wrapper (when there's no contents to the table). This verifies when a
<table></table> is passed in makes sure that a tbody is constructed.
Again, everything here is backed by a test suite.

> >From the same function:
>
> // IE can't serialize <link> and <script> tags normally
> jQuery.browser.msie && [1, "div<div>", "</div>"]
>
> You have to keep in mind while reading this stuff that
> jQuery.browser.msie is meaningless on the Web. It isn't of much use
> on an Intranet either, unless you use the same version and
> configuration of IE forever.


Huh? Show me a drastically improved version of IE and I'll show you an
updated copy of jQuery.

> >From merge:
>
> // Also, we need to make sure that the correct elements are being
> returned
> // (IE returns comment nodes in a '*' query)
> if ( jQuery.browser.msie ) {
> for ( var i = 0; second[i]; i++ )
> if ( second[i].nodeType != 8 )
> first.push(second[i]);
> } else
>
> Same problem different function. What if some agent that doesn't
> identify as IE has the same problem?

These browsers that you keep talking about must be amazing! They're,
quite literally, everywhere! At every turn there's a browser that we
support that also claims to be IE, but it isn't IE! What have we been
doing wrong all this time? How could we have been so naive?

> Also note how hard it is to
> follow with all of the missing brackets.


*shrug*

> More madness:
>
> var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";
>
> Obviously you should just check (or set) them both. What happens if
> IE8 switches gears on this? And what of an IE-spoofing agent that
> doesn't use "styleFloat?"


The same argument, over and over, is getting incredibly old. Where's
your ultra-popular library that is 100% future proof?

Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.

> // Check to see if the W3C box model is being used
> boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",
>
> That could have far-reaching implications. A quick search found it in
> an attempt to measure the viewport:
>
> return this[0] == window ?
> jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
> Math.max(document.documentElement["client" + name],
> document.body["client" + name]) ||
> document.body["client" + name] :
> this[0] == document ?
> Math.max( document.body["scroll" + name], document.body["offset" +
> name] ) :
> h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
> this.css( n, h.constructor == String ? h : h + "px" );
>
> I characterized this as a "million monkey" project earlier and I want
> to take a moment to apologize to monkeys everywhere. I think even a
> single monkey could write a better solution to this very common
> problem. Certainly there are many better solutions floating around on
> the Internet.

Certainly! They are, literally, everywhere! I mean,