Google’s late-but-inevitable entry into this arena is certainly no copycat. The Google Web Toolkit (GWT) is nothing less than a completely original approach to web development that allows server-side Java developers to take their skills to the JavaScript domain… without having to write any JavaScript.

In short, you write, test and debug your client-side code in Java and then use a specialized compiler to convert it all into cross-browser JavaScript for use on your site.

How’s it work?

You can write you client-side code using the usual core Java classes in the java.lang and java.util packages, as well as a nice library of classes that come with GWT that let you access the same browser features that are available in JavaScript (the Docment Object Model, alert boxes, setTimeout, XMLHttpRequest, etc.).

You also get a bunch of Java classes for adding widgets to the page, from simple buttons to complex drop-down menus and trees. All of these widgets offer events that you can subscribe listener objects to, and write Java code to respond to them.

When you’re ready to test out your application in a browser, you simply compile your classes in your Java IDE of choice and launch the GWT Shell, which pops up a specialized browser window and loads your application. On Windows, that browser window uses the Internet Explorer rendering engine, whereas on Linux it uses Mozilla.

The GWT Shell acts as a go-between between your Java classes and the special browser window, allowing your application’s client-side logic to run within the browser even though it is implemented in Java, not JavaScript. This small miracle actually lets you test and debug your client-side logic as you would any other Java code! Set breakpoints to pause and step through client-side event handlers, write unit tests to verify that your user interface works as designed. It all just works.

At this stage, your application is still a collection Java classes, and the final development step is to compile those classes down to efficient cross-browser JavaScript code. The compiler that comes with GWT actually reads the source code of your classes and generates the equivalent JavaScript code!

You can then take the generated JavaScript code, along with your static HTML, CSS and image files and dump them on a server as you would for any other web site. The resulting code is entirely self-contained — no browser plugins or special server technology required.

What about AJAX?

As I mentioned, the class library does give you access to the XMLHttpRequest object normally used in AJAX applications, but GWT also offers an even slicker method of communicating with the server.

In addition to your client-side code, you can write Java server-side code. Because it doesn’t get converted to JavaScript, this code can use the full capabilities of the Java platform, and any additional class libraries you may require.

In your client-side code, you can set up classes that are able to communicate with your server-side code. When your application is compiled, GWT will automatically generate all the JavaScript needed to communicate with the server on the client-side, and will compile your server-side code to a set of Java Servlets.

You can deploy these Servlets on any Java web server, and let GWT do the rest. GWT manages the conversion between JavaScript variables on the client-side and Java objects on the server side, and again it all just works.

GWT also includes a full browser history management system, allowing you to involve the browser’s Back and Forward buttons in your application’s navigation, even though the browser never actually leaves the page containing your applications.

Sticking Points

Google has definitely put together an impressive platform with GWT, but as one would expect (especially from a beta product) it’s not perfect:

GWT detects and supports browsers by their user agent string.

You must rely on Google to add support for future browsers. Right now, for example, GWT applications are incompatible with IE7. You can hack the toolkit to treat it like IE6, but that’s the extent of what you can do to support new browsers.

The bundled GWT widgets make extensive use of tables for layout.

If you want you application to generate a standards-compliant document structure, you’ll need to write your own widgets, which isn’t a happy prospect.

GWT was written to work with Java 1.4 or later.

As such, it does not take advantage of Java 5 features like annotations and generics. This adds some redundancy and bulk to the code you must write, especially when working with the AJAX features of the library. For example, each server-side access point in your application requires you to write an interface to describe the servce, another interface to describe the asynchronous version of the service, and finally a class to implement the service. Using annotations, you could do it all by writing just one class.

The development shell does not support Mac OS X.

Google is saying that Mac support is planned, but for now GWT development is limited to Windows and Linux. Compiled GWT applications run just fine in Mac browsers, of course.

Unclear best practices for security and performance.

By masking the client-server division, GWT could lead unwary developers to make some serious security and performance blunders. You really need to know what you’re doing to use GWT effectively.

But the biggest thing lacking in GWT is an example of a finished, real-world application running in the wild. No doubt Google is hard at work on its next big project using GWT, but for now at least GWT is unproven technology.

Kevin began developing for the Web in 1995 and is a highly respected technical author. Kev is a world-renowned author, speaker and JavaScript expert. He has a passion for making web technology easy to understand by anyone. Yes, even you!

http://www.sitepoint.com Matthew Magain

I haven’t decided yet whether to be impressed or appalled. It’s an ambitious project, but I do question whether becoming completely reliant on Google to resolve any cross-browser issues for you is a good approach to take long term. Sure, you could go fix up any of the generated code afterwards, but what would be the point then?

