GWT = Easy AJAX

LORRAINEJUG7/12 /2009

Who am I?

Olivier GérardinTechnical Director, Sfeir Benelux (groupe

Sfeir)Java / Web architect13+ years Java3 years GWTgerardin.o@sfeir.lublog.gerardin.info

Agenda

Little GWT showcaseWhy GWT?How does it work?Key featuresMyths & misconceptionsPointers, Conclusion, Q&A

GWT Showcase

Ext-GWT explorerPiano EtudesGWTUMLClarity AccountingContactOfficeMyERP, CompiereAnd more: Google Wave, Timetonote CRM…

Why GWT?

The web 0.0

Or “The Link Era” A web page is just a bunch of images and text with

links Links take you to a new page

1. Click on link2. HTTP request is built (from static link URL) and sent3. Wait for server to reply4. Server replies with HTML page (usually from static

storage)5. Response received blank screen6. Wait for entire page to load

“Dynamic” web with forms (web 1.0)

Or “The Form Era” In addition to images and text, a web page can contain

fields and other widgets A designated button submits the form

1. Fill in form2. Submit3. HTTP request is built (from form parameters and field

values) and sent4. Wait for server to reply5. Server replies with HTML page (usually generated on

server)6. Response received blank screen7. Wait for entire page to load

An example of form-based web application: Squirrel mail

Server side processing

CGI Basic bridge to OS commands Very ineffective (1 request = 1 process)

Web server with dedicated module (PHP, …) Scripted Usually interpreted

Application server with thread pool management (JSP, …) More effective JSPs are compiled at first invocation

ASP, perl, whatever…still requires full page reload

Java Applets

Plain Java application inside a web page!Server interaction without page reload!Rich UI (Swing)!But…

No consistent JVM support (MS vs Netscape/Sun) Sloooooooow start Hard to interface with the rest of the page Mostly seen as a gadget for irritating animations

There comes JavaScript

Client-side scriptingFirst usage: server-side form validation

Avoid server round-trip when invalid Instant feedback

With DHTML: polymorphic client page Menus, animations, etc.

Cross-browser (almost)Still no server interaction without

submit/reload

XHTTPR and AJAX

MS introduces Office Web Access JavaScript “clone” of desktop client (Outlook) Fetches data from server without reloading page!

How is that possible? New class: XmlHttpRequest Allows server interaction without page reload Response received asynchronously Interface updated through DOM

AJAX is born!

The first AJAX app: Outlook Web Access

JavaScript frenzy

JS becomes hype… Cool-looking, nice to use web UIsEveryone wants to do JavaScriptAny serious web site must have dynamic

content, auto-completion or other AJAX goodies

Widget sets / frameworks begin to emerge Scriptaculous, YUI, dojo, jScript, …

Anything seems possible in JavaScript JavaScript OS, AjaxSwing (WebCream), …

JavaScript hangover

Serious JavaScript hurts… Cross-browser compatibility nightmare

Fix in one, break in another JavaScript Guru required!

Developing/Debugging nightmare Weird runtime errors No static typing No refactoring

And.. Memory leaks Heavy pages Security issues

JavaScript confusion

Source: BrowserBook © Visibone

What to do?

Change jobs?Subcontract?Give up dynamic pages?

Back to web 1.0…Target a single browser?

Not an option for Internet appsGive up AJAX and use other technology?

Plugin required SEO unfriendly Proprietary environment / learning curve What server-side technology to match?

Use GWT !

GWT gives you AJAX without the pain of JavaScript development Takes care of cross-browser issues Allows full debugging (breakpoints, step by step,

inspecting/watching variables) Strong static typing early error detection Full refactoring options No browser plugin or mandatory IDE Short learning curve Simple RPC mechanism

But can communicate with any server technology

Program in Java…

GWT allows developing client-side web apps in full Java (with only a few restrictions) Leverage existing Java tools and skills Use any IDE (Eclipse, NetBeans, IntelliJ, …)

Program like a traditional graphical client (Swing, SWT, …) Widgets, containers, listeners, etc. Use OO patterns (MVC, MVP, observer, composite, etc.)

Test like any Java app Use standard Java debuggers Test with JUnit

… forget JavaScript!

JavaScript is only generated: For deployment To test in actual web mode

GWT’s promise is that the generated JavaScript app behaves exactly like the Java app And it does (most of the time)

(forgetting JavaScript not mandatory)

How does it work?

4 easy pieces

1) Java-to-JavaScript compiler2) JRE emulation library3) Java libraries4) Hosted Development mode

GWT compiler

Generates JS code from Java sourcesPerforms numerous optimizations

In most cases better than hand coding Can generate obfuscated (ultra-compact) code

JS plays a role similar to bytecode for compiled Java applications

JRE Emulation library

