We Keep Coding

Javascript: How to make sense of all the frameworks and design philosophies?

I have been a user of jQuery (and some of its minor plugins) for a while. The Javascript code I've developed over the years could be described best as... messy. It used a ton of global variables and functions here and there, didn't use standard ways of organizing the code, nor any design patterns whatsoever.
I am currently building the new version of a website, and I have completed doing the backend with PEAR::MDB2 and Smarty templates. The rest is just homebrew PHP with some classes.
Now I am at the point where I'll add the Javascript layer on top of the website to improve the user-friendliness of some features. (while making sure everything degrades gracefully) I want to write better, cleaner, more organized Javascript than I used to, so I did a little research. I read Stefanov's Object-Oriented Javascript to have a better grasp on some concepts I knew only loosely about (prototypes, constructors, etc.) as well. Now I'm stuck at a point where I wonder which Javascript frameworks I should use, and how to organize it all.
After conducting my research, I understood Cappuccino & Objective-J, and Sproutcore were not what I was looking for. To quote Cappucino's about page:
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks
So there's that. Then I found out about Coffee Script, which is more of a one-to-one "compiler" and wouldn't help me with the actual organization of my code.
I also stumbled on some articles that give guidelines:
Using Inheritance Patterns to Organize Large jQuery Applications
A JavaScript Module Pattern
I also found out about Backbone.js, Shoestring, JavaScriptMVC, Google Loader, jQuery Tools, jQuery UI. I don't really know what to do of all this... The things I know:
I don't want to invest too much time in learning something too complex, I want to keep things simple and flexible as much as possible (that is why I don't use Symfony on the backend, for example), yet clean and organized.
I want to use jQuery, the question is, what should I use with it? (that is compatible too)
Right now, I'd use jQuery and jQuery Tools and "organize" all that in a simple namespace/object literal with simple properties and methods and also, since the site is localized, I just plan on using the simple vsprintf (as I do on the backend) with key:value pairs loaded from an object literal provided by the backend. JavaScriptMVC seems interesting, but I fear it would bring way too much complexity for a project that is fairly small sized. That is where I need your advice! Thank you very much in advance.

