jQuery’s primary role is to normalize the DOM API which is the one thing browsers haven’t agreed on for over a decade (until IE9 came out). It’s better thought of as a tool than a library. It’s basically just a factory function that returns an adapter merged with a bit of decorator that wraps and normalizes the DOM object API with lots of cruft reduction and some additional goodies like the animate function and an event system that lets you fire and listen for new events on the fly on any object without even defining them somewhere first.

What it doesn’t do is help you with writing more complex, maintainable app-oriented code (well, the event thing is neat-o but easy enough to DIY), use objects well, or use any of the core ECMA spec obects that really form the basis for the core language of JavaScript.

Among proper JavaScript devs, it takes very little time to filter out the devs who are going to be useful on a project from web designers or CMS-only devs gunning for a salary increase by doing awful things with a tool they’d rather not understand under the hood if they can avoid it.

Also, the DOM API is pretty verbose with method names that practically write their own documentation (by approaching paragraph length basically), which is a good thing, IMO. We want the core native stuff to be obvious and spelled out. But the tedious nature of writing with it encourages us to use JavaScript to do something it’s very good at. Eliminate cruft, normalize, and bend the API to a paradigm that works better for us. I personally think jQuery did a bang-up job of this compared to most of its contemporaries and that you can learn a lot about JavaScript (like how to keep your objects really lightweight as far as memory is concerned) by studying jQuery under the hood.

But I wouldn’t use it as a pre-fab UI library namespace. And I wouldn’t discard loops in favor of using .each on everything. And I often downshift to DOM API methods when JQuery is adding work without really eliminating cruft which brings up one of the most important features of jQuery to those of us who actually know what we’re doing. It doesn’t get in your way when you don’t want it there.

But make no mistake. If you don’t know how to do it without jQuery you’re at best an entry-level JavaScript/client-side dev. On the flip-side if you only know JavaScript and only have minimal understanding of CSS, you better be focused on something other than UI problems.

Edit: I realize I focused on JQ a bit too much for a question that was asked more generally.

Most other popular JS tools/libraries/frameworks are either UI libraries, none of which I’m a big fan of (too inflexible typically), and rapid-application building frameworks that apply concepts from MVC or similar patterns. I’d rather DIY architecture personally (and I’m a little wary of this model-binding in templates trend) but these new frameworks aren’t the sorts of things implemented by JS devs who can’t handle code problems that require JS-literacy themselves I would wager.

Most JavaScript developers use a framework since JavaScript as a language contains quite a lot of cruft and otherwise undesirable functionality. It has some really powerful functionality but there are also plenty of ways to shoot yourself in the foot.

I’ve used jQuery and YUI and the past. When using a good JavaScript framework programming in it is a significantly more enjoyable experience. I tend to favor jQuery these days because it allows me to write very clean functional-like code. jQuery also relies heavily on CSS selectors for DOM querying so it feels a lot more natural to write $('#some_element') than writing document.getElementById('some_element').

I recommend reading JavaScript: The Good Parts by Douglas Crockford to learn some tips for very effective (and beautiful) Javascript programming. This book won’t teach you how to write nifty JavaScript effects or AJAXy magic but it will teach you about the language, what to rely on, and what to run away from screaming. It’s a fairly short book but I’d recommend reading it a few times.

When we used to develop in JavaScript we had to write three version of the same function in order to make the function works in IE, Safari and Firefox.

JQuery take care of this problem (not perfect but better than doing it from scratch) and let you focus on the function itself.

On the whole, Javascript frameworks solve DOM interaction problems. The rest JS has nothing to do with the DOM.

Of course, many frameworks supply functions to JS behave more like a standard OO language, such as by adding “classes” (uugh, now my mouth tastes dirty). I’d say, just learn JS for what it is and avoid that crap. To me it’s like trying to program C++ as a functional language. You can kind of do it, but it’s better to learn C++ as it really is.

JS has more in common with languages like LISP or PROLOG than Java. Syntax is similar to Java, which is misleading and the frameworks are designed for not-so-clever PHP beginners. So they try to emulate some outdated, horrible OOP model. And the code these beginners produce is just sub-standard, ugly and hard to modify.

Of course that OOP model works on server side very well, but it’s horrible for client side UI. JS has completely different programming model, very well suited for UI developping (easy callbacks, prototypal inheritance, super-easy encapsulation, very clean object model, etc.).

jQuery… that’s most easy to use, but it is most horrible. With constructs like parent().parent().parent()… it’s designed to “shield” you from “real” JS by providing some horrible PHP-like OOP model. That’s why, probably is so widely adopted. People don’t have time to learn JS so they just use jQuery and pretend it’s Java or PHP.

instead jump right ahead with a library like JQuery ?

Just stay away from it. There is no worse code in JS that code written using JQuery. Or course if you previously used Java it’d look “ok” for you. But that’s not true. You can write so much better, error-free and modular code using pure JS or mootools (because it’s extending JS rather than replacing it’s object model).

Using that BS those frameworks provide (like “classes”) it’s like going back from C++ to C, just because you can’t think beyond simple functions and global variables. So you need something that’ll “dumb down” the language so you can write some very crappy code without learning any new things.

People learn differently.

==Top down approach==

Some jump into the library and learn how to work with the library and inevitably learn some of the javascript, or base language, features.

==Bottom up approach==

Others like to learn about the pieces and then how they are put together to create the library they’re using. Sometimes they feel that to be more effective they’d like to know the nooks and crannies of what they’re using and the language it’s written in.

The approach you take largely depends on you AND how easy the library is to use. If the library is hard to use then either users won’t use it OR they’ll be forced to do a bottom up approach.

Fortunately, javascript appears deceptively similar enough to java and other languages in terms of syntax that most users feel they can take a top down approach while relying on their reference language for help to determine how things are working. This happens even though, as stated in the comments, Javascript is very different from Java and draws more inspiration from LISP/Scheme than from Java.

The top down approach works with javascript/jquery quite well but what inevitable ends up happening is that the user ends up coming up with a Java like solution to their problems when a simple javascript convention would be easier to implement. This is a drawback but only until they realize that javascript can make some tasks easier. Until then, to the user, javascript becomes Java just on the client side.

Eventually they run into some weird bug or code they can’t understand, like the way closures work, and have to dig into javascript basics more than they have to.

I don’t know how much of client-side code is built with 3rd party libraries but I do know that they can make life much easier since you don’t have to ‘re-invent the wheel’. Cave men did that a while ago so focus on other things if you can. If you’re in a limited environment then you might have to write your own library but basing it on a 3rd party library is NOT a bad idea because they’ve thought of, faced, and solved more issues than one person could hope to cover in the same amount of time.