Provides a GWT-compatible version of Java core classes Most of java.lang Most of java.util Some classes of java.io and java.sql

For convenience only! No real I/O or JDBC!

Used when running in web mode Hosted mode runs in a JVM with standard JRE

GWT Java libraries

Utility classes RPC, I18N, …

Widget set Simple widgets (Button, TextField, …)

Base building blocks In most cases map to native HTML object

Composites = widgets built from other widgets Panels = widget containers

Panels enforce a layout (vertical, horizontal, grid, …)

GWT widgets: Simple widgets

GWT widgets: Composites

GWT widgets: Panels

Hosted / Development mode

Allows running GWT apps without converting them to JavaScript Code runs as Java bytecode in a standard JVM Embedded web browser emulates HTML rendering

platform-dependant… Performs extensive checks to make sure the code is

compilable to JavaScriptBottom line: if a GWT application performs as

expected in development mode, it will perform identically in web mode True 99,9% of the time

Key features

Easy development

During development, you are writing and running a classic Java app Use your favorite IDE All IDE features available (code completion, code

analysis, refactoring, links, Javadoc, …) Plugins help GWT-specific tasks (launching, compiling,

creating RPC services, …)

Easy RPC

RPC mechanism based on Java servletsEasy as:

1. Define service interface

int add (int x, int y);

2. Derive asynchronous interface

void add (int x, int y, AsyncCallback<Integer> callback);

3. Implement service interface (server-side)

public int add (int x, int y) {return x + y;

}

Easy JSON generation

Easy as:

JSONObject livre = new JSONObject();

livre.put("Titre", new JSONString("GWT"));livre.put("Pages", new JSONNumber(123));

JSONArray chapitres = new JSONArray();chapitres.set(0, new JSONString("Introduction"));

Easy JSON parsing

Easy as:

JSONObject livre = new JSONObject(json);

String titre = livre.get("Titre").isString().stringValue();double pages = livre.get("Pages").isNumber().doubleValue();

JSONArray chapitres = livre.isArray();String chap0 = chapitres.get(0).isString().stringValue();

Deferred binding

Appropriate code for user environment (browser, locale) is chosen at application startup time ≠ dynamic binding (implementation chosen at runtime) ≠ static binding (implementation chosen at compile time)

Code for every combination is generated at compile time

Advantages: Allows app-wide optimizations Compensates for the lack of dynamic (runtime) loading

Disadvantages: Increases compilation time

Deferred Binding (explicit)

Deferred binding can be called explicitly:

Foo foo = GWT.create(Foo.class);

Implementation is provided by either: Substitution: an existing class is designated Generation: class is generated during compilation

Easy native JavaScript integration

Implement a method directly in JavaScript:

public static native void alert(String msg) /*-{$wnd.alert(msg);

}-*/;

Call back Java methods from JavaScript Pass objects back and forth

Useful to wrap legacy JavaScript libraries

Easy Widget reuse

Create your own widgets: Extend existing widget

Works but not the most efficient Might expose unwanted methods from superclass

Extend Composite Recommended method

Use JSNI To wrap existing JavaScript widgets

Easy history support

AJAX app = single page “back” button catastrophe…

GWT solution: Encode app state in URL as “fragment”

E.g. http://myserver/myGwtApp#x=1;y=2

Save state:History.newItem(token);

React to state change (“back” button)History.addValueChangeHandler(…);

Easy i18n

Taking advantage of Deferred Binding1. Define interface:

public interface AppConstants extends Constants { String title();}

2. “Implement” interface (AppConstants.properties):

title = Hello, World

3. Use:

AppConstants appConstants = GWT.create(AppConstants.class);String title = appConstants.title();

Easy i18n

More advanced i18n1. Define interface:

public interface AppMessages extends Messages { String mailStatus(int n, String s);}

2. “Implement” interface (AppMessages.properties):

mailStatus = You have {0} messages in folder {1}

3. Use:

AppMessages msgs = GWT.create(AppMessages.class);String status = msgs.mailStatus(15, “Inbox”);

Easy debugging

In development mode, application runs as bytecode (just like any old Java app…)

So you can debug it just like any classic Java app: Set breakpoints Step through code Inspect variables Change variables …

Easy client-server testing

Integrated application server for testing RPC services Can be disabled to use external server

JUnit integration to run client-side test cases Hosted mode or web mode Full access to RPC services GWTTestCase, GWTTestSuite for automation

Selenium for automated GUI testing

Short dev cycle

Change client code: press “Reload”.. Done!

Change server code: Embedded server: press “Restart”.. Done! External server: hotswap /redeploy if needed

Easy scaling

All session data resides on client Similar to classic fat client

No session information on server-side Forget session affinity Add/remove servers on the fly Restart server without losing clients

“Easy” styling

Styling relies entirely on CSS Widgets have well-known styles Programmer can add custom styles

