Javascript Libraries... which one?

[Neo Geshel]

I have been looking into Javascript libraries for the last week or two
here, and there are certainly a lot of options out there.

http://www.prototypejs.org/
http://mootools.net/
http://mochikit.com/
http://script.aculo.us/

And then there are even add-ons to some of these, such as:

http://moofx.mad4milk.net/

I am just curious, is there a site out there that has examined all of
these libraries, and has made a feature and performance comparison among
them? Javascript isn’t my sharpest tool, by far, and I feel a little
overwhelmed examining the source code for these libraries.

I am looking to add a library to my repertoire of tools so that I can
enhance already existing content (I have no intention of making any
content JS-only capable!!), and as such, I am seeking some opinions or
actual rigorous examinations on which library might provide the best
spread of features.

As for my needs, I have no real intentions of supporting IE or Netscape
less than version 6, I am more interested in site effects than AJAX
(although this will probably change in the near future), and I am just
looking for any personal opinions about the Libraries. Such as bad
experiences, Library shortcomings, potential conflicts, etc.. Anything
constructive that you might be able to provide, that is.

TIA
...Geshel
--
*********************************************************************
My return e-mail address is an automatically monitored spam honeypot.
Do not send e-mail there unless you wish to be reported as a spammer.
Please send all e-mail to my first name at my last name dot org, with
a subject-line of “NEWSGROUP REPLY FOR NEO GESHEL†(all uppercase).
*********************************************************************

 

[Isaac Schlueter]

I have been looking into Javascript libraries for the last week or two
here, and there are certainly a lot of options out there.

http://www.prototypejs.org/
http://mootools.net/
http://mochikit.com/
http://script.aculo.us/

You forgot http://developer.yahoo.com/yui/

I'm partial to the Yahoo lib for obvious reasons (I work for y! games,
so I may be a bit biased), but I've found it to be a very handy
library. Unlike prototype and (to a lesser extent) scriptaculous and
jQuery, it doesn't try to rewrite the syntax of the language, but just
extend it and sprinkle some sugar here and there. The yui connection
lib is one of the few that doesn't leak memory.

--i

 

[Neo Geshel]

You forgot http://developer.yahoo.com/yui/

I'm partial to the Yahoo lib for obvious reasons (I work for y! games,
so I may be a bit biased), but I've found it to be a very handy
library. Unlike prototype and (to a lesser extent) scriptaculous and
jQuery, it doesn't try to rewrite the syntax of the language, but just
extend it and sprinkle some sugar here and there. The yui connection
lib is one of the few that doesn't leak memory.

--i

Thanks.

I haven’t had much of a chance to take a close look at it... doesit
have a getElementsByClassName function?

Cheers,
...Geshel
--
*********************************************************************
My return e-mail address is an automatically monitored spam honeypot.
Do not send e-mail there unless you wish to be reported as a spammer.
Please send all e-mail to my first name at my last name dot org, with
a subject-line of “NEWSGROUP REPLY FOR NEO GESHEL†(all uppercase).
*********************************************************************

 

[Isaac Schlueter]

I haven't had much of a chance to take a close look at it... does it
have a getElementsByClassName function?

http://developer.yahoo.com/yui/docs/YAHOO.util.Dom.html#getElementsByClassName

There's also a generalized getElementsBy that takes a function as the
first argument.

--i

 

[Matt Kruse]

http://www.prototypejs.org/
http://mootools.net/
http://mochikit.com/
http://script.aculo.us/
Add:
http://www.jquery.com/
http://developer.yahoo.com/yui/


I am just curious, is there a site out there that has examined all of
these libraries, and has made a feature and performance comparison
among them?

There are a number of them, and most of them are not a good analysis of the
situation. For example, google this:
http://www.google.com/search?q=javascript+library+roundup

Javascript isn't my sharpest tool, by far, and I feel a
little overwhelmed examining the source code for these libraries.

They are often written in a way to reduce the download size, even before
packing. And they take advantage of some of the lesser-known features of
Javascript. So they can indeed be difficult to understand, but if you have a
decent knowledge of js many of them are actually quite interesting to look
at.

I am seeking some opinions or
actual rigorous examinations on which library might provide the best
spread of features.

I haven't done a "rigorous" examination of the libraries, but I will offer
some opinions. As my experience and need for features may be very different
than yours, not all my points may be important to you.