Ok, my attempt at an answer:
There is no 'best' to way to do it. You now know what's there and I think you might have a preference for yourself for what you want. In that case, pick a framework and learn it inside-out. (sorry to burst your bubble, but each framework has a learning curve, some steep, some very easy, but in the end to use it well you have to invest in it. Just do it, you won't be sorry).
You of course have an preference for clean code, so you might take some considerations into account. You also say you have a preference for jQuery, which is fine, but there are some limitations (as also pointed out in the link provided by eskimoblood).
There are some nice lectures / and tutorials with advice on how to structure your code in jQuery:
How to manage large jquery apps
On Large jQuery apps
Essential Javascript and jQuery patterns (free ebook)
Some style guides:
Jquery core UI Styleguide
Google Closure Javascript Style Guide
Tools for checking your code
JSLint
JSHint (a more forgiving/practical fork)
Closure Linter (haven't tried it yet, but intend to)
Standard works (javascript)
Everything by Douglas Crockford
Quirksmode
There might be more.. perhaps more people can contribute, but I also think that you've almost reached the end of what you can learn before getting your hands dirty. Many of these guides are written in a very generic way, but the interesting thing is that javascript is called upon in many specific situations. It might be useful to just post some of the code that you regard as "messy" and we can help you figure out how to do it better. Good luck!

You should watch the video and read the links in this article and then you should ask yourself again if jquery is the right tool. Maybe you will use dojo, that is much better for larger projects or you take a look at backbone and where you can stay with jquery. After all both of them are more "javascriptish" then something like sproutcore, cappuciono or even GWT. And also much easier to understand when you come from jquery.

One framework that is to consider is definitely ReactJS from Facebook. This framework is pretty slick in many ways.
First thing you have to know is that it is a view framework. It can be used server-side to do the pre-rendering of pages, but it really shines on client side. Since it's a view framework, it can be used with backbone or any other "back-front"-end framework.
One of the main point of React is its rapidity. It keeps a virtual DOM in memory and virtualize all the webpages events. So the virtuals event are used to keep events browser agnostics.
The virtual DOM kind of make programming a dynamic site as if you were programming an old static website. You can just shoot the whole HTML to render to the view engine (as if you were "re-rendering" the whole page) and it will manage the DOM operations. It does a diff between the new virtual DOM and the current virtual DOM and only inserts nodes that needs to be inserted. This way you reduce the number of DOM ops and thus increase your render speed by a lot.
A good place to start is this tutorial which shows how to use "Flux" (the web flow designed by Facebook for its site) in order to realize a Todo application!

Wrap jQuery, dojo with custom library?

Coming from Java, I'm wondering if a Java best practice applies to JavaScript.
In Java, there's a separation of interface and implementation, and mixing them up is considered a bad practice. By the same token, it is recommended to hide implementation details of your library from end developers.
For example, log4J is one of the most popular logging libraries out there but it is recommended to write code to the slf4j library or the Commons Logging library that "wraps" log4j. This way, if you choose to switch to another logging framework such as logback, you can do so without changing your code. Another reason is that you, as a user of a logging library, how logging is done is none of your concern, as long as you know what logging does.
So back to JavaScript, most non-trivial web applications have their own custom JavaScript libraries, many of which use open source libraries such as jQuery and dojo. If a custom library depends on, say jQuery, not as an extension, but as implementation, do you see the need to add another layer that wraps jQuery and makes it transparent to the rest of JavaScript code?
For example, if you have the foo library that contains all your custom, front-end logic, you'd introduce the bar library that just wraps jQuery. This way, your foo library would use the bar library for jQuery functions, but it is totally oblivious to jQuery. In theory, you could switch to other libraries such as dojo and google web toolkit without having a big impact on the foo library.
Do you see any practical value in this? Overkill?

Although it makes sense from a theoretical standpoint, in practice I'd say it's overkill. If nothing else for these two reasons:
Anything that adds to the size of
the request (or adds more requests)
is bad - in web world, less is more.
If you're using say jQuery, the
chances of you switching to
something like Mootools is (imho) slim to none. From what I've seen, the top libraries each aim to solve different problems (at least in the case of Mootools and jQuery - see this great doc for more info on that). I'd assume that you'd incur a tremendous amount of headache if you were to try to implement a middleware library that could easily switch between the two.

In my experience and being a Java developer myself, sometimes we tend to take the whole "abstraction" layer pattern too far, I've seen implementations where someone decided to completely abstract a certain framework just for the sake of "flexibility" but it ends up making things more complicated and creating more code to maintain.
Bottom line is you should look at it on a case by case basis, for example you wouldn't try to create an abstraction layer on top of struts, or on top of JPA, just in case you then go to a different framework (which I've rarely seen done).
My suggestion is, regardless of the framework you are using, create objects and components that use the framework internally, they should model your problem and be able to interact between them without the need of any specific framework.
Hope this helps.

There are a lot of good answers here, but one thing I don't see mentioned is feature sets. If you try to write a library to wrap the functionality provided by, say, jQuery, but you want to be able to easily swap out for something like prototype, you have a problem. The jQuery library doesn't provide all the features prototype provides, and prototype doesn't provide all the features jQuery provides. On top of that, they both provide their features in radically different ways (prototype extends base objects -- that's damn near impossible to wrap).
In the end, if you tried to wrap these libraries in some code that adds 'abstraction' to try to make them more flexible, you're going to lose 80% of what the frameworks provided. You'll lose the fancy interfaces they provide (jQuery provides an awesome $('selector') function, prototype extends base objects), and you'll also have to decide if you want to leave out features. If a given feature is not provided by both frameworks, you have to either ditch it or reimplement it for the other framework. This is a big can of worms.
The whole problem stems from the fact that Java is a very inflexible language. A library provides functionality, and that's it. In JavaScript, the language itself is insanely flexible, and lets you do lots of crazy things (like writing a library, and assigning it to the $ variable). The ability to do crazy things lets developers of javascript libraries provide some really creative functionality, but it means you can't just find commonalities in libraries and write an abstraction. I think writing javascript well requires a significant change in perspective for a Java developer.

Someone wise once said "premature optimization is the root of all evil." I believe that applies in this case.
As others have expressed, you don't want to abstract for the sake of flexibility until you have an actual need for the abstraction. Otherwise you end up doing more work than necessary, and introducing unnecessary complexity before it is required. This costs money and actually makes your code more brittle.
Also, if your code is well organized and well tested, you should not be afraid of major changes. Code is always changing, and trying to anticipate and optimize for a change that may or may not come will almost always get you in more trouble than it saves you.
Acknowledgement: I should give credit to Agile programming and my practice and readings on the topic. What I've said comes directly from my understanding of Agile, and I've found it to be an extremely good razor to cut out the extra fat of my work and get lots done. Also none of what I've said is actually JavaScript specific... I'd apply those principles in any language.

