We Keep Coding

Providing no-js fallbacks for clientside MV* frameworks

I just recently got introduced to MV* frameworks and have taken a chance to try out Ember.js with the TodoMVC app tutorial they have on their site.
I was considering using Ember for one of my upcoming projects (a Ruby on Rails CRUD app, similar to Twitter in some of the functionality), but I'm still a bit confused and before I take a final decision I would love it if somebody could clear the following concerns:
Is it a good idea to use such an advanced framework as Ember for a medium-sized multi-page CRUD app? Will it improve development time and maintenance compared to an interactivity layer built with jQuery's DOM manipulation and AJAX capabilities? Or is using Ember (and the like) only good when developing complex single-page apps (e.g.: Grooveshark)?
Considering the app will be developed using Rails, and assuming Ember will be used, is it going to be possible to offer a fallback with basic functionality for browsers with JavaScript disabled and/or for search engine crawlers? Will it require code duplication or other dirty tricks? Do you know of any technique that can be used to achieve it?
Will it be possible to adapt the website for mobile browsing (using only CSS) with valid results, or will the overhead imposed by running Ember on the phone make it hard for the device to render the website in a way that keeps it responsive?

We're in the middle of a pretty big Ember project right now, so here are my thoughts on your questions.
We've found Ember to be really productive for creating rich UIs for our single page app, but I don't know that it's going to be that much more helpful if you're creating an app designed for traditional multi-page (viewing pages, submitting forms, etc) layout.
I think this is the clincher - Ember is completely JS-based, so if you need to support browsers without JS, you'd basically have to write a parallel application. If this is a hard requirement for your app, I think Ember (or any MV* JS framework) would be out of the question
We've had very few performance issues on mobile - our site is fully responsive and renders on everything from Blackberries to the latest Chrome on desktop with good performance.

#Scott Rankin, has addressed most of the concerns with going with the Pure Ember approach. I'll add one quick way to make this decision.
Go with Ember/MVVM if the application is behind a login. Then you don't have to consider search engines, as the content is generally private and not supposed to be indexed.
For SEO you have to build atleast part of your content such that it is indexable. A good example of this is the Discourse application. They use Ember but also send down some generated html along with the app html slugs, so that search engines can index them. You can read about their approach here.

We have a different approach which can be seen as a fall back: We pre-render a static version of each page in the application (daily scheduled task). This static version is stored on the server as HTML file. Whenever we sniff as spider/ robot user agent, we deliver that version.

What combination of Javascript/Css/HTML frameworks and libraries do you recommend?

I'm looking to modernize my web development with some cool libraries, but there are so many tools that do different things, often with overlap, that it is hard to decide.
I'm not interested in one framework but more in a combination of various tools that work well together. I've looked at resets and normalizers, boilerplates, HTML frameworks, and grid framework, CSS authoring frameworks, CSS frameworks, Javascript frameworks, DOM manipulation, AJAX, resource-loading, feature detection and UI libraries, Javascript toolkits, server-side pre-processors and client-side pre-processors, and framework generators; It's beautiful chaos.
Also I'm looking forward to using SASS and Coffeescript or something similar so a combo including those would be nice.
Update:
I've decided on JQuery for DOM manipulation and I would also appreciate some kind of kickstarter/bootstrapper.

Depends for what. Use what you know best!
However, here are a few recommendations...
The Feather-Weights
For quick, no frills and no overthinking development, I'd recommend:
Underscore for general JavaScript Development
BackBone for client/server communication (using jQuery or Zepto.js for AJAX calls) and designing your models and event buses
Jasmine for JS testing
SASS for cooler CSS
HTML Frameworks, what's that? :)
CoffeeScript is indeed great, if you want to go down that road. If you are interested in CoffeeScript, you may want to look at Google's Dart as well, but it's fairly recent.
The Heavy-Weights (Batteries Included)
If you're building a rather complex web-application (speaking more along the lines of thousands of lines of code here), you need to take it up a notch and in that case I'd recommend you look at:
The Dojo Toolkit
Sencha's ExtJS
The whole Google Closure Tools stack
Dojo and Closure can be integrated in complex build systems and their compilers will allow for a good modularization of your codebase while keeping it easy to produce a strongly optimized deliverable. They also both contain their own module loading system, so you won't need additional libraries like Require.JS, and will only load the parts you explictly tell them too if you use a custom build. But be warned, they're definitely more hands-on and have a steeper learning curve.
The Google Closure Tools are definitely very comprehensive and are as batteries included as it gets, but they do not necessarily make development easy for you: they give you the power, but you need to know what you are doing.
Bootstrappers / Kickstarters
Some solutions offer to "kickstart" your project and to prepackage for you a collection of some of the above tools, sometimes offering you some customization, so you can easily get started and don't need to maintain your own kickstarter up to date with new versions:
Bootstrap
Foundation
HTML5Boilerplate
Kickstart
Skeleton
WARNING: I haven't really tried these kickstarters extensively myself.

Obviously, the answer here depends greatly on what you're building. If you're really getting into front-end engineering and making single-page web apps, I'd recommend reading Addy Osmani's blog. Recently, he's been blogging and giving a lot of talks about javascript MVC/MVP/MVVM systems, as well as scaling javascript apps.
If you want a laundry list, read this article where he gives his ideal stack:
Backbone.js for lightweight MV*
Require.js + AMD + RequireJS text add-on (to assist with external template management)
Backbone.js LayoutManager (if you require some more intelligent layout management)
jQuery for DOM manip.
Handlebars.js for templating, unless you're doing something simple, in which case, opt for Underscore's Micro-templating
r.js for handling script optimization
Jasmine + Jenkins for testing and CI
Node.js + Express (speaking of Node, Miller Medeiros has an excellent write-up on how to use it as a build script)
MongoDB as a noSQL data-store
This is surprisingly close to what I use myself and I can attest to the quality of these libraries and this as a whole-stack solution.

jQuery for JavaScript. Many great UI plugins for UI controls in addition to the code jQuery API that hides the browser differences in the DOM.

Angular JS - Awesome. MVC Framework, great for quick SPA's
jQuery - DOM manipulation - good for effects (fading, toggling etc.)
Don't rely on it too much though.
Angular JS, jQuery - Some argue they work well together.
Backbone.js
Ember.js
React.js - Uses JSX, not JS, but pretty much the same thing
<script type='text/jsx'>
//JSX
</script>

Pure JavaScript-based clients

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.

Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.

I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.

Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.

Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.

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/

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