We Keep Coding

I'm interested in using Ext.js, but troubled by a number of issues. Is there a better alternative?

Ext.js is of interest to me because it appears to have a fairly complete widget set (though I've certainly run into shortcomings of the widgets after a very short time). The problems I potentially have with it, however, include these:
in my opinion it's very ugly, and looks like a cross between a Windows UI and some PHP content management system (yes I know I can write my own theme, but there may be limits to what I can change, and it may not be as easy as it should be, and I'd rather work with something that is clean, elegant, and attractive out of the box.)
the graphs currently use Flash, which limits the clients it can be useful on (version 4 promises to resolve this problem)
the license is a bit restrictive, which is not an issue now, but it makes me think twice about becoming intimately familiar with a tool that I may not be able to use in the future.
Honestly the look & feel is probably the biggest issue to me: I've seen in the past that developers (or companies) who don't place a high value on aesthetics often can't be bothered by other 'details' either.
So: is there a other better alternative?
UPDATE:
Another problem with Ext.js, is that it seems to be an all-or-nothing proposition. That's one reason I'm not looking seriously at SproutCore, which in other respects is awesome. (Well... it needs some performance improvements, but it'll get there eventually I think...)
Cappuccino seems to be the same way: you're not using it on a web page, rather you're building a Cappuccino app that just happens to use the web as its runtime environment.
In other words, ideally I don't want a JS version of Flex: it's own little walled garden. jQueryUI would be ideal if it were more complete, since it doesn't break with normal web development methods and paradigms. But if walled gardens are all there are, I'll live with it.

If you are looking for a RIA-Framework you shouldn't use jQuery(UI). Instead use one of the following frameworks.
Qooxdoo (www.qooxdoo.org): Pure Open-Source RIA-Framework with the most of the features of ExtJS. There were coming up some interessting new themes in the last weeks
Cappuccino (http://cappuccino.org): Nice framework with a nice GUI
ZK (http://www.zkoss.org/): ExtJS like RIA-Framework
SproutCore (http://www.sproutcore.com/): Apple-Style RIA-Framework

I undestand your pain - I use to got same - in ExtJS I saw only problems (those what you mentioned, and belive me much more others), however because I was a little forced to use it, I started to use it and I followed in love - It very complex and optimal solution for javascript driven apps.
You can go and look for alternatives like jQuery (I was there for 1 year), dojo, and others frameworks, but whoever says that they are better than ExtJS, he rather did not have ..... time to know ExtJS
It my very subjective opinion

I dont know much about PHP, and I am using ExtJS with ASP.Net MVC, they fit well. I wish I could use an integrated JS Widget set, but Jquery UI widget set was not rich enough when I last evaluated and I dont think it still is. But it is at least included in the last version of MVC.
My only complain about ExtJS would be the number of user extension controls that you need to use, I'd like to see those as part of ExtJS core widget set, but they are not, but still distributed with the library. ExtJS is a very nice fit for a cross-platform Rich Web Application. I would recommend trying ExtJS, I have really no complains about it other that what I already said above.

jQuery, Web Application Framework?

For the longest time I've used jQuery to hack together web sites. Now I'm interested in making a web application (one page load for the entire site to function, like Gmail).
Are there any jQuery Frameworks or practices that I can leverage to build my application so I don't have to recreate the wheel, or hack something together as I go?
Thanks

One of the (not so) many options is JavascriptMVC, which is pretty cool and I've used it for one midium-size project.
It's website is pretty discouraging, but give it a chance and watch the video. One possitive aspect is that it's creator always answers really fast in JMVC's google group.
But, actually, if I had to remake the project I mentioned, I would not use it, as jQuery provides (almost) all JMVC's functionality, you just have to get used to it. For an example in how to handle big apps with jQuery, I would recommend you to watch this video between others of Alex Sexton and other members of the yayQuery podcast.

I honestly don't know how someone could say jQuery provides almost all of JMVC's functionality. Yes, you can do a lot of similar things with jQuery, but you would have to write it an maintain it yourself.
Here's a quick list of what JavaScriptMVC provides that jQuery does not: (read more of them at http://jupiterjs.com/news/javascriptmvc-features)
Dependency Management
Building / Compression
Logging
Organized Folder Structures
Package Management
Code Cleaning
Functional Testing
Client Side Templates
A bunch of delegatable special events (drag-drop, hover, resize, etc)
A bunch of dom utilities
Language Extensions
An awesome widget factory
Documentation

Have you looked into Sammy.js? It's an mvc framework built on JQuery and is very beginner friendly. http://code.quirkey.com/sammy/

Supporting Multiple JS libraries

I have developed one of my modules using Dojo. Its gone really well and I have done a lot of custom plugins and server support in Dojo to allow AJAX calls, RPC + SMD communication with my server.
However, now that I am getting onto the user side of things, I am seeing that jQuery has some really nice already built plugins. Do you think it is possible to support both JS libraries realistically without it being a massive problem?
What kind of integration can I achieve? Does anyone have experience in this?
I have probably written somewhere in the region of 30k lines in Dojo for my Administration panel...

jQuery is very good about not messing with the prototypes of built in javascript objects (unlike Prototype), this allows it to be used with other libraries quite easily.
A source of potential conflict is jQuery's use of $ as a shortcut for jQuery. I'm not a dojo user, but if this conflicts with dojo in some way, there are instructions addressing this.
That said, I think you'd be better off looking at these jquery plugins and rewriting them and porting them to dojo. I'm sure the dojo community would appreciate it, and it would give you experience. It'd also make your application a little slimmer in the waist area.
Edit: I've noticed a couple answers trivializing the download speed of adding an additional library. I'd take this with a grain of salt.
As developers we tend to see only the extra 10ms it takes to download the library over localhost, or from our development server on a 100 Mbit LAN. The download speed is not so trivial from California to Virginia, or especially from USA to Europe. Additionally, it adds further burden on your client's javascript engine. If they are using a 1-2 year old good computer with Safari or Chrome, this would be negligible, but if they're on IE, FF2, or some versions of FF3 the difference can be severe, or at least measurable.

When using 2 libraries (both of which, I'm sure - were designed to be used by themselves) you have 2 main worries:
That one library will effect the other.
That having a dependency on 2 libraries will bloat your pages.
In this case, I would bet that #1 is not going to happen. Although #2 is still a concern.

Most of the popular JS libraries can be scoped to their own global shortcuts. JQuery can be set to not initialize the $ variable. JQuery aside, I hear that Dojo and Prototype can work together without conflicting.
Regardless of what combination of JS libraries you decide to use, the best way to get information on compatibility issues is to hit the mailing lists relevant to the JS libs you'll be using with each other.
http://docs.jquery.com/Using_jQuery_with_Other_Libraries
http://www.dev411.com/blog/2006/06/13/dojo-and-prototype-together

Query.noConflict() makes for fairly easy interoperability because you can redefine $. As hobodave draws attention to, Prototype is lousy in this regard (because you can't easily just redefine $ with Prototype). I am not sure but I think Dojo doesn't have any issues of it's own and plays nicely with others out of the box (please someone correct me if that's not true).
The biggest problem I've had is the number of "must have" libraries written in specific frameworks, such as for things like sophisticated graphing that would be non-trivial to implement from scratch.
Bloat is bad, but compared to image sizes JS script sizes are of negligible concern (because it's so small and connections are so fast and it's only on first page load if you get your caching right, it's almost a non issue). I'd say maintiainablity being more of a worry, and it's a matter of deciding if you want that must-have-plugin that you don't have the time or inclination to reinvent in whatever framework you are using.

I have used Prototype, jQuery, and ExtJS on several projects (for various reasons) and almost always use jQuery and ExtJS together. One way to limit trouble would be to avoid mixing libraries in any given page - keep Admin page to dojo and new pages to jQuery - but what fun would that be? :-)
I find few problems when integrating jQuery and ExtJS. I pick a framework for classes/objects/inheritance (I use ExtJS) and stick to it. Then, I use ExtJS to create most widgets and I use jQuery for low-level DOM manipulation and simple widgets. Again, I cannot recall running into conflicts when using two libraries, but FireBug is a good tool to uncover suspected causes of such conflicts.

Best Technologies for AJAX Web Development

I have some experience in AJAX development, mostly on .NET and MooTools. However, I want to learn more and see what others out there thought about the various other options available. I am looking more for advice about the front end. The back end, I will most probably be coding it in .NET using c# and WCF services.
Please feel free to provide me as much information as you can. Also, I would appreciate any links to resources.
List of Options (feel free to add)
Write my own Javascript
Use a framework like MooTools, JQuery, etc. Which one is better?
Use Google Web Toolkit. Am I tying myself to the limitations of GWT? Or are there not limitations?
ASP.NET AJAX
WPF (Will this run on non-IE browsers?)
Flash (it'll be a pain to learn action script)
Thanks
Jaspreet

Writing your own Javascript often means reinventing the wheel when it comes to trying to attain cross-browser compatibility. Frameworks such as jQuery and MooTools take care of much of that grunt work for you.
Personally, I would suggest picking a Javascript framework or using GWT, but really it's just a matter of personal preference at that point, much like choosing a programming language. Pick that one that is best for your purposes, or that you're most familiar with.

I'd go with jQuery.
jQuery will be bundled with the next version of Visual Studio. Google uses jQuery. jQuery has the largest user-base of any of the frameworks out there.. And speaking of not re-inventing the wheel: jQuery also has the largest plugin-repository of any of the frameworks out there.. Including its own official UI library which is in constant development.
.. And if you're a fan of books; there's 3-4 books about the framework out currently.
Oh, yeah! Check out Douglas Crockford's website for great vanilla JavaScript tips and tricks.
Just my two cents :)

jQuery
prototype
MooTools
dojo
GWT
ExtJS
Those will all have you working with very solid code, which is usually the best way to improve your own skills. And don't forget all their extensions/plugins.

I would recommend jQuery. It's more extensible and light-weight than most other JavaScript libraries I've seen (and you can have it Google-cached with the AJAX APIs).
For Flash-based AJAX web apps, Flex is a better solution.

Since this is a fairly subjective question I will put in my 2 cents.
I've developed using the Dojo toolkit and found it very well rounded. However, if you don't do a custom build on your library it slows everything down. It has a steeper learning curve than other frameworks, but seems to sit pretty close to heart of Javascript.
But this isn't an advertisement for dojo. I'm working on a Ajax web app currently and my goal is to try and avoid using a framework. Why? A few reasons.
The biggest reason is complete control over the code. Not that I don't trust toolkits, I just like my custom code. I don't have any code that I don't use, and all of my abstractions are custom made for my purposes. At times I am in fact reinventing the wheel*, but its always a bit different because it's purpose built.
The other big reason is the amount of knowledge I gain. I'm confident that I could pick up any framework much faster, because of not using one for a project. I understand so much more than I did previously. Before It was more like a voodoo mystery box, and now even frameworks make more sense to me.
The fact of the matter is if you do any non-trivial javascript you will end up with a framework (or a mess). In reality it may not be the fastest way to write web apps, but it isn't all that hard with a little practice. You can be amazed at what creative things you can come up with that didn't exist before.
*Reinventing the wheel is a terrible analogy that we all use. We reinvent wheels all the time. First made of stone, then lighter wood, tires, etc... My truck doesn't have the same wheels as my sedan.

Like other responders I prefer to use frameworks, but my favorite is dojo -- clean and well-designed architecture, good books (my favorite being Matthew Russel's), and a particularly impressive approach to using browser extensions (such as Google Gears or Microsoft Silverlight) if the user has them installed, while falling back gracefully (e.g. to Ajax-interfaced server-side storage) if no suitable browser extensions (or sufficiently advanced browsers, with HTML5 support) are present.
Dojo is, currently, slightly less popular than jquery (e.g., [jquery ajax] has 8.4 million hits on Google Search, vs 4.3 million for [dojo ajax]), but that's still way popular enough to ensure it won't go away any time soon;-).

You must check ExtJS.
Most libraries I've seen have usable core but lack the widget/control library that will blend-in with each other. Sure you can get a vast number of controls for jQuery, but do you have the time to find out which ones have intended functionality and tweak their visual appearance to match the rest of controls? ExtJS gives you just that. Core is core. It works and it works great. But the vast selection of compatible and functionality rich controls is the main driver that will make your life easier.
I've used ExtJS with Asp.Net and WCF services and it was a really nice experience overall. You will need some time to get to know ExtJS component model to extend it even further (as you would need to do the same with other libs), but when you do, you start loving it even more.
One more thing: since MS ships jQuery with MVC it doesn't mean it's the best. It only means it's one of the best (and much better than Microsoft's in-house Ajax) but with the most relaxed open source license.
Edit: Now that Silverlight 3 has shipped it became apparent it will shake things a bit with its offline support and rich graphics support. As well as standalone desktop like web apps. Definitely something to consider...

Please note that WPF has nothing to do with ajax.
AJAX = Asynchronous javascript and xml
WPF = a windows-only UI display technology. The only option there for in-browser use is to create an Xbap. The more-suited-for-the-web counterpart is silverlight (say, like flash but from microsoft), so perhaps you should look into that as well... it's like using flash, but with familiar MS technologies.
Concerning your question about which framework to use in case of ajax: I prefer jQuery. It's short syntax and chaining allow you to reach your goals very fast in an intuitive way.
Also, GWT is a Java framework that also renders stuff on the client, as far as i know. So you would have the limitation of Java as backend language...

GWT has made considerable leaps and bounds over the past 7 months. The mutiple GWT widget libraries have received a good deal of attention, and Google's work on the library has been impressive. Going GWT limits you to:
Using GWT widgets
Possibly becoming a GWT widget developer
The benefits include:
Coding in Java
Debugging in Java
Skipping the parts of JavaScript that make you pull your hair out
GWT is the step past AJAX. It buries the HTML / JavaScript so that you don't need to deal with it, but also provides access in case you do want to deal with it.
Overall, you will spend less time trying to get small things working, and more time adding awesome to your application.

there is also prototype.js

Try the Yahoo! User Interface Library (YUI)

Pick a library to learn, then pick up the others--but I don't think I'd reinvent the wheel.
I picked MooTools and have picked up jQuery/Prototype since. (Picked Mootools because their site, at the time, was the only one that validated, figured clean html meant clean javascript).
Side note about MooTools:
An often overlooked feature of MooTools is the download builder. You can download just enough of the framework source to get your AJAX working, and nothing else.

There's the BBC's open source javascript library called Glow

Ajax - Library or Plain Javascript

I've been doing a lot of reading about AJAX, and wanted to know which is the better way to approach things: by using a library such as jQuery using their built-in methods or creating JavaScript without a library for AJAX?

Ajax has a lot of quirks when working with the XMLHttpRequest Object. When you start to work with it, you will not see it, but when it is out in a production environment, it will bite you in the butt. Browsers, browser version, user settings, the type of server, type of request, and much more can affect what needs to be coded. Libraries tend to solve most of the problems, but they all are not perfect.
I always tell people it is great to work with a tutorial to see how the XMLHttpRequest works. After you have learned how to do it naked, work with a library that fits your needs.
Eric Pascarello

Why create a library when plenty already exists? If you create a library it is going to take time and effort and you'll end up going through the same hurdles others already have. And unless your company is trying to sell an Ajax library then stay away from writting your own plumbing code.
I am currently using both JQuery and Microsoft's Ajax in my site and have found that they are both feature complete with plenty of options of different ways you can set up the communication.

If you ask this question on comp.lang.javascript you'll get lots of different answers, many of which disdain the commonly-used libraries (one quote sometimes taken slightly out of context is Richard Cornford's post on c.l.js in 2007: "Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not the
best source of advice on designing systems that use javascript.")
The argument for libraries is they abstract away most of the differences between browsers and allow for cross-browser scripting. The argument against libraries is that they are bloated code with quirks of their own, so you'd have to learn just as much to use them well as you would to use cross-browser techniques in raw javascript. If you are writing lots of Javascript that you're going to reuse in multiple places, and you're trying to make websites that load quickly and use a minimum of excess bandwidth (e.g. if you have pay-per-use webhosting like via Amazon S3 or nearlyfreespeech.net), then it's probably worth stripping whatever you're going to use out of a good library, tweaking it, and using that.
I was all psyched about Prototype for a while, but then decided I just need a few simple building blocks. I tend to use Doug Crockford's simple JSON library, and then some of Fork Javascript's minimalist libraries as needed (primarily FORK.Ajax), and do the rest myself from scratch or reusing routines from an earlier project that I've honed to something that works well for me.

why wouldn't you use library if it meets your needs. you're using .net framework, or java JRE, or php built-in functions...
you can create your own javascript for the purpose of learning, or to do something libraries don't offer. but for regular development, you are much quicker with library and you get cross-browser compatible JS without having to code cross-browser support manually, it's already built-in into the library