There are good arguments calling this development practice - wrapping in order to switch later - into question in any language.
A good quote by Oren Eini, from his writeup on wrapping ORMs:
Trying to encapsulate to make things
easier to work with, great. Trying to
encapsulate so that you can switch
OR/Ms? Won’t work, will be costly and
painful.

This is definitely something that is done in enterprise environments.
Take for example a company that has their own custom javascript framework that is used on all of their projects. Each of the projects decide to use their own framework (jQuery, Dojo, Prototype) to add functionality to the underlying modules of the company framework. Employees that move between projects can now easily do so because their API with working the project's codebase is still the same, even though the underlying implementation could be different for each project. Abstraction is helpful in these situations.

It is overkill. Javascript is not Java and is not in any way related to Java. It is a completely different language that got J-a-v-a in the name for marketing reasons.
If you are concerned with availability of add-on libraries, then choose a framework with a large ecosystem. In an enterprise environment you will be further ahead by standardising on a vanilla off-the-shelf uncustomised web framework that you can upgrade every year or so tracking the rest of the world. And then supplement that with a SMALL in-house add-on library which you will, of course, have to maintain yourself, not to mention training any new programmers that you hire.
Since you are talking about Javascript in the client (web browser) it is more important that you limit the complexity of the things that people do with it. Don't build huge amounts of client side code, and don't make stuff that is so brittle that another programmer can't maintain it. A web framework helps you both keep the linecount down, and keep your own code reasonably simple.
It is not a question of Javascript best practice, because that would be different for server-side JS such as Rhino or node.js.

Adapter pattern is not a common solution in this case. The only example I know to use this pattern is extjs. Javascript projects are usually too small and they aren't worth the effort you would make by creating such an abstraction layer.
The common solution for this problem is that you try to use multiple frameworks together for example with jquery.noConflict.

I've done this before, and can talk a bit about the experience of writing a library/toolkit wrapper.
The plan was to move from Prototype to some other library. Dojo was the first choice, but at the time I wasn't sure whether that's the library to move everything to (and by everything I mean ~5MB of Prototype-happy JS). So coming from a world of clean interfaces, I was set to write one around Prototype and Dojo; an awesome interface that would make switching out from dojo a breeze, if that was in fact necessary.
That was a mistake that cost a lot of time and effort for a few reasons. The first one is that although two libraries can provide the same functionality, (a) their API will almost always be different, and most importantly (b) the way you program with one library will be different.
To demonstrate, let's take something as common as adding a class-name:
// Prototype
$("target").addClassName('highlighted');
// Dojo
dojo.addClass("target", "highlighted");
// jQuery
$("target").addClass("highlighted");
// MooTools
$('target').set('class', 'highlighted');
Pretty straight-forward so far. Let's complicate it a bit:
// Prototype
Element.addClassName('target', 'highlighted selected');
// Dojo
dojo.addClass("target", ["highlighted", "selected"]);
// jQuery
$("target").addClass(function() {
return 'highlighted selected';
});
// MooTools
$("target").set({
"class": "highlighted selected"
});
Now after choosing an interface for your version of the addClass you have two options: (1) code to the lowest common denominator, or (2) implement all of the non-intersecting features of the libraries.
If you go with the 1st -- you'll loose the "personality" / best qualities of each of the library. If you go with #2 -- your addClass' code will be at 4 times larger than the ones provided by any of the libraries, since for example when Dojo is included, you'll have to write the code for the function as the first param (jQuery) and the Object as the first param (MooTools).
Therefore, although it is theoretically possible, it isn't practical, but is a very nice way to understand the intricacies of the libraries out there.

Is plain vanilla JavaScript better than using frameworks like jQuery or MooTools? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am wondering if it is a good idea to rely on frameworks like jQuery or MooTools or should we just use plain JavaScript?
Apart from avoiding the re-invention of wheel, do they add any specific value?
Since the frameworks are open to the public, can there be possibility of exploitation of any security holes that might appear (of course, unintentionally :) ) in the frameworks?
Are there any other points that are to be considered when choosing a framework or otherwise?

