Hi, I'm Andrew Bowers, product manager
for developer products at Google.
I'd like to talk to you about Google Web Toolkit.
Browsers are capable of a lot these days,
but to take full advantage of the browser
you need to be an expert in JavaScript
and three or more browsers and their quirks,
and potentially have a lot of time on your hands.
Alternatively, you could have a good set of tools
to help you out.
Google Web Toolkit provides a set of tools for just that.
It lets a developer write an AJAX application
in the Java programming language,
taking advantage of all the tools available for Java,
and then cross-compiles that code into highly optimized,
plain old JavaScript.
JavaScript that's not only optimized per browser,
but can be served from any web server.
Let's see what development with Google Web Toolkit looks like.
Let's look at one of the App Engine demo applications
that uses Google Web Toolkit, or GWT for short.
It's a sticky note application that allows surfaces
to be shared among logged-in users.
I'll go into Eclipse and open up this project.
The source package structure is divided
into client and server packages.
At deploy time, Java files in the client directory
will be cross-compiled into JavaScript,
and run in our users' browsers.
Files in the server directory
will be run as bytecode on the server.
Because my client code is also modeled in Java,
I have the option of using the same objects
across both my server and my JavaScript client.
GWT provides higher-level abstraction
on top of JavaScript, enabling developers
to be more productive by coding against widgets
and events that work across all major browsers.
It's worth noting that you can also mix
handwritten JavaScript into GWT source code easily.
But for now, I'm just focusing on the Java aspects.
Part of the development-time magic of GWT
is the hosted mode browser.
During development, you interact with your application
in the hosted mode browser, which runs your Java bytecode
on the backend to render your user interface
in an embedded browser.
This has two benefits.
First, because we're running Java bytecode,
it means you can debug as you would any Java applications,
setting breakpoints, inspecting variables,
and stepping through code.
I'll set break points...
create a new note to trigger one of them...
and then inspect the variable containing the note contents.
Second, you can develop using the familiar
edit-refresh-view programming model of JavaScript.
You don't have to compile your Java source
into JavaScript to see changes in the browser.
I'll change the size of a sticky note in my code...
refresh the hosted mode browser...
and create a note with the new dimensions.
Google Web Toolkit provides an optimized RPC mechanism
for Java, which means you don't have to worry
about the complexity of low-level HTTP interactions.
Alternatively, you can also easily use JSON
to communicate with the server.
When you're ready to see what your application
will look like in production,
you compile your source code into JavaScript.
Google Web Toolkit handles the browser implementation
differences for you, and creates an optimized JavaScript file
per major browser.
The code is contained in the cache.html files.
Browser-specific JavaScript means a user
downloads only what they need.
An Internet Explorer user doesn't download code
needed for Firefox.
The compiled script is heavily optimized,
including compiler optimizations like method inlining,
code size reduction, such as removal of comments
and unused code, and of course, the final script
is obfuscated and minified.
Now, if you want to inspect the final JavaScript
in a human-readable form,
simply compile with the "pretty" option selected.
Just be sure to switch back to obfuscated before deploying,
as this results in faster code and less JavaScript
for the user to download.
I've shown you the basics of developing
with Google Web Toolkit,
the benefit these tools can have
on a web developer's productivity,
and the performance gains you can achieve
in your AJAX application.
To learn more,
visit code.google.com/webtoolkit.