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 Ext JS as my rich-widget toolkit for a while, but I'm thinking of moving to YUI, partly because of the less restrictive license.
The component-oriented model used in YUI seems quite similar to the one that I've enjoyed so much in Ext JS, but I'm interested in how deep those similarities are. So I'm interested in feedback from people who've used both Ext JS and YUI. What is the same, and what is different? What do I lose by moving to YUI, and what do I gain?
I think both libraries actually address different needs.
YUI is designed addresses the needs of Yahoo inc. It is very good at building public facing applications where things like graceful degradation, clean markup and accessibility is important.
ExtJS is a very good and well designed full RIA framework that is very firmly targeted at building line of business applications. Features such as a really powerful grid component, strong layout and good professional look and feel.
I've used both quite considerably, although only up to YUI 2.7.0 and have built several full RIA using the frameworks.
Moving an existing application from one to another would be quite differcult as although they share a common ancestor (ExtJS was once YUIext) the frameworks are quite different now.
One major difference is that YUI is distributed under the extremely permissive BSD license whereas ExtJS is distributed under a very viral interpretation of the GPL. For instance, with Sencha's interpretation of the GPL, if you write a SOAP or REST interface specifically to talk to an ExtJS front end then your server code must be GPL and you must provide access to the source since you have "distributed" it by granting access over the web. Sencha does provide a commercial license for their code but if you read their docs carefully you will see that they do not allow you to convert code you wrote against GPL Sencha to another license when you switch to the commercial version. (http://www.sencha.com/legal/license-overview)
In short, if your code needs to integrate with proprietary business logic or commercially licensed systems then you must develop using the commercial version of Sencha from the outset.
For me the difference is that YUI is very lightweight and flexible, whereas ExtJS is heavier, with a bigger footprint and more rigid in the way you use it. YUI is great if you know what you're doing in Javascript and want to extend your power; ExtJS is good if you want a UI abstraction layer that you don't have to mess with much ... but if you do want to make it do things it wasn't designed to do, it can be a real chore.
When building a recent application I had the exact same decision to make YUI or Ext JS.
I ended up going with YUI for a few reasons:
YUI 3 is extremely light weight and fast for simple tasks and the lazy loading makes things even faster.
Graceful degradation was important for this app.
Using YUI 2 widgets in YUI 3 is rather easy and with 3.1 literally weeks away that will become even easier.
YUI documentation is unbelievable and the irc chat and forums are very helpful and actually have people from the YUI development team.
In a time when all applications are migrating to the web, the clear line drawn by Gareth between public facing and Business app doesn't make sense too me.
I prefer the other answers, like the one of Robusto, and compare both framework on technical/financial grounds.
YUI advantages:
Free
Lightweight (HTML + Javascript)
More efficient
Easier to learn and understand
Better documentation and examples
Larger community
Ext advantages:
Richer features & components
Some (undocumented) Server Side driver (like .NET) (although using such libraries on the server seems bad design)
Conclusion:
If your web site doesn't require the extra features provided by ext, go for YUI.
I haven't used ExtJS a lot yet, still in a learning phase, but for what I was able to do with it, I'm pretty sure that even a little more than 1 year ago when I was doing a lot of YUI dev, it would have been much more challenging and the result would not have been as slick.
It's not too say you shouldn't do it, but my advice to you would be to make some serious research and good prototyping of some of the existing features you have to see if YUI will fit your needs. DON'T just base yourself on the examples and the feel of "Yeah seems that would work".
With the GPLv3, it states that as long as your users are all part of the same legal entity that you do not need to share the source code. The verbiage technically states this as if they are not part of the same legal entity, then you need to provide source. But this doesn't mean Sencha won't change the license later. It also doesn't mean they will either.
Related
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.
My team consists of more java guys and limited experience with JavaScript. I know this question have been asked several times, but just to get my facts right, I need to clarify few things as my experience in client side technologies are very limited. We've decided to build our solution using GWT instead of pure JavaScript framework (given there are more java experience).
These were the facts to back my decision.
100% written in java
Requires basic java skills (Java SE not Java EE)
OOPHM – Out of process hosted mode – Define your browser & version. Browser compatibility no longer our problem
Debugging – debug your GWT apps just like any other Java application, using your IDE's debugger
Optimized JavaScript - GWT writes faster and more compact JavaScript than you
But some of my application function needs to use external js libraries.
For e.g. Let's say I need make use of some specific js library to draw some stuffs on a particular page. (actually that js files written in dojos).
Can above requirement be accommodated with GWT?
Do you think the decision to go with GWT is wise or do have any other recommendation?
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
Thanks in advance.
Can above requirement be accommodated with GWT?
Yes (see #Andrey Kapelchik's answer).
Do you think the decision to go with GWT is wise or do have any other recommendation?
Given your background and the points you mentioned, I think it is a very good decision. I have built apps with JavaScript, jQuery etc., but for anything that's larger than 1000 lines of code, I wouldn't want to build a JavaScript app "manually" again. The points that are decisive for me:
With GWT, I can re-use parts of the code both on the server and client side. For example, I can validate on the client side to give immediate feedback, then validate again on the server for security, using the same code.
I find my way much easier in large GWT projects. While it's certainly possible to arrange even large JavaScript code in a clear way, it always tends to get unwieldy.
I make intense use of IDE features all the time (refactoring, finding write access to fields, ...), and IDE support for JavaScript is too limited for me.
You will still need a tiny bit of JavaScript knowledge here and there. Your team definitely should learn CSS, and I'd recommend to learn it thoroughly - no matter which client side framework you choose.
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
In a few projects I'm working on, we're using GXT, because that decision was made a few years ago. Here's my opinion: If you need to build something that looks very much like a desktop app, GXT may be perfect, otherwise I wouldn't recommend basing the app on GXT.
You get the best performance with pure GWT, and if you know CSS, it's much more flexible. GXT has some nice features, but working around its limitations, significant performance issues (and sometimes its bugs) can be quite time-consuming. If you really need a special GXT widget, you can still build a pure GWT app, and then add just that one GXT/SmartGWT widget.
I suppose GWT is perfect for the requirements and objectives of your described project. GWT has JavaScript Native Interface to use native JavaScript. JSNI allows integrating GWT with existing JavaScript or with a external JS library. It solves these issues by allowing you to integrate JavaScript directly into application's Java source code.
My team really struggled with this issue after many false starts we determined that JavaScript can not really be avoided and it is not as bad to master as I feared it would be. The time it would take to ramp up on GWT would be around the same as it would take to ramp up on client side JS MVC framework.
We did consider GWT but dropped it because it will be harder to maintain in the long run for the following reasons.
What if the developers of GWT loose interest in maintaining it, it takes a really sophisticated skill set to maintain something like GWT.
Widgets that we might want might be available for something other GWT and porting to GWT might be more work than we want to do.
Modern JavaScript MVC frameworks are getting really mature with a lot of really cool features that make it easy to develop complex one page apps.
Browser will get better, JS frameworks will get better, it will be easier to higher front end developers ... etc.
We also evaluated dojo and dumped it because we felt that customizing it was going to be too hard for our team. Here is what we ended up with.
Twitter Bootstarp for a CSS / widget framework
A bunch of different jquery plugins wrangled up form various places online
JQuery, Backbone, Handlebars for the client side MVC framework.
If i was starting the project again today, I would go with AngularJS from Google, it really is an amazing approach for building client side web apps. Especially because of the clever use of Dependency injection in JavaScript and the two way biding and a bunch of other stuff. I was at a Throne of JS conference and the google AngularJS guys were saying that they ported a 17,000 line GWT app to 2500 line angularJS app.
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'm trying to learn JavaScript, but seem to be going around in circles regarding primitives, objects, functions, etc. I can code fairly well in Python, so the JavaScript part is now mostly about syntax and idioms.
I am overwhelmed by the choices and I'm not sure how to choose: Prototype, jQuery, Dojo, Node.js, Backbone.js, etc.
What would be good JavaScript framework/s to pick up after mastering the basics? At the risk of betraying my JavaScript naivete, I'd like one (or a combination of) framework wherein I can do asynchronous requests, data visualization, and UI implementation.
I can do asynchronous requests, data visualization, and UI implementation.
async requests means XHR2
data visualization and UI means HTML, DOM4 or <canvas>
If you want to learn and really learn stick with the low level basics and don't use bloated abstractions.
Sure when you use jQuery you might finish it faster, but you won't learn anything other then how to hack together spaghetti code using jQuery. Your code wouldn't be anywhere near as maintainable, stable or performant if you had just learned how to do it right with plain old javascript.
I wouldn't be right to not first say to make sure you understand JavaScript itself first. It's a rather unique language with both good parts and bad parts. If you take the time to understand closure, prototypal inheritance, this keyword, constructor functions, etc, you will thank yourself. JavaScript, The Good Parts is an excellent place to start. Anyways...
For basic DOM manipulation, event handling, ajax, etc jQuery is the clear winner. In the past, Prototype/Scriptaculous was a common alternative.
For more advanced browser-based applications, Backbone.js, Angular.js, and Ember.js are the winners.
Dojo, Mootools, ExtJS, and Knockout.js are some alternatives to Angular and friends... all with varying strengths and focuses.
There are countless libraries for charting. HighCharts is a popular one. For more advanced visualizations, check out D3.js and Raphael.
Node.js is different beast. It's a server-side, network IO platform. It's competitors are things like Python's Twisted and Ruby's EventMachine.
Of course this topic has been covered in great length here:
https://stackoverflow.com/questions/394601/which-javascript-framework-jquery-vs-dojo-vs
For the first steps I'll recommend jQuery, with it's intuitive syntax and ability to be extended with bunch of plugins, and for it's strong community and huge amount of articles, tutorials, etc. on the internet.
jQuery is a cross-browser JavaScript library that provides
abstractions for DOM traversal, event handling, animation, and AJAX
Try it at first, then you can go with other frameworks based on the task requirements like Raphaël JS for vector graphics,Processing.js for animations, etc.
I would suggest 3 main/major frameworks to consider. The reason I choose the following 3 is because they are fairly well supported, document and used, but more importantly - they all suggest a different coding style/convention.
Dojo
ExtJS (Sencha)
jQuery (UI/core)
Should be noted that any one of them can be fit to almost any coding style/preference, but if I were to create the perfect (from working with it standpoint) framework, I would do a hybrid:
Dojo's widget creation and styling + ExtJS layouting capabilities and stores-based data managemenet + jQuery DOM manipulation and AJAX support.
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 have started a new web application and have decided to use jquery as my primary javascript library... But still i want to get some pros and cons tips from SO users who used jquery ...
Pro's
Eliminates a lot of cross browser javascript issues
Can perform complicated Javascript operations in little code
Can easily add Ajax functionality to app
Has built in UI and effects libraries
Con's
Overhead of adding extra javascript to page
Learning curve may not be short for some developers
All pros, no cons.
The only thing will be the execution time overhead that jQuery adds to load its files and execute its functions, but compared to the Pro of coding cross browser compatible JavaScript it is nothing.
Also compared to other JavaScript libraries jQuery is one of the fastest and smallest out there. Their community is huge and you can easily find support and good documentation.
Pros:
Large community
Useful for selecting and iterating over sets of DOM nodes
Eliminates some inconsistencies between browsers
Makes it easy for inexperienced JavaScript developers to do relatively complex scripting tasks
Cons:
Regular updates that change existing behaviour
Some confusing fundamental API methods (e.g. attr() method: what exactly does it do? It certainly blurs the line between attributes and properties)
Encourages "chaining", which leads to code that is difficult to debug: in a long chain of jQuery method calls, there's nowhere to put logging statements, so you need a full-on debugger
Short list of supported browsers
A general point about general purpose libraries: they encourage developers not to attempt to understand the underlying problems that the libraries try to solve, leading to a tendency to think of the library as being magical and to use it for absolutely everything
Adds 70K of JavaScript to every page where it's used when often a few bytes of non-jQuery code would do
Performance is generally much slower than the equivalent (well thought-through) non-jQuery code
Quality of plug-ins is very variable
You've made a good choice, don't worry. jQuery is a very well designed library - it is powerful, clean, well documented, and extremely popular. Learn it well, and it will be a powerful tool in your arsenal.
That said, I think that to be really aware of its pros and cons versus other frameworks, you should first learn it well. Only a deeper understanding of a tool enables you real comparison with other tools.
The only con I can think of is the occasional memory leaks. It is a great framework on top of javascript and is not restrictive.
That said, jQuery UI is terrible to my taste and if your application requires highly interactive UI try Ext JS.
The pros and cons are really relative to what your new web application will be doing. If it is going to be JavaScript/Ajax-rich and requires cross-browser support then jQuery is the way to go - no doubt. However, if you are only going to use JavaScript very sparingly, then it may be over-kill to include a large-ish framework, and it would be more efficient (in terms of performance and page size) to code the JavaScript directly.
Pros: Lightweight, easy to use, good documentation, gets rid of nearly all cross-browser issues and normalizes the event model.
Cons: jQuery UI doesn't have much to offer, and the plugins are hit or miss.
If you're doing a very JavaScript-heavy Rich Internet Application, go with YUI or ExtJS. jQuery is an excellent DOM manipulation library, and is the best for highly custom UI work. But if you need lots of stock UI and a robust data management system behind it, you need a bigger framework to tie it all together.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.
By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.
Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.
Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with
A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.
I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.
I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).
An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .
I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.
There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.
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'm gearing up to do some Ajax style client-side JavaScript code in the near future, and I've heard rave reviews of jQuery when it comes to this realm. What I'm wondering is:
What are all the cross-browser JavaScript libraries out there?
What is the experience using them?
An excellent resource is Jeff Atwood's post on JavaScript libraries.
He lists:
Prototype and Script.aculo.us
jQuery
Yahoo UI Library
Ext JS
Dojo
MooTools
ALL the cross browser JavaScript libraries out there? You do realize that there are
well over 100 libraries out there, so you should narrow this down a little, IMO.
A good place to start is with Wikipedia's Comparison of JavaScript frameworks, which covers Dojo, Ext JS, jQuery, midori, MochiKit, MooTools, Prototype & script.aculo.us, qooxdoo, YUI, and SweetDEV RIA.
Prototype FTW.
I do like jQuery, but Prototype serves my needs most of the time. It may just be because I'm more familiar with it, but I seem to get stuff done faster in Prototype than in jQuery.
I want to report this almost unknown library entitled: "BBC Glow".
Other libraries are praised for bells and whistles, but Glow is about cross-browser support. The project has a clear statement about its goals, and there is also a browsers support table.
It is a solid starting point.
Most of the existing answers are either gateways to slimy marketing or libraries long past their due date.
What is conveyed as "cross-browser" is most often "multi-browser", meaning a small umbrella of browsers. Libraries such as Dojo Toolkit and Ext JS (anything by Sencha, really) are guilty of this behavior. jQuery used to behave similarly before some loud calls for sane code arose (the project still has a giant mountain to climb yet). "Cross-browser" most often refers to abstractions for the DOM and a few other APIs.
I've recently completed an HTML DOM library that covers a very wide range of browsers, which I think may interest the community here. The current list is:
Internet Explorer 5-9;
Firefox 1-13;
Opera 5-12;
Safari 3.1-5;
Chrome 1-4 (presumed to work on all Chrome builds, but Chrome versions remain difficult to test independently); which is the second-widest coverage I've encountered, just trailing another, which I will mention in the next paragraph. The library I've created is entitled: "Matt's DOM Utils" (Utils) and can be accessed via GitHub[[0]] or my own site[1]. It's fully modular and focuses specifically on DOM traversal while providing other utilities such as an Element::classList module.
However, the most comprehensive DOM library on the Internet is David Mark's "My Library". The library contains a giant pile of utilities, with coverage for nearly all browsers beyond Netscape 4. It has a pseudo-modular build stage, and can be very minimal if desired. It can be accessed via GitHub[2] or David's site[3]. I suggest to anyone reading this thread to give that API a thorough glance. I have learned immensely from both the author and the code itself.
If you want to jump on the same bandwagon everyone else does, jQuery is the end-all, be-all. You don't have to think, just listen to everyone else. :P
Personally, I use and love MochiKit. It seems to do everything jQuery does, but the philosophy is a bit different and the community is by far smaller. There are not tons of additional plugins, but there are some. It was designed with a lot of Pythonic style and functional programming constructs, so if that sounds interesting to you, you might want to take a look.
jQuery.
(Added so as to have an entry for voting.)
Loads!
jQuery, Prototype, Ext JS, Dojo, MooTools, YUI, Mochikit, the list goes on!
jQuery is very popular, and an excellent choice. However, some frameworks are better for some things, and others better for others. If you could give us a better idea of what you want to do, or how you will be using it (or even which other languages you use) we'd be able to give you a nudge towards one or the other.
The list that Dori posted is pretty comprehensive, and I don't think that it's possible to list all the libraries out there since there might be one being written even as I type (it seems to be a passion for some people).
I feel that going with jQuery and/or Prototype will probably get you off the ground and building neat stuff pretty quickly, and chances are that you will fall in love with them as so many of us have.
Gucci had Thomas Fuchs (the creator of script.aculo.us) create their website without using Flash, but check it out, it looks amazing for being JavaScript / CSS only.
A post about it is Gucci Relaunches on Script.aculo.us.
These libraries are so powerful and versatile (with some nice plugins) that you won't "hit the wall" and start looking to other libraries anytime soon.
I have also seen people do some nice stuff with Dojo and Ext JS, but I have never worked with them myself.
I like jQuery. Prototype is very similar. There are several others but I highly recommend you evaluate them yourself.
I prefer Mootools because it is lightweight and is based on Prototype, but like Jay said you should check them out for yourself.
Do have a closer look at MooTools.
I can't think of doing any JavaScript development without using jQuery (also take a deep look to jQuery UI).
jQuery is a good choice. It leans towards the 'skinny and speedy' side, and allows for some fantastic DOM manipulation.
Of the popular ones are jQuery, Dojo Toolkit, Prototype (with Script.aculo.us) and MooTools. I'd encourage you to test out MooTools unless you're on ASP.NET in which case I'd encourage you to check out the project I am working on (Ra-Ajax) which is a fully server-side binded Ajax Framework for ASP.NET...