Which UI framework for Grails-based web service backend?

Using Grails to create a JSON-serving backend is a no brainer - especially with the insane levels of backend-specific productivity improvements offered by Grails 2.0 (interactive command line, WAY easier mocking and better reports in tests, integrated GORM-friendly multi-database access, JSONBuilder improvements).  Unfortunately, I'm still struggling to figure out an equivalent 'no-brainer' for what to use on the frontend.  Decoupling the backend is definitely the way to go; generating views via grails commands allows me to get the app in front of the user quickly, but at a cost of closely coupling the UI to the backend server - not an ideal design when the UI framework ecosphere is in such flux.  Forum diving isn't clearing up candidates either; each toolkits' "kitchen sink" leaves me wondering how much of the actual effort to pull together a decent UI they're leaving out of the attached code snippets alledgedly used to display the widget.

Right now I've got seven frameworks to consider (GSP is my current fallback if I have to get something out fast; tho serving JSON to GSP completely erases its advantage talking to a Grails server).  They are:

Vaacdin
Pivot
SmartGWT
jQuery
RichUi
GrailsUi

zk - I actually re-wrote the demo app used for this toolkit with Grails but it's been a while so I don't recall all the details; XML is used to describe the UI and Java is used to write actions.  Once the app is cached on your local machine it's pretty zippy.

Pivot and SmartGWT are the most Swing-like; with both good (lots of model-ready widgets) and bad (didn't we already decide downloading Java to run inside a browser was a bad idea?).  One Stackoverflow commenter said SmartGWT was 'JSON ready out the box'; my personal experience was otherwise.  Pivot's table sample code makes it appear JSON ready but I'll have to write something to be sure.

Vaadin is HTML5 (aka the 'Silverlight Killer') which the smart money is betting will be the framework that makes the mobile app market irrelevant.

The forums say zk is Grails 2.0 ready today; Pivot's developers are still working on the plugin.  I'm not sure about SmartGWT.  Again, as I'm returning JSON this is not quite as important, however if I do integrate with Grails (and thus the cloudfoundry plugin) then I gain the advantage that updating (and other cloud-goodness like provisioning) is just as easy for the UI as it is for the web service.

jQuery gives me a wealth of javascript widgets that unfortunately also gives me a dependency on large amounts of javascript.  On the upside, I can share (some) code with mobile clients (zk-mobile is supposed to have this advantage too .. *supposed* to) using jQuery mobile, and, combined with PhoneGap, I could potentially use some of this code for a (semi) native client downloaded/purchased via appstore.

RichUI and GrailsUI - these are basically plugin wrappers to the yahoo javascript UI framework; one of which paradoxically leaves out what's arguably the most important widget in a UI framework, the table widget.

The best way to find a winner in this group is to just go ahead and write a UI in each.  Fortunately, hosting multiple web service backends on cloudfoundry gives me a solid foundation on which to try each of these platforms.

Edge cases and new code

Spectacular failures in software development still plague the industry. Sometimes I wonder if this is a less a problem of the tools or more a problem of managing the design of the thing; or rather, over-managing. I came off of a large, failed, multi-year project at my former employer. On the surface, it appeared everything was done correctly as far as design went; lots of detailed use cases and database designs. Looking back on it, I see that a lot of time was spent on managing edge cases; the kinds of things the software is meant to manage only rarely or only due to an extreme exception. The app itself was a straight-forward CRUD app looking to replace an older client/server app; thus, most of the business rules should have already been in place. The thing about older apps is that all the edge case rules they contain were never designed into the thing in the first place; they came in as time went by. The hubris back in the 'waterfall' days was that the app was never expected to be majorly refactored over time. Now many of the tools for web development (frameworks, IDE's) have the expectation that refactoring will be done and support those efforts. Thus, the development of greenfield apps may best be realized through a modified 80/20 rule that promises only to deliver the 80% on V1/launch, and that the 20% (which will take 80% of the time) will be delivered incrementally with heavy unit testing and use-case churn expected during that time. Grails is a great tool that's designed to 'get something in front of the customer really fast' while providing a RAILS framework which enables much simpler refactoring and the incremental addition of services to manage edge cases.