I posted the following to the OCJUG mailing list on January 2.  About
the only change I would make now is to add in a comment on how the
recent open sourcing indicates our ongoing commitment Google has.  I
am not on the GWT team, but I am pretty stoked on the product.

[And now we listen to Scott from January.]

Hi, all - sorry for the delay, but I wanted to run this by our press
dept to make sure that my comments were reasonable.

GWT is being used internally at Google.

Google Checkout and Google Base are both public facing GWT apps that
have made it out, and there are others under development.  Further, we
are investing in GWT development, as evinced by the Googler presence
on the GWT mailing lists, and the pace of change in the toolkit.

I can put in my personal perspective on why I have championed GWT for
various projects here at Google.  These are just my opinions, not
Google public statements, but I suspect that other teams have used it
for similar reasons.

I do not love javascript, nor am I wedded to AJAX.  I prefer Java as a
language for many server side projects, though not all Java is good.
For example, I believe SOAP to be overly engineered, overly complex,
and overly tedious to use across platforms and languages.  (This is
based on my experience in a former life integrating Java, C#, and Perl
code via SOAP.  Not the way of joy.)

Web applications do have an important place, and users want
interactivity.  Google has to create those applications, and thus we
have to build, buy, or help outsiders develop tools that will let us
do so, in the way that most helps our users.  (I know, every company
says that.  From where I sit, though, it is not optional - users want
those rich apps, and they want them distributed, interactive, and
collaborative.)

So, why isn't <your favorite google app> written in GWT?  Maturity and
time.

The toolkit is still pretty young, and features are getting added with
each release.  Since rebuilding an existing app requires substantial
engineering effort, we need to see a payoff, either in usability,
speed, or functionality.  Then, we need to port all of the existing
features that do not exist in the toolkit.  That is not cheap, and
thus every app manager has to evaluate whether this is a good idea.
For an existing app, the cost is high, so it will take a while.  For a
new app, or one that has no AJAXy features, on the other hand, the win
is clearer, and it is more likely to happen.

In summary, GWT lets us work with a familiar paradigm, but gives the
user better results than than plain server side Java has classically
given.  Further, it lets us spend our time on business logic, rather
than browser-specific AJAX work.

This is a big win.

Scott

--
Scott Ellsworth
scott_ellswo...@alumni.hmc.edu

Google Irvine is hiring Java developers.  The toolset used depends on
the project, but we do interesting things in interesting ways.  Drop
me a line if you are interested.

'The barbarian is thwarted at the moat - Scott Adams.'