Prototype:
It has been criticized in the past because it extended Object, which is a
javascript no-no. This has been fixed in version 1.5. The main gripes
against Prototype are that it tries to make JS into a class-based language
that it is not, and in doing so makes the syntax more confusing than it
would have been written in 'plain' JS. It is not very cross-browser or
standards-compliant. It is popular because it was one of the earlier
frameworks available, but I think it is reducing in popularity. It is used
heavily by the Ruby on Rails crowd and it tries to be Ruby-like. I would not
recommend Prototype. (Although your url is new to me - I didn't know it got
a new site for the version 1.5 launch).

MooTools:
This lib takes the approach of extending HTMLElement, which I particularly
like. It has a lot of functionality but it is broken up into many files and
can be hard to always know which files you need. In a recent discussion on
their support forum which I started, I was very much NOT impressed with the
team of developers. They had an elitist, unprofessional attitude. This led
me to not go with MooTools, even though technically their stuff is pretty
good. I found some glaring problems in the most recent release, although
some have been fixed in the development version. This lib was originally
based on Prototype and takes a class-based approach which is still not very
"JS-like".

MochiKit:
I haven't actually looked at this one at all. I have no idea.

Yahoo YUI:
This feels like a very "classical" library, in that the code is contained in
deep namespaces, it is organized by module, it is very verbose, and tries to
be a "do everything" library. I looked at it, but personally it never felt
right to me. Plus there were some glaring logic problems in some of the code
(don't know if they are fixed) so I wasn't sure how rigorously they tested.
I don't like their idea of "browser grades" and they seem to be keen on
browser detection. Nevertheless, it's very mature, extremely well
documented, has a lot of examples, and has a lot of support. Plus the power
of Y! behind it means it will probably still be relevant for years to come.

jQuery:
The popularity of this library seems to be growing, the documentation is
good, the examples are good, and the user community is fantastic. Rather
than extending HTMLElement, it uses the approach of a custom object that
holds on to an array of reference objects and can manipulate them. This
hopefully avoids memory leaks. It's small (19kb compressed) and packs in a
lot of features, they key being the ability to select elements by CSS
selectors. So if you want to do something with all DIVs on the page with
class "myclass" you just do $('div.myclass').doSomething(). The user
interface is handled by Interface Elements, which mirrors most of what
Moo.fx does. I ended up standardizing on this library as the basis for a
number of upcoming projects because the documentation is good, the user
community is great, the extensibility is great, the footprint is small, and
the plugins are growing. I plan to convert some of my own code into
jQuery-compatible plugins and to continue supporting this library in the
future.

Hope that helps!

 

[Douglas Crockford]

Prototype:
It has been criticized in the past because it extended Object, which is a
javascript no-no.

The problem with augmenting Object is that it causes incompetent programs to
break. I think the solution is to write competent programs, but I seem to be in
the minority. Also see http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

 

[Peter Michaux]

The problem with augmenting Object is that it causes incompetent programs to
break. I think the solution is to write competent programs, but I seem to be in
the minority. Also seehttp://yuiblog.com/blog/2006/09/26/for-in-intrigue/

But are you right that the hasOwnProperty() is a complete solution?

<URL: http://groups.google.com/group/comp.lang.javascript/msg/775698102c01a47e>

Peter

 

[Matt Kruse]

The problem with augmenting Object is that it causes incompetent
programs to break. I think the solution is to write competent
programs, but I seem to be in the minority. Also see
http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

Your 'solution' starts out with limiting your test scope to make the desired
result easier to achieve:
"In all of the A Grade browsers ..." (Y!'s browser grading always rubs me
the wrong way)

What about older browsers? Using your approach of filtering out functions is
not good at all, since creating a method on an object is perfectly
acceptable and will work fine in older browsers. Other valid observations
appear in the comments to the article.

Unless you can identify a "defensive" solution that works in every case,
then I still think the recommendation stands to not augment Object. In
reality, there is no convincing reason to do so anyway.

 

[Douglas Crockford]

Your 'solution' starts out with limiting your test scope to make the desired
result easier to achieve:
"In all of the A Grade browsers ..." (Y!'s browser grading always rubs me
the wrong way)

What about older browsers? Using your approach of filtering out functions is
not good at all, since creating a method on an object is perfectly
acceptable and will work fine in older browsers. Other valid observations
appear in the comments to the article.

Unless you can identify a "defensive" solution that works in every case,
then I still think the recommendation stands to not augment Object. In
reality, there is no convincing reason to do so anyway.

Had you read a little farther, you would have seen that the typeof function test
works in the antique browsers. It also works in applications which dredge the
prototype chain intentionally.

If you do not program defensively, then if your code has to run with other
people's code (which is common with libraries and mashups) then your code will
fail. In this case, your code fails simply because the other code exists. Useful
code should never be that fragile. And whether you understand it or not, there
are good reasons to augment Object.

http://javascript.crockford.com/

 

[Matt Kruse]

Had you read a little farther, you would have seen that the typeof
function test works in the antique browsers.

Of course it does, but it also eliminates valid properties of an object
which happen to be functions. This isn't desireable, is it?

whether you understand it or not, there are good reasons to augment
Object.

I know it's useful, but it can also be avoided.

 

[Peter Michaux]

Had you read a little farther, you would have seen that the typeof function test
works in the antique browsers. It also works in applications which dredge the
prototype chain intentionally.

If you do not program defensively, then if your code has to run with other
people's code (which is common with libraries and mashups) then your code will
fail. In this case, your code fails simply because the other code exists. Useful
code should never be that fragile. And whether you understand it or not, there
are good reasons to augment Object.

http://javascript.crockford.com/

Don't you think that these random mashups are a bit of a pipe dream?
JavaScript has conflicting abilities (for-in vs. Object.prototype, for
example), inevitability some programmers will value one option over
the another, and programmer abilities and knowledge very widely. Taken
together don't you think it is impossible to code defensively for all
styles of JavaScript?

I already gave an example in this thread of where the for-in problem
could burn someone if they don't know that an object is created using
inheritance.

Another example: in JavaScript it is necessary to use the global name
space to do anything substantial. We can limit the use to just one
symbol (eg. YAHOO). However the authors of two other parts of our
mashup may not have been so disciplined or valued the pseudo-namespace
style. In this case those two authors may have symbols clobbering each
other. So for mashups to work a certain agreed upon subset of
JavaScript's abilities need to be used with discipline.

Rules like don't augment Object.prototype and use a pseudo-namespace
do help insure two pieces of code work together. These rules are ways
to stay out of the grey area so that other people who don't even need
to code defensively. Not augmenting Object.prototype is already a well
accepted rule in libraries.

Peter

 

[Neo Geshel]

There are a number of them, and most of them are not a good analysis ofthe
situation. For example, google this:
http://www.google.com/search?q=javascript+library+roundup


They are often written in a way to reduce the download size, even before
packing. And they take advantage of some of the lesser-known features of
Javascript. So they can indeed be difficult to understand, but if you have a
decent knowledge of js many of them are actually quite interesting to look
at.


I haven't done a "rigorous" examination of the libraries, but I will offer
some opinions. As my experience and need for features may be very different
than yours, not all my points may be important to you.

Prototype:
It has been criticized in the past because it extended Object, which isa
javascript no-no. This has been fixed in version 1.5. The main gripes
against Prototype are that it tries to make JS into a class-based language
that it is not, and in doing so makes the syntax more confusing than it
would have been written in 'plain' JS. It is not very cross-browser or
standards-compliant. It is popular because it was one of the earlier
frameworks available, but I think it is reducing in popularity. It is used
heavily by the Ruby on Rails crowd and it tries to be Ruby-like. I would not
recommend Prototype. (Although your url is new to me - I didn't know itgot
a new site for the version 1.5 launch).

MooTools:
This lib takes the approach of extending HTMLElement, which I particularly
like. It has a lot of functionality but it is broken up into many filesand
can be hard to always know which files you need. In a recent discussionon
their support forum which I started, I was very much NOT impressed withthe
team of developers. They had an elitist, unprofessional attitude. This led
me to not go with MooTools, even though technically their stuff is pretty
good. I found some glaring problems in the most recent release, although
some have been fixed in the development version. This lib was originally
based on Prototype and takes a class-based approach which is still not very
"JS-like".

MochiKit:
I haven't actually looked at this one at all. I have no idea.

Yahoo YUI:
This feels like a very "classical" library, in that the code is contained in
deep namespaces, it is organized by module, it is very verbose, and tries to
be a "do everything" library. I looked at it, but personally it never felt
right to me. Plus there were some glaring logic problems in some of thecode
(don't know if they are fixed) so I wasn't sure how rigorously they tested.
I don't like their idea of "browser grades" and they seem to be keen on
browser detection. Nevertheless, it's very mature, extremely well
documented, has a lot of examples, and has a lot of support. Plus the power
of Y! behind it means it will probably still be relevant for years to come.

jQuery:
The popularity of this library seems to be growing, the documentation is
good, the examples are good, and the user community is fantastic. Rather
than extending HTMLElement, it uses the approach of a custom object that
holds on to an array of reference objects and can manipulate them. This
hopefully avoids memory leaks. It's small (19kb compressed) and packs in a
lot of features, they key being the ability to select elements by CSS
selectors. So if you want to do something with all DIVs on the page with
class "myclass" you just do $('div.myclass').doSomething(). The user
interface is handled by Interface Elements, which mirrors most of what
Moo.fx does. I ended up standardizing on this library as the basis for a
number of upcoming projects because the documentation is good, the user
community is great, the extensibility is great, the footprint is small,and
the plugins are growing. I plan to convert some of my own code into
jQuery-compatible plugins and to continue supporting this library in the
future.

Hope that helps!

Wow. That certainly does help!!

Based on your opinions, I will certainly be looking further into the
Yahoo YUI and jQuery.

I guess you haven’t taken a closer look at script.aculo.us, eh?

Thanks!
...Geshel
--
***********************************************************************
My return e-mail address is an automatically monitored spam honeypot.
Do not send e-mail there unless you wish to be reported as a spammer.
Please send all e-mail to my first name at my last name dot org, with
a subject-line of “NEWSGROUP REPLY FOR NEO GESHEL†(alluppercase).
***********************************************************************

 

[-Lost]

There are a number of them, and most of them are not a good analysis of the situation.
For example, google this:
http://www.google.com/search?q=javascript+library+roundup


They are often written in a way to reduce the download size, even before packing. And
they take advantage of some of the lesser-known features of Javascript. So they can
indeed be difficult to understand, but if you have a decent knowledge of js many of them
are actually quite interesting to look at.


I haven't done a "rigorous" examination of the libraries, but I will offer some
opinions. As my experience and need for features may be very different than yours, not
all my points may be important to you.

Prototype:
It has been criticized in the past because it extended Object, which is a javascript
no-no. This has been fixed in version 1.5. The main gripes against Prototype are that it
tries to make JS into a class-based language that it is not, and in doing so makes the
syntax more confusing than it would have been written in 'plain' JS. It is not very
cross-browser or standards-compliant. It is popular because it was one of the earlier
frameworks available, but I think it is reducing in popularity. It is used heavily by
the Ruby on Rails crowd and it tries to be Ruby-like. I would not recommend Prototype.
(Although your url is new to me - I didn't know it got a new site for the version 1.5
launch).

Prototype is horrible. *Period*. Especially if you are unfamiliar with JavaScript,
prototype will make you go crazy.

MooTools:
This lib takes the approach of extending HTMLElement, which I particularly like. It has
a lot of functionality but it is broken up into many files and can be hard to always
know which files you need. In a recent discussion on their support forum which I
started, I was very much NOT impressed with the team of developers. They had an elitist,
unprofessional attitude. This led me to not go with MooTools, even though technically
their stuff is pretty good. I found some glaring problems in the most recent release,
although some have been fixed in the development version. This lib was originally based
on Prototype and takes a class-based approach which is still not very "JS-like".

Some of its functions are based on those found in prototype.js, which immediately tells me
to avoid it like the plague. I would be interested in seeing *which* functions in
particular they adopted though.

http://snook.ca/archives/javascript/javascript_effe/

....mentions a streamlined version of the prototype.js (no clue as to its validity or
usefulness).

MochiKit:
I haven't actually looked at this one at all. I have no idea.

From a quick glance, I like MochiKit. It breaks down several of the most popular
"must-haves" and presents them in small modular components. As to the strength of the
code, I cannot attest.

I can say that the script used in the distribution area makes Firefox gag.

Yahoo YUI:
This feels like a very "classical" library, in that the code is contained in deep
namespaces, it is organized by module, it is very verbose, and tries to be a "do
everything" library. I looked at it, but personally it never felt right to me. Plus
there were some glaring logic problems in some of the code (don't know if they are
fixed) so I wasn't sure how rigorously they tested. I don't like their idea of "browser
grades" and they seem to be keen on browser detection. Nevertheless, it's very mature,
extremely well documented, has a lot of examples, and has a lot of support. Plus the
power of Y! behind it means it will probably still be relevant for years to come.

Sadly this will always be more popular than it deserves. Not that it is not an amazing
library (just look at the developers maintaining it), I am just saying, anything with this
much press and a halfway stable lifetime is going to stay in the forefront.

The connection manager is the best I have seen, but of course nowhere near as simple as
Kruse's "AjaxRequest Library" or with the lite-weight simplicity of Michaux's "Fork."

jQuery:
The popularity of this library seems to be growing, the documentation is good, the
examples are good, and the user community is fantastic. Rather than extending
HTMLElement, it uses the approach of a custom object that holds on to an array of
reference objects and can manipulate them. This hopefully avoids memory leaks. It's
small (19kb compressed) and packs in a lot of features, they key being the ability to
select elements by CSS selectors. So if you want to do something with all DIVs on the
page with class "myclass" you just do $('div.myclass').doSomething(). The user interface
is handled by Interface Elements, which mirrors most of what Moo.fx does. I ended up
standardizing on this library as the basis for a number of upcoming projects because the
documentation is good, the user community is great, the extensibility is great, the
footprint is small, and the plugins are growing. I plan to convert some of my own code
into jQuery-compatible plugins and to continue supporting this library in the future.

I have to agree, jQuery is fairly fantastic. One of the things I like most is the
"versatile selector expressions to traverse to an element."

http://docs.jquery.com/Tutorials:How_to_Get_Anything_You_Want

On a side note, unless you are actually familiar with JavaScript and do not mind wading
through API and tutorials, you will not like jQuery.

The subtleties of page-wide things like:

$('a').click(function() { ... }); ...will make little to no sense without applying
selector expressions to modify individual links (or generic ifs).

All in all, I highly recommend:

jQuery (actual effects library)
Light Box (image specific)
FAT (fade anything technique)

And lastly, a little known effects library that is simply *pimp in my opinion is:

http://www.devpro.it/bytefx/

*It is super-small, super-fast, works in a lot of current browsers, and is *simple*.

-Lost

 

[Ian Collins]

I have been looking into Javascript libraries for the last week or two
here, and there are certainly a lot of options out there.

http://www.prototypejs.org/
http://mootools.net/
http://mochikit.com/
http://script.aculo.us/

You may also like to check out

http://dojotoolkit.org/

Which, while large, has a high gem to turd ratio. I use their rpc and
event libraries.

The documentation is a bit patchy (typical for an open source project)
but of good quality and there are plenty of unit tests to act as
examples. The support mail list is very active.

 

[-Lost]

You may also like to check out

http://dojotoolkit.org/

Which, while large, has a high gem to turd ratio. I use their rpc and
event libraries.

Hehe... please... tell me... what does "high gem to turd ratio" mean?

And "large" is an understatement. 4.5 Megabytes of download for a "javascript toolkit" is
*immense* or *gigantic* at best. I am not knocking it though, dojo is *awesome* and the
actual script itself is a semi-whopping 150 Kilobytes.

The documentation is a bit patchy (typical for an open source project)
but of good quality and there are plenty of unit tests to act as
examples. The support mail list is very active.

Verrrry true. http://manual.dojotoolkit.org/index.html

-Lost

 

[Ian Collins]

Hehe... please... tell me... what does "high gem to turd ratio" mean?

Gem: A crystalline rock that can be cut and polished for jewelry.
Turd: Vulgar. A piece of excrement.

 

[-Lost]

Gem: A crystalline rock that can be cut and polished for jewelry.
Turd: Vulgar. A piece of excrement.

OK, I will continue to play along... (even though you did not answer what was asked).

So, you are saying Dojo (and or its routines) starts out great and turns to shite?

-Lost

 

[Ian Collins]

OK, I will continue to play along... (even though you did not answer what was asked).

So, you are saying Dojo (and or its routines) starts out great and turns to shite?

No, I'm saying the ratio of good bits to bad bits favours the good.

 

[-Lost]

No, I'm saying the ratio of good bits to bad bits favours the good.

Aaaah, OK! I thought you were saying "gem TO turd", I simply misconstrued that.

-Lost

 

[Neo Geshel]

OK, I will continue to play along... (even though you did not answer what was asked).

So, you are saying Dojo (and or its routines) starts out great and turns to shite?

-Lost

Gem to turd ratio: Similar to signal-to-noise ratio, just a wee bit more
colourful. =)

In other words, the ratio of useful stuff (the Gems) to superfluous
turd-y material that, IYO, could just as well have been dropped.

Cheers,
...Geshel
--
***********************************************************************
My return e-mail address is an automatically monitored spam honeypot.
Do not send e-mail there unless you wish to be reported as a spammer.
Please send all e-mail to my first name at my last name dot org, with
a subject-line of “NEWSGROUP REPLY FOR NEO GESHEL†(alluppercase).
***********************************************************************