Frameworks solve cross-browser bugs which normally would cost hours of your time, so you can focus on functionality instead of worrying about some edge case browser bug.. instead of wasting 4-5 hours solving a bug spend that time with your family.
Frameworks such as jQuery are pretty loaded with stuff like animation, selectors, html manipulation so there's usually some sort of functionality already built into the library, again saving you more time and the API makes it really easy to actually accomplish complex things.
Interpreters and browsers are only getting faster and faster so I don't particularly think it's a huge issue loading an entire library up. In addition thanks to Google et al we get very fast cdns and nowadays lots of sites are using the same exact URI to pull the script in, meaning there's a higher rate of the script getting cached and reused on another site.
Instead of every single web developer having their own library it's much more efficient having thousands of people concentrated to bettering a handful of libraries so cross-browser bugs get documented and fixed.
Competition is a good thing, the result of the slickspeed tests resulted in much faster selector engines such as Sizzle. Developers not having to worry about trivial DOM bugs means more complex libraries are created daily, which means entry-level developers have access to very powerful plugins.
As far as security, jQuery for example will detect if the browser is capable of parsing JSON natively and if so, rely on that. Usually any modern browser will have this, and it's much safer than eval... so jQuery strives to use the safer and more secure methods first. It will only use eval if there isnt a JSON.parse method available.
An important thing to remember in jQuery though is remembering you're still coding in Javascript. Usually people get too caught up in the sugar coated methods and wrapping everything in $, I think it's important to know you can still do this.href instead of $(this).attr('href') if you would like an absolutely normalized uri for example.

