jQuery is an interesting language. But I feel like it's no more "javascript" than C is assembly. It uses a lot of conventions and syntactic sugar that is not standard in the language. It's a cool and elegant, but there's a learning curve at both ends; first, you need to learn it, and then it becomes so habitual that you forget how to write "regular" javascript.

YUI, on the other hand, feels a bit more like plain old JS, which some people like and some people don't. The main problem with YUI is a lack of overall consistency in naming and whatnot. YUI 3 is coming out soon-ish, and addresses a lot of that stuff quite nicely. YUI does a really good job of not cluttering up your environment with too much gargbage--everything is under one global YAHOO object, so it's a friendly neighbor.

Avoid prototype at all costs. It monkeys around with the core object types, and adds scores of globals, which pretty much ensures that, unless ALL of your code uses prototype, and always will, you'll get unexpected behavior in some cases.

YUI was built first and foremost for use at Yahoo. It'd be hard to find a library that's more play-tested or scrutinized for performance than that. Personally, I find the core YUI libs a lot more useful than the widgets. They tend to be a bit over generalized in a lot of cases, and I can usually get better results by rolling my own.

Disclaimer: I'm a webdev at Yahoo, and I've been using YUI since its pre-OSS days.

jQuery is, of course, Javascript. John Resig didn't invent functional closures or chaining. But it seems like jQuery is designed to change the way that you write Javascript. It even says so on http://jquery.com/ It's a set of conventions, and they're not standard. I'm not saying that they're bad (in fact, I really like the jQuery style and think it's very elegant.) But there's a learning curve there, and not every javascripter is a programming language geek who would get off on learning a new style.

> then it becomes so habitual that you forget how to write "regular" javascript.

I wish that were true. Unfortunately, I still have to drop back to W3C DOM for performance often enough. For a recent feature I added, 6 lines of jQuery becomes 24 lines of JavaScript, but the speed goes from unacceptable to acceptable. (What am I doing that jQuery's not fast enough? In this case keystroke-by-keystroke search and manipulation of a 6000-cell table.)

Have you tried JQuery 1.2.6 yet? I've also had to drop down to raw DOM for performance, but I've found that many features that were unacceptably slow with 1.2.3 (mousemove events, $.map) have gotten quite usable. Events no longer copy the whole event object, map is linear time instead of quadratic, and I've heard $.extend got a major speed boost which'll speed up construction of all jQuery objects.

(Curiously, in the benchmarks folks did in the Reddit thread, it looked like Firefox was not quadratic - which implies that Firefox either has some clever optimizations going on or does crazy things with concat().)

if you or anyone is interested send me a email (tunde.ashafa AT gmail)

This is high praise indeed, and suggests to me that a) the standard DOM APIs are poorly designed, and b) that jQuery’s API is very well designed, and meshes much better with the language.

As I write most of my Javascript at Yahoo, and we can assume that Yahoo webdevs know Javascript, but not necessarily jQuery, YUI is a much better choice. (Just addressing the language conventions, not nec. the library implementation.)

To me, jQuery feels like a better javascript than javascript itself. Manipulating the DOM with plain old javascript is what feels like using C. All the quirky function names, all the weird browser variance. It's like being in college again, trying to get C++ I wrote in Windows to compile in Linux.

While jQuery is merely a library at the moment, I have to wonder if there would be any drastic speed improvement (other than negating the download time) if someone implemented the jQuery API as a browser plugin (or just tacked it on to the JS spec itself). I'm not saying that this would have any immediate practical application (since no one installs plugins anyway), but the idea sounds just silly enough to be interesting at least.

Similarly, for DOM querying, it implements the W3 Selectors API rather than reinventing the wheel.

I really like this approach. base2 doesn't provide anything in the way of widgets (though I think there may be some code along these lines in the Subversion repository, implementing some of the HTML5 components) -- for most of what I do, widgets aren't available anyway or would need to be extended, so I end up writing my own. And it's easy enough to use a YUI or other widget with base2 when it makes more sense.

For animation, I've used animation.js and found it simple and fast.

> anything but Mozilla, I think

WebKit also handles things well:

[].map

function map() { [native code] }

[].forEach

function forEach() { [native code] }

For more advanced stuff, your best bet is Prototype.

Dojo, YUI (and ExtJS, not on your list) are good if you have a massive team of JavaScript developers and need standards and solid documentation, but are overkill for 90% of projects.

Ext has a nice DataStore object for accessing remote data. And Ext has all those great "rich" components. But I found it wasn't much more work to do my own components in jQuery. (Tree is very simple to implement in jQuery from scratch)

The sense of control I have with jQuery is nice.

The main code to handle my own trees:

  _.fn.toggleTreeNode = function(animate) {
    var node = this.filter('button');
    if(animate) {
      node.siblings('ol').slideToggle(animate)
    }
    else { 
      node.siblings('ol').toggle();
    }
    node.parent().toggleClass('closed');
  };