No shift from traditional HTML styling HTML/DOM build page “skeleton” Appearance tuned with CSS

Separate UI construction from styling With well thought styles, it’s possible to reskin completely

an application without changing one line of codeGWT styling has all the benefits of CSS with all

problems of CSS Be careful with brower dependencies!

Easy Google APIs

Project gwt-google-apis http://code.google.com/p/gwt-google-apis Libraries that wrap Google JavaScript APIs

Gears, gadgets, AJAX search, Maps, Visualization, Language, AjaxLoader

Standalone libraries (do not require JavaScript libraries)

[new in 2.0] in-browser development mode

Before: hosted mode uses customized browser engine Heavily customized

Only one supported browser per platform (IE on Windows, WebKit on Mac, Mozilla on Linux)

Platform-specific code (SWT) Difficult to keep up-to-date

Browser and hosted application share the same process

Most plugins don’t work (including Google Gears…)

[new in 2.0] in-browser development mode

After: Hosted mode shell runs outside browser Communicates with browser using plugin through

TCP

[new in 2.0] in-browser development mode

Benefits Use any (supported) browser/version on any platform Behavior closer to web mode No interference with browser plugins No more platform-specific stuff in GWT (one jar for

all!) Network protocol cross-platform possible

Dev mode shell on machine X, slave browser on machine Y

E.g. dev on Linux, test in IE on Windows…

[new in 2.0] code splitting

Before: monolithic download can become very big Slow startup times

After: Programmer can insert “split points” in code Hints for the compiler to place everything not required up

to split point in separate download Compiler divides code in several “chunks”, which are

loaded on-demandBenefits:

Initial loading time reduced 50% on average with a single split point

Allows on-demand module loading

[new in 2.0] declarative UI

Declarative construction of GUI using XML grammar

Allows automatic binding with Java code Assign widget references to Java fields Automatically attach methods as event handlers

Benefits: Clearly separate:

Static UI construction (XML) Dynamic UI behavior (Java)

[new in 2.0] resource bundle

Download multiple heterogeneous resources from server in a single request Images (already possible in pre-2.0) CSS Text Any binary resource

Benefits: Fewer round trips to the server Less overhead More responsive interface

Myths & misconceptions

Myth: GWT is a JS library/framework/widget set

GWT is not for JavaScript developersProvides only Java classes

Myth: GWT is a framework

GWT is a toolkit (set of tools)Frameworks may be built on top of it

Myth: GWT is applets

GWT app is full JavaScriptNo runtime/pluginNo JRE required

Myth: GWT is only for Java programmers

Yes, GWT uses Java as programming language…

BUT you can also see it this way:

GWT lets you write/debug/test/refactor AJAX apps with state-of-the-art IDEs and tools using a statically-typed object-oriented language

GWT makes it worth learning Java!

Myth: GWT generates poorly performing JS

The GWT compiler generates highly optimized and compact code

Hand written JavaScript might be marginally faster in some cases, but it’s not worth the trouble

Myth: GWT only works with a Java backend

GWT includes a simple and efficient RPC mechanism that relies on Java servlets

BUT it plays nice with any server-side technology that can handle HTTP requests (even PHP) Includes XML encoding/decoding library Includes JSON encoding/decoding library

Myth: GWT has poor UI components

Yes, GWT’s builtin widgets are minimalistic…

BUT it’s not the point to provide a complete and beautiful widget set

GWT provides the basis for rich and good-looking components

Create your own or use 3rd party See Ext-GWT, SmartGWT

Myth: GWT apps have long startup times

Not longer than any JavaScript appObfuscation reduces sizeDeferred binding loads just the necessary

code for the platform/languageGWT 2.0’s code splitting can split code in

several chunks Smaller initial download On-demand downloading

Myth: GWT doesn’t integrate with existing sites

GWT was designed from the beginning with the goal to integrate well into existing sites

Very easy to add GWT to an existing page Only a few lines of HTML Can “hook up” to any DOM element

Myth: GWT has poor skinning possibilities

GWT uses CSS for stylingCan reskin a whole application without

changing a line of code (done that!)Can split work between developer (behavior)

and designer (appearance)Caution: CSS can introduce browser

dependencies

Conclusion

Is GWT the future of web development?

GWT has passed reality checkWho wants to hand-write JavaScript for 6

different browsers (and maintain it) ?

GWT = easy AJAX now !

=

Pointers

GWT home (downloads, docs, FAQs, guides, etc.) http://code.google.com/toolkit

Google groups “GWT” group http://groups.google.com/group/Google-Web-Toolkit

onGWT: fresh news about GWT http://www.ongwt.com

LinkedIn “GWT Users” group http://www.linkedin.com/groups?gid=129889

Shameless self-promotion

Thank you

Questions?