Do not downplay the importance of avoiding the re-invention of the wheel. You don't invent a new computer each time you want to write a new program.
But apart from that, JavaScript libraries provide better cross-browser support. This is extremely helpful, as a quick look at QuirksMode will demonstrate.
JavaScript frameworks make many things easier. Look at the jQuery documentation and you will see how easily it is do many fancy things.
JavaScript frameworks have been extended by many people, so there are many high quality jQuery plugins (for example — it's the framework I know the best) that you can use without having to write them yourself.
It is unlikely that JavaScript frameworks would introduce security holes, as they don't expose any more functionality than what you can do with plain JavaScript.

The frameworks provide a cross-browser-API for JavaScript, so most of the time they are very usefull even though they come with a little speed-loss. But the JS-Engines get fast almost every update so that's not really a problem.
There are also very many plugins for the frameworks so they not only provide an API but also new cross-browser-features.
But it depends on what you wanna do.

I don't give great weight to the "Open Source is extra-vulnerable to security issues" argument. I see benefit of many Good Guys reading the code and spotting such problems. If this were an issue then we'd need to discard Linux, Apache, MySql, and most of the Java libraries.
Frameworks generally save a very great deal of effort, I see them precisely as a pre-invented wheel. They don't need any other value.

It depends on what you're using JavaScript for. If you want to be able to show and hide panels, animate stuff, attach events to multiple elements, do Ajax, etc. then you need to consider cross-browser issues.
jQuery eliminates the need to think about cross-browser issues and allows some really neat functionality like the above and also modal dialogs, etc.
So it depends on what you want from JavaScript.

I have never used MooTools so can't comment on that, but jQuery makes a lot of things easier.
Selecting collections of objects by class, name, partial Id, etc.
Simplify Ajax calls.
Wireup event handlers to handle onclick, mouseover, mouseout, etc. and assign to elements based upon general selectors so that the logic can be reused.
Tons of transitions and other visual stuff to pretty up the front end.
There are a lot more, but it generally simplifies/accelerates development. One thing to watch out for is if you are using a ton of selectors in a single function (loop that iterates over the DOM 40+ times) it is waaay more efficient to use vanilla JavaScript.
So my advise would be to code the front end with the aid of a framework and then optimize the underperforming parts by subing in vanilla JavaScript.
Also, I don't see how jQuery or MooTools could be a security threat as they are client side frameworks, not server side. Remember to always validate inputs on the server side in addition to any client side validation and to properly parameterize SQL queries that are constructed on the server side.

What should I choose? jQuery, mootools, yui, scriptaculous or prototype?

Duplicate: Which Javascript framework (jQuery vs Dojo vs … )?
I am totally new to JavaScript, but I want to implement Ajax features into my website. Which JS framework should I learn? Please recommend or which one you are using and why you use it?

jQuery is currently extremely popular, so you're probably going to have the most luck finding recent tutorials/plugins/etc for it, as opposed to one of the other frameworks. That's probably a fairly good selling-point from the perspective of someone new to this.

Microsoft apparently blessed jQuery, so for now that's your best bet.

I'm currently writing a paper on JavaScript frameworks. After all the research I've done so far, I can tell you this...
Seriously, nobody can tell you which framework is best for you. There's only one way to find out: try playing around with all the different libraries you're considering. It's a matter of personal preference.
See this excellent JavaScript Library Overview, a presentation by John Resig (who happens to be the lead developer of jQuery). It contains small code samples for all the listed frameworks. After viewing those, you'll probably know which framework to choose, depending on which coding style you prefer.
Also, this SO topic might be of interest.

Jquery is probably the best of the lot, it actually lets you "do more, write less"

One more for Jquery..Awesome plugins!!

Built in intellisense for jQuery in VS2008 (sp1 I think?) was one consideration for us, but essentially we've played with mootools, prototype, scriptaculous and jquery, and have found jquery to be the easiest for us all to understand/support.
We have a mixed team here, and even our business logic guys can pickup the logic/approach in jquery.
We also use telerik controls, and they've now announced more support for jquery - it certainly seems its star is in the ascension.
Try all of them, but if you're from a .net background, I think it's the logical choice at the moment.

I use jQuery now because it is easy and has lots of features. Before I was using prototype and scriptaculous.

I noticed Dojo wasn't included on your list. It's a framework that's geared to heavy-weight AJAXified pages.
http://dojotoolkit.org/
That said, JQuery appears to have the most momentum at the moment, and other frameworks (like Dojo) are working on putting more JQuery-like functionality into their product, so I would recommend learning that.

Im having a really good time with jQuery myself. Thers lots of good documentation and tutorials for it, which is excellent if your new to Javascript.
If its only the ajax features your after I recommend checking out http://docs.jquery.com/Ajax . Also the tutorials at Themeforest is really brilliant. For example the jquery tutorial for absolute beginners day 10 is showing you the basics of jQuery + Ajax.

FORK Ajax. It does the job well, and it's very small (5KB minified) and simple.

I'll plug Mootools. Of course the reason anyone prefers any of these over another is "I started using XYZ first."

jQuery is my go-to framework of choice, but you really have to look at each ones' strengths and see how they align with your project
The important thing is, use a framework -- really any framework. The benefits of using a framework, no matter which one, are so enormous. The best ones get rid of all or most of the cross-browser headaches you are bound to experience.

The best thing to consider is what you want the framework for. jQuery was designed to make manipulating the DOM easier. So if that is the main focus of what you want to be doing, then great. It is a super rad framework and it is really is amazingly natural and easy to pick up.
That having been said, it is worth considering what the others have to offer. Other frameworks like prototype and mootools are most interested in turning javascript into a more powerful programming language with richer object oriented programming capabilities and functionality for arrays, strings and numbers. I don't know enough to be able to compare/contrast prototype and mootools, but maybe someone else could fill in on that.
This is a great article that explains the difference between mootools and jquery - jqueryvsmootools.com/
The good news is that you don't necessarily have to decide. Although you might occasionally come up with bugs, you should be able to use jQuery with either mootools or prototype (see here). Basically just call jQuery.noConflict(); before any script on which you want to use jQuery and everything should work just fine. This allows you to use jQuery for all of it's slick DOM manipulation and rad UI library while also giving access to a more powerful framework when that is what you need.
Please let me know if I've missed anything here and I hope this helps.

When I was new to JavaScript, after a week I found out that life is much easier with a framework. Anyway, I did not even knew, what exactly they are for; I've got some glue about $() that it's a smart replacement for window.getElementById(), and I assumed that there are some other comfortable methods for other purposes, like AJAX request.
I did not wanted to spend lot of time on learning a framework, so I was decided that I will choose that which I fall in love first sight. Then I was spending about a whole month with googling. I have not missed any of the "big names", but I dropped them soon. The main reason of the dissatisfaction was their site, the documentation: after reading a whole page of text, I was yet as dumb as before. What is it for? What they do? What is the input, what is the aim, what is the output?
Then, I found DOMAssistant. It's small, perfect, and well-documented. Just take a look on the first paragraph of the opening page, it's a totally clear definition of the JS framework:
What is DOMAssistant?
The idea of DOMAssistant is to provide
a simpler and more consistent way to
script against the Document Object
Model (DOM) in web browsers. The idea
is that everything starts with the
element(s) in question, selected
through id or CSS selectors, and then
perform various methods on it, such as
adding or removing classes, events
etc.
So, I say, if you finally choose another, more fashionable framework, DOMAssistant is a must-to-see. And if you have no need for animated flying windows, it's also a good choice.

Which Javascript Framework is the simplest and most powerful? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been using various javascript frameworks including mootools, jquery, prototype and scriptaculous and have found them all good, but difficult to extend to more complex ideas.
If I am going to knuckle down and learn one, which is the simplest to extend and use whilst staying powerful enough to use in a variety of directions?

I propose jQuery.
I'll give you some of the major arguments from the presentation that my team put on yesterday for senior management to convince them of that.
Reasons:
Community acceptance. Look at this graph. It shows searches for "prototype", "yui" and "scriptaculous" growing from 2004 to 2008. Then out of nowhere in 2006 searches fro "jquery" shoot up to double the number of the other libraries. The community is actually converging on a single leading product, and it's jQuery.
jQuery is very very succinct and readable. I conducted an experiment in which I took existing code (selected at random) written in YUI, and tried re-writing it in jQuery. It was 1/4 as long in jQuery. That makes it 4 times as easy to write, and 4 times as easy to maintain.
jQuery integrates well with the rest of the web world. The use of CSS syntax as the key for selecting items is a brilliant trick which helps to meld together the highly diseparate worlds of HTML, CSS and JavaScript.
Documentation: jQuery has excellent documentation, with clear specifications and working examples of every method. It has excellent books (I recommend "jQuery in Action".) The only competitor which matches it is YUI.
Active user community: the Google group which is the main community discussion forum for Prototype has nearly 1000 members. The Google group for jQuery has 10 times as many members. And my personal experience is that the community tends to be helpful.
Easy learning curve. jQuery is easy to learn, even for people with experience as a designer, but no experience in coding.
Performance. Check out this, which is published by mootools. It compares the speed of different frameworks. jQuery is not always the VERY fastest, but it is quite good on every test.
Plays well with others: jQuery's noConflict mode and the core library's small size help it to work well in environments that are already using other libraries.
Designed to make JavaScript usable. Looping is a pain in JavaScript; jQuery works with set objects you almost never need to write the loop. JavaScript's greatest strength is that functions are first-class objects; jQuery makes extensive use of this feature.
Plug-ins. jQuery is designed to make it easy to write plugins. And there is an enormous community of people out there writing plugins. Anything you want is probably out there. Check out things like this or this for visual examples.
I hope you find this convincing!

In my opinion, jQuery is exceptionally powerful and simple. It uses CSS selector syntax to pull back elements and only adds two functions to the global namespace: jQuery() and $(), which is an alias for jQuery().
There are a massive number of plugins available for jQuery to let you do things like create slide shows, accordion controls, rich calendars, etc. The book "jQuery In Action" is a phenomenal companion to the online reference material.
We used it on my last project to create a fairly rich scheduling tool and we liked it so much, we're encouraging it's adoption throughout our consulting company as the defacto standard for all JavaScript use. You can check out the results at http://www.stanleysteemer.com

See also (other related questions):
Comparison of Javascript libraries
What JavaScript library would you choose for a new project and why?
What is the single most useful general purpose javascript library for rich internet apps?
Which JavaScript framework is best for web development?
Which JavaScript library is recommended for neat UI effects?
What is the best lightweight javascript framework?
Any good AJAX framework for Google App Engine apps?

jQuery is my favorite

Prototype. Is simple, unobtrusive, and makes your javascript code look cleaner than ever.
It has a wonderful user group, where you can get your questions answered almost immediately

Another vote for jQuery. It's small, focussed, and yet very powerful. It's also reasonable well documented, by the (generally awful) standards of JS libraries.
It's also very easy to extend, once you get your head around the syntax.

NOTE: This answer was pre-Angular/Ember/etc. so addresses an outdated issue.
I teach this stuff, and really had little choice but to home in on JQuery, since the majority in the industry has already 'chosen' it (not always a good reason, I know), but also because - for students that already know some CSS - the entry point is lower.
I've also used Mootools (my second choice), but a colleague convinced my to switch to JQuery with the 'programmability' argument - I find it cleaner to code with and understand. The JQuery community, online documentation, free online books and third-party sites help, too.