So am I to understand that GWT is not a server-agnostic technology? I can’t have a GWT front-end supported by a PHP-based back-end without doing a LOT of work?

Anonymous

There is a problem with printing this page!

http://www.sitepoint.com/ Kevin Yank

So am I to understand that GWT is not a server-agnostic technology? I can’t have a GWT front-end supported by a PHP-based back-end without doing a LOT of work?

You certainly can. You’ll just have to use the simpler XMLHttpRequest object for performing server requests to your PHP scripts (or whatever). All of the client-side stuff (widgets, events, DOM, etc.) is completely server agnostic.

The only non-server-agnostic feature of GWT is the support for “Remote Procedure Calls” (basically, automated AJAX), which is designed to communicate with Java servlets on the server.

I do question whether becoming completely reliant on Google to resolve any cross-browser issues for you is a good approach to take long term. Sure, you could go fix up any of the generated code afterwards, but what would be the point then?

Actually, you can do one better. All of the client-side framework code is open source, so if you have a cross-browser issue Google hasn’t fixed you can fix it yourself and recompile.

http://www.sitepoint.com/ Kevin Yank

Actually, you can do one better. All of the client-side framework code is open source, so if you have a cross-browser issue Google hasn’t fixed you can fix it yourself and recompile.

Are you sure that’s the case? From what I can see, the majority of the open-source client-side code is written on top of Google’s closed-source browser compatibility layer. Only in a couple of places do they use their JSNI (JavaScript Native Interface) facility to drop to “bare JavaScript” in their component library.

Given a bug or forward-compatibility issue in Google’s compatibility layer, the only way around it would be to reimplement the affected widgets using JSNI yourself, which as Matt mentioned would defeat the purpose of GWT anyway.

Fredrik Carlsson

The simpler “XMLHttpRequest” is that a part of GWT?

Peter Wu

I don’t like the idea of using Java to program AJAX applications. This is not only over-complicating the matter, it lenghtens development time.

Imagine the difference between save and see it in action, and save, compile, and see it in action. There is just an extra step there.

Besides, if you are building an application using another language such as PHP/ASP.NET, how would you manage to do AJAX with GWT unless you have someone who knows JAVA in your team?

So if I am going to manage a project using GWT, then all my developers have got to be Java developers otherwise the entire project will be quite complicated.

I personally disagree with the move of using Java everywhere on the web. It’s pure blindness and dumb.

I would like to say that Yahoo and MS are at least making the right move here. MS is planning to make Atlas completely agnostic, and it will benefit everyone.

On the other hand, why’s Google sticking its nose into the Java edge without considering the wide variety of other development languages? It’s dumb.

http://www.oozm.com itsjoker

Agree Peter. Also a Java developer will cost a lot more. However, it is truly an alternative to hide your javascripts.

magixMan

Quite an interesting concept that might be suitable for building a large scale distributed application. I still can’t get my mind around whether it is worth the extra complexity for most applications. Browsers have come a long way and cross-platform JS is just not that difficult. Working in JS is much easier for most folks than Java. Still the real worry has been expressed in other posts. What happens when things go wrong? I don’t look forward tracking down subtle bugs that might occur in the translation to JS or that are browser specific.

Yogi

Hi,
As I’m looking for starting point to develop GWT application, I got many aspects without any proper approch. For a small application, you have to write so much code and it takes long time to develop it. It’s much easier to do using JS,HTML/DHTML.
And what is the point to write java code for JS,HTML/DHTML which later convert to JS, HTML?

GWT Application is running over the Mozilla but not running in Microsoft IExplorer,projrct is running in Apache-Unix environment.
What is the solution..

samanta

GWT Application is running over the Mozilla but not running in Microsoft IExplorer,projrct is running in Apache-Unix environment.

Application is running on Mozilla.

I am getting below error: when I am running the application in IExplorer6.0

I need the solution..

samanta

see below the error

table style=WIDTH: 100%; HEIGHT:250px” cellSpacing=0 cellpadding=0>

Easyrules

Its a good Article.

OJ

Hi Kev, you say that the client-side code is server-agnostic, do you have any step-by-step process so we can extract the widgets from the JARs? Thanks.

John

The point of coding in java vs. js is that it is complicated to program in many different browsers, and yes you’re letting google take care of cross-compatibility for you. Also using java in your applications is much better because it’s object-oriented. Yeah sure you can use “classes” in js, but it’s still a procedural language.

Biju

Dojo is a better Ajax framework compared to GWT.

hq tube

Soon I feel the pressure break and hot seamen races into my mouth. Then I move my moth away and his dick is spraying my neck and chest with seamen, but the water from the shower washes me quickly. hq tube