Rationale
There are various points why we might (or not) want to use plain GWT for the next AdminCentral implementation. Following tries to summarize the points and answer some open questions.
Evaluation
IDE/build support
All major GUIs provide support for GWT one way or another
configuration is sometimes still cumbersome
maven plugins exist
Communication
as of GWT 2.1 JSON is used as a protocol for communication between server-client instead of RPC
as of GWT 2.1 the transport is optimized to generate minimum traffic (eg. delta transfer for modified objects)
Development
learning curve is not too steep comparing to alternatives
due to increasing popularity, it is possible to find developers who work or used to work on GWT projects easier then for alternatives that requiter GWT and some extra framework (Vaadin, GXT)
Performance
Runtime performance
the GWT team repeatedly shown that all their development is bent around runtime performance and memory requirements
Compile Time performance
Not the foremost point of the focus for GWT development
Integration
It is generally possible to mix plain GWT with other frameworks that build on top of it. However bringing such framework for single component is probably not worth of the overhead in most cases.
integration requires deep understanding.
using other projects like gwt-exporter allows exposing custom GWT based functionality as plain JS and allows interaction and integration without need for re-compilation
integration via above mentioned export requires active selection of integration points by the main module developer
documentation for the export is non existent apart from 3rd party tutorials and team consists of 2 people only
developing more complicated components from scratch is time consuming
some other extra components exists in the incubator already e.g. TreeTable
using plain gwt allows for inclusion of Gadget spec and deployment of AdminCentral add-ons via Google Gadget mechanism as shown for example here for the eXo GWT client