Javascript Libraries... which one?

Discussion in 'Javascript' started by Neo Geshel, Feb 16, 2007.

  1. Neo Geshel

    Neo Geshel Guest

    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).
    *********************************************************************
     
    Neo Geshel, Feb 16, 2007
    #1
    1. Advertising

  2. On Feb 16, 10:47 am, Neo Geshel <> wrote:
    > 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
     
    Isaac Schlueter, Feb 16, 2007
    #2
    1. Advertising

  3. Neo Geshel

    Neo Geshel Guest

    Isaac Schlueter wrote:
    > On Feb 16, 10:47 am, Neo Geshel <> wrote:
    >> 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
    >

    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).
    *********************************************************************
     
    Neo Geshel, Feb 17, 2007
    #3
  4. On Feb 16, 4:42 pm, Neo Geshel <> wrote:
    > Isaac Schlueter wrote:
    > >
    > > You forgothttp://developer.yahoo.com/yui/;)

    >
    > 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
     
    Isaac Schlueter, Feb 17, 2007
    #4
  5. Neo Geshel

    Matt Kruse Guest

    Neo Geshel wrote:
    > 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!

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Feb 17, 2007
    #5
  6. Matt Kruse wrote:

    > 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/
     
    Douglas Crockford, Feb 17, 2007
    #6
  7. On Feb 16, 8:37 pm, Douglas Crockford <> wrote:
    > Matt Kruse wrote:
    > > 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 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
     
    Peter Michaux, Feb 17, 2007
    #7
  8. Neo Geshel

    Matt Kruse Guest

    Douglas Crockford wrote:
    > 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.

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Feb 17, 2007
    #8
  9. Matt Kruse wrote:
    > Douglas Crockford wrote:
    >> 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.


    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/
     
    Douglas Crockford, Feb 17, 2007
    #9
  10. Neo Geshel

    Matt Kruse Guest

    Douglas Crockford wrote:
    > 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.

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Feb 17, 2007
    #10
  11. On Feb 17, 1:38 am, Douglas Crockford <> wrote:
    > Matt Kruse wrote:
    > > Douglas Crockford wrote:
    > >> 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.

    >
    > 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
     
    Peter Michaux, Feb 17, 2007
    #11
  12. Neo Geshel

    Neo Geshel Guest

    Matt Kruse wrote:
    > Neo Geshel wrote:
    >> 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 ofthe
    > 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 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).
    ***********************************************************************
     
    Neo Geshel, Feb 17, 2007
    #12
  13. Neo Geshel

    -Lost Guest

    "Matt Kruse" <> wrote in message
    news:...
    > Neo Geshel wrote:
    >> 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).


    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
     
    -Lost, Feb 17, 2007
    #13
  14. Neo Geshel

    Ian Collins Guest

    Neo Geshel wrote:
    > 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.

    --
    Ian Collins.
     
    Ian Collins, Feb 17, 2007
    #14
  15. Neo Geshel

    -Lost Guest

    "Ian Collins" <> wrote in message
    news:...
    > Neo Geshel wrote:
    >> 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.


    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
     
    -Lost, Feb 18, 2007
    #15
  16. Neo Geshel

    Ian Collins Guest

    -Lost wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >>
    >>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?
    >

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

    --
    Ian Collins.
     
    Ian Collins, Feb 18, 2007
    #16
  17. Neo Geshel

    -Lost Guest

    "Ian Collins" <> wrote in message
    news:...
    > -Lost wrote:
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>>
    >>>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?
    >>

    > 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
     
    -Lost, Feb 18, 2007
    #17
  18. Neo Geshel

    Ian Collins Guest

    -Lost wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >
    >>-Lost wrote:
    >>
    >>>"Ian Collins" <> wrote in message
    >>>news:...
    >>>
    >>>>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?
    >>>

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

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

    --
    Ian Collins.
     
    Ian Collins, Feb 18, 2007
    #18
  19. Neo Geshel

    -Lost Guest

    "Ian Collins" <> wrote in message
    news:...
    > -Lost wrote:
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>
    >>>-Lost wrote:
    >>>
    >>>>"Ian Collins" <> wrote in message
    >>>>news:...
    >>>>
    >>>>>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?
    >>>>
    >>>
    >>>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?
    >>

    > 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
     
    -Lost, Feb 18, 2007
    #19
  20. Neo Geshel

    Neo Geshel Guest

    -Lost wrote:
    > "Ian Collins" <> wrote in message
    > news:...
    >> -Lost wrote:
    >>> "Ian Collins" <> wrote in message
    >>> news:...
    >>>> 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?
    >>>

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


    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).
    ***********************************************************************
     
    Neo Geshel, Feb 18, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Karsten Wutzke
    Replies:
    21
    Views:
    936
    Roedy Green
    Jun 29, 2007
  2. Nathan Sokalski
    Replies:
    4
    Views:
    598
    PJ on Development
    Nov 8, 2007
  3. Replies:
    0
    Views:
    262
  4. Sriram Srinivasan
    Replies:
    13
    Views:
    583
    Benjamin Kaplan
    Nov 12, 2009
  5. Nathan Sokalski
    Replies:
    4
    Views:
    201
    PJ on Development
    Nov 8, 2007
Loading...

Share This Page