My favorite thing about jQuery is it makes doing things the right way very easy.

There's a lot of jQuery love and Prototype hate out there, which I don't quite get. Both are fantastic; both are bloated.

It's easy if you do it from the start, and there's a real savings in maintenance costs.

I will add that the ExtJS forums are very active and pretty helpful...as are the YUI ones. I've asked several questions in both and gotten good responses each time.

    $('a.hide_these').hide();

    $('a.hide_these').parents('p')

I've only used a few animations from jQuery (like sliding/fading) but the framework also lets you do your own custom animations using CSS (your element will gradually morph to the styles you define).

or if you want to hide all the anchors of class hide_these then you could do this.

$('p > a.hide_these').hide();

YUI is a close runner up, and if I were starting today I might go with it. The widgets are fantastic, the documentation is fantastic, and the community is large. It also feels more like JavaScript than ExtJS.

As jQuery UI develops it'll probably become a contender in that space, as well. But, for now, I'm just adding it to our websites in a few places where it is useful--that's the other negative about ExtJS: It's a "drink the Kool-aid" kind of library. I've had a hard time integrating it in little bits and pieces, and it's turned out that everything is going to have to be converted to use ExtJS for it to all work together.

;P

It's a language specifically designed to make it very difficult to do anything interesting.

PHP (the language, not the implementation) has some very deep problems, in my opinion. But at least you can sketch out a rough solution, and gradually turn it into something more polished.

I think the best design is done by coding little sketches that gradually become more and more complete, and are cheap enough to throw away; not by drawing complex UML diagrams and then carefully casting them into perfect code. That's just impossible, and the result is a lot of bloated crap that is very difficult to change when (inevitably) your design changes.

Static typing is not a silver bullet. The claim that not using a static typed language for anything complex will result in a "scratch rewrite" is absurd.

I'd say either of them would be fine, but there does seem to be more momentum behind jQuery as of late.

Prototype does a lot in that extra 24 KB, is faster on some benchmarks, and I just like the way the code looks. If you just minify and gzip Prototype, you're looking at a much lighter footprint.

In the end, none of the frameworks are very lean: though Mootools and YUI are at least modular.

I know that prototype and scriptaculous provide more functionality, but my point is that jQuery is providing enough of what I need from both libraries while still being smaller.

Seriously though - I've written both and I'd find it hard to go wrong with either. jQuery is more the way I've been leaning of late, but were it to suddenly disappear off the face of the earth tomorrow I'd be fine with Prototype/Scriptaculous. To each, his own. :-)

I actually find both to be a bit heavy. I don't necessarily want animations out of the box, so that makes jQuery a bit more bloated to me.

I also don't necessarily want all that Prototype offers for all of my projects.

I use Ruby on Rails, which has support for Prototype/Scriptaculous, so that's what I use. I like it a lot better than straight JavaScript. The thing that the libraries do well at is papering over browser differences. One good aspect is they collect "fixes" and tricks that have been spread all over the web and concentrate them one place.

I'm mystified why Prototype doesn't download in minified format. It's easy and useful to do but I'm sure most folks don't think of it.

DOM manipulation is pretty simple with the javascript dom functions, as is animation, although it depends on how custom you need it, and how much you're worried about speed/bloat/etc

Of course, you can roll that stuff yourself - but why duplicate all of that effort?

Also, DOM manipulation with the regular DOM is amazingly inconvenient when compared to manipulation using a library such as jQuery. The DOM is a pretty verbose API with a lot of weird quirks (removing a node: "theNode.parentNode.removeChild(theNode)") - jQuery provides a much more sensible API, which in turn means that I find myself using DOM manipulation a lot more since it isn't such a pain to do.

Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.

And as far as easing goes...

http://www.robertpenner.com/easing/

eg

function timerMethod() { currentFrame = (currentTime - startTime) * numFrames / animationDuration; }

And to do 'easing' as you call it, you could just use sin/cos, or a small lookup table.

The main reason to duplicate effort is to firstly learn how these things work, and secondly to get a better solution matched more optimally to your use case.

I personally like the DOM... theNode.parentNode.removeChild(theNode) makes quite a lot of sense. But it's probably a matter of taste that one.

When I started learning js I just decided it would be worth more to learn js, rather than any library. Now I know js there seems little benefit on learning one of the js libs.

Of course this is all just my personal opinion and experience.

I strongly disagree. The library authors, and fellow users, have discovered and worked-around browser and Javascript gotchas and performance bottlenecks that it could take you years of custom work to independently discover.

The issue is, they make general libraries that cover hundreds of use cases. Because they cover that many, they are very general, and useful to lots of people, but they are non-optimal. They have extra things you won't need. They have extra arguments to functions you don't need. Bloat.

But using a lot of Prototype in the past....

i think jQuery has a lot to offer above mootools, but mootools does a good job of looking really clean.