Javascript Library

[shapper]

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]

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

 

[Peter Michaux]

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...

<URL: http://groups.google.com/group/comp...a42f3f7647f/7913289a7a41be97#7913289a7a41be97>

Peter

 

[Brian Adkins]

Until further notice: yours.

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

 

[David Mark]

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

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]

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
powerful, compact, easy to understand, and has an active support
community.

Matt Kruse

 

[David Mark]

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]

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]

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?

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.

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.

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]

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.

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.

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?

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?

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?

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.

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?

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]

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.

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++ )
if ( second.nodeType != 8 )
first.push(second);
} 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 );
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.

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.

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.

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.

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'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.

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.

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.

#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.

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]

On Mon, 29 Oct 2007 14:42:48 -0700, in comp.lang.javascript David Mark
<[email protected]>

Thank you for the insightful review of jQuery.
Could you please tell me where I can get a copy of your js library?
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------

 

[Evertjan.]

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]

 

[Douglas Crockford]

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]

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]

@gmail.com>


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.

 

[Matt Kruse]

[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.

Really?

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

 

[David Mark]

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]

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]

Why not?

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

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

Why would you care?