GWT Java AJAX Programming

simon_kehler writes "The Google Web Toolkit (GWT) is a Java AJAX framework that provides an easy to use programming paradigm for web developers using the Java programming language. It is one of the more recent entrants into this field, but has been gaining a lot of traction and popularity. GWT Java AJAX Programming authored by Prabhakar Chaganti and published by Packt Publishing addresses the use of GWT to build ajaxified user interfaces. The author gently introduces the reader to GWT and then leads the reader through a series of tasks, each of which shows how to perform an useful action with GWT." Read below for Simon's review. GWT Java AJAX Programming author Prabhakar pages 240 publisher Packt Publishing rating 8 reviewer simon Kehle ISBN 1847191002 summary A great book for learning the different facets and features of GWT

I am a software architect working for a startup that is evaluating the use of GWT for a new project. I lead a team of experienced Java developers that are comfortable working with Swing and have reasonable familiarity with Struts. We have looked on with envy at all the nice things you could do with the AJAX integration built into web frameworks in languages such as PHP and Ruby. When I came across GWT we decided to take it for a spin and see if your team would be comfortable using it. The documentation that comes with the GWT download is a bit sparse. I was looking for a more in depth intro to the framework and came across this book. this seems to be the first print book on the GWT framework.

The book is divided into ten chapters. An introduction to GWT and its download and setup is provided in the first chapter. The author then shows how to create random quote GWT application in chapter 2. This is a nice example that immediately gives you the flavor of what its like to work with GWT. It shows you the steps involved in writing and running a simple GWT app. Chapter 3 details the service interfaces that you need to create as a part of any GWT application. These are the heart of how the AJAX mechanism works in this framework. Chapters 4-6 go through a lot of tasks that show you how to create increasingly complex user interfaces using the GWT framework. Chapter 7 deals with creating custom widgets that can be shared across applications. Unit testing for GWT applications is covered in chapter 8 (Yes, you can unit test your AJAX apps!). I18N and client XML support are dealt with in chapter 9 and finally chapter 10 shows how to deploy your applications.

This book moves along at a fairly rapid pace and is a quick read. The examples chosen for the tasks are well thought out and show different features in GWT. There are several really cool and innovative examples in this book: Password strength checker, uses colored check boxes to visually show the strength of a password. A very different way of using a check box. Dynamic Lists, change list entries as selections change. Flickr label, recreates the cool label widget that was made famous by Flickr. Sticky Notes, you create post it notes in your browser and drag them around to place them as you want (uses GWT drag support.) Mona Lisa jigsaw puzzle, rearrange Mona Lisa (uses GWT drag support.) Moo.fx, uses moo.fx javascript library for effects (uses JSNI.) Color Selector, integrates Rico Javascript library into GWT (uses JSNI.) Calendar, a very cool mac os x like calendar widget (Creates a compound widget.) Weather, another widget (creates a compound widget.) I18N, displays the country flag based on the locale (uses i18n support.)

I had played around a bit with GWT before. So some of the things in the book were not new to me, but there were several things that I found very useful. GWT provides a way to integrate Java and Javascript (you can call into Java from JS or from JS to Java) called JSNI (Javascript Native interface). The JSNI examples in this book showed how to integrate with moo.fx, Rico and scriptaculous libraries. This was great as we have some homegrown Javascript libs that we would like to continue to use even when we move to GWT. If we can try to hook those in and call them from GWT, that would be sweet! The ability to create widgets that can be shared across applications is very important to our project. The author creates two widgets in chapter 7 — calendar and weather. Both of these were very cool and reminded me of my mac desktop widgets! The weather widget uses Yahoo's weather service to retrieve the information that is displayed. Again, very nicely done. The ability to unit test is another thing that is crucial for us. GWT leverages and extends JUnit to provide this support. However, this is one of the parts of GWT that people do not seem to be using much. Searching on the GWT forums reveals as much confusion about this topic. This book contains a chapter that shows how to unit test a GWT application. The examples are quite simple, but the creation of test suites was a good one, as I had struggled with that before. I really liked the author's coverage of deployment. He first shows how to manually deploy a GWT application. this gives you a feel for whats involved and what's going where. Then he automates that using ant and finally shows how to deploy from within eclipse. This is very useful as I have tripped over deployment before.

Overall, this is a well written book that was very useful to our team. There were a few examples that we had implemented differently than the author — table sorting, paging and in place editing of the tree nodes. I18N is a big topic and the author covers only one way to use it. It would have been nice to have a complete chapter devoted to that topic, as this is a topic of particular interest to us as we work with a multitude of languages. This is a very developer oriented book and assumes that you know Java, HTML, some Javascript and some CSS. Of course if you did not know those topics, you probably wouldn't be too interested in GWT! This is not a book that dives into the internals of how GWT works or tries to impress you with all the nitty gritty of the GWT architecture. The author provides you with ways in which you can accomplish most common tasks that require GWT. They may not be the only way to do things using GWT but it gets you comfortable using GWT and thinking about how you would actually apply it for your problem. I really enjoyed reading this book and its focus on the practical side of using GWT.

You can purchase GWT Java AJAX Programming from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Web 2.0

[D-Cypell]

I have also looked at GWT and it is pretty innovative. While everyone with ways to abstract the Javascript functions to deliver 'web 2.0', 'ajaxified' applications, Google has treated Javascript, HTML and CSS like the 'byte code' of the web application.

Personally, I think it would be nice to see Google work on a standard for 'application markup'. Perhaps lending a few developers to help move the XUL forward.

I can see the benefits of web based applications, but having to write a tonne of script to achieve such a basic HCI function as drag and drop is not whree I want to be.

Re:Web 2.0

[jesterman]

Personally, I think it would be nice to see Google work on a standard for 'application markup'.

I would simply preferr a rethink of the whole web application thing. I mean, I'm *so* tired of having to deal with tons of languages that don't work very well by themselves (imagine work together with others) and are not properly implemented in browsers....etc

I look at old designs such as the Unix with its services (read: small applications) and shell, wich provide the means to have applications interacting with each other in non-obvious ways and it makes me (pardon) sick of having to deal with such a messy place that is web applications.

Frankly, I would be very excited to see a single idiom on server/client side talking to each other without layers of translations and the like, and, of course, fully enjoying the power of scripts on browsers.

IMHO, there are many things wrong when it comes to web app, and I'm not sure the efforts are going in the right direction.

Re:Web 2.0

[namityadav]

Hmm .. Since reading about GWT the first time (And creating an asynchronous CLI module from it within an hour), I have been on and off about GWT. I wasn't sure I wanted to rely on one more framework that I may have difficulty debugging later. Since then I've come to appreciate GWT more and more.

For a Java developer like me (Who never feels comfortable with Javascripts), GWT is valuable. A swing like UI library like GWT gives you easy RPC and Serialization support. That's all that you need as an application developer. The client side becomes an extension of your back-end application instead of being a complex and difficult to understand layer. Experienced developers of Java server applications can very easily develop client side with this toolkit, something that they could never do (Without major change in focus) with the traditional frameworks.

One strong point of GWT is that it re-enforces the point that the client side should ONLY deal with the presentation of data. Nothing else.

I am not sure how capable it is at implementing very rich interfaces (Since I've only targetted small sub-modules with it so far). My feeling, though, is that you should be able to create some really rich applications with it. Perhaps, if your application has a long-term future, modifying or building your own widgets based on the toolkit shouldn't be far-fetched either.

Re:Web 2.0

[Shawn is an Asshole]

Something I'm more impressed with is Echo2, which is dual licensed under the LGPL and MPL. Try out the demos. It's possible to do some really cool stuff with it. I started learning it a few days ago, so far it seems really nice.

All of these frameworks are mostly overkill

[roman_mir]

There is nothing that can't be done with a few lines of very simple javascript, here is a simple synchronized xml request test page that loads a simple data file and evaluates data quickly into an array and a map.

Test code:

<HTML><SCRIPT LANGUAGE="JAVASCRIPT"><!--
function handleHTTPResponseForArray(str) {
// UNPARSED TEXT EXAMPLE
handleHTTPResponse(str);
// ARRAY EXAMPLE
var textarea = document.getElementById("textarea2");
var result="";
var array=eval(str);
var hashMap=new Array(array.length);
for(var i=0;i<array.length;i++) {
hashMap[array[i][0]] = array[i][1];
result += "key:" + array[i][0];
result += "\t\t\tval:" + array[i][1] + "\n";
}
textarea.value=result;
// HASH MAP EXAMPLE
result="";
for(var i=0;i<array.length;i++) {
var tmpKey = array[i][0];
result += "key(" + tmpKey + ")=" + hashMap[tmpKey] + "\n";
}
textarea = document.getElementById("textarea3");
textarea.value = "Use result as a hash map with key/value pairs:\n";
textarea.value += result;
}
function handleHTTPResponse(str) {
var textarea = document.getElementById("textarea1");
textarea.value=str;
}
function handleHTTPError(str) {
alert(str);
}
function makeHTTPRequest(url, onLoadFunc, onErrorFunc) {
var request;
if(window.XMLHttpRequest) {
try {
request = new XMLHttpRequest();
} catch(e) {
alert(e);
return;
}
} else if(window.ActiveXObject) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e1) {
alert(e1);
return;
}
}
}
try {
window.status = "ECSM:AJAX:Connecting to "+ url;
request.open("POST",url,false);
request.setRequestHeader('Content-Type','applicati on/x-www-form-urlencoded; charset=UTF-8');
request.send(null);
window.status = "";
} catch (e) {
window.status = "";
alert(e);
return;
}
if (request.status==200)
onLoadFunc(request.responseText);
else
onErrorFunc(request.status);
}
function testHTTPRequest() {makeHTTPRequest("mockups/load-data.txt", handleHTTPResponseForArray, handleHTTPError);}
//-->
</SCRIPT><BODY><input type="button" value="Run Test" onclick="javascript:testHTTPRequest();">
<table>< tr><td>Unparsed Text:</td><td><textarea id="textarea1" rows="10" cols="100" style="background

Re:All of these frameworks are mostly overkill

[Anonymous Coward]

There is nothing that can't be done with a few lines of very simple javascript, here is a simple synchronized xml request test page that loads a simple data file

You keep using that word. I do not think it means what you think it means.

(Especially after posting 75 lines of ugly Javascript.)

Re:All of these frameworks are mostly overkill

[roman_mir]

Ooh, goody gumdrops, /. never ceases to surprise me. Seriously, I wasn't going for Funny in the previous post.

For my next comedic number I will solve a quadratic equation.

Re:All of these frameworks are mostly overkill

[s2jcpete]

Following your logic, anything beyond assembler or the abacus would be overkill to.

Re:All of these frameworks are mostly overkill

[roman_mir]

aaah, no. Javascript frameworks pack mostly unnecessary bloat. Only use what is absolutely minimally necessary to build your solutions, don't fall into these 'be all' frameworks.

Re:All of these frameworks are mostly overkill

[s2jcpete]

Are you posting via lynx?

Re:All of these frameworks are mostly overkill

[roman_mir]

No, FF, it's bloated like hell. I am also posting from work, where I am given a WinXP machine to use, terrible bloat. I am posting bloated HTML content over a bloated HTTP protocol too, which runs on top of bloated TCP/IP etc. None of which undermines my earlier point that most solutions do not require complex frameworks and can use simplest solutions.

Some may need more complex frameworks, but most do not.

Re:All of these frameworks are mostly overkill

[LuisAnaya]

Well, please reconcile the statement "simple java script" and long list of javascript code that you posted? That was a heck of a punch line :).

Re:All of these frameworks are mostly overkill

[s2jcpete]

Your earlier point reads like a grumpy old man saying that you should walk to school uphill both ways. From machine code -> C -> C++ etc. They were all developer to make OUR life easier, and turn out code quicker with less bugs.

Re:All of these frameworks are mostly overkill

[roman_mir]

Like it or not, that WAS simple Javascript. I usually write Javascript that reevaluates the entire page DOM and does something strange with it. You can see it for yourself.

Re:All of these frameworks are mostly overkill

[roman_mir]

Fitting all solutions into similar frameworks is fine and all, but it often unnecessary bloats the application, forces the developers into unnatural (for the application at hand) coding patterns, prevents developers from using sufficient and most efficient solutions to the problem. I think learning the basics is necessary to make sound decisions. Once you understand the basics of the technology, then you can make your own educated guesses whether a framework in question is worth your time.

Re:All of these frameworks are mostly overkill

[Sancho]

Frameworks like the GWT allow users to use their current experience in a language (in the GWT's case, that language is Java) and transform it into whatever the current fad is (in this case, AJAX).

Yes, they're a little bloated. So is code written in Delphi, C++ Builder, Visual Studio, etc. Obviously, the more you abstract away the details, the more bloat you get. What you have to evaluate is whether or not you get enough of a benefit from that abstraction. In the GWT's case, that benefit is likely to come in the form of rapid development and use of a mature codebase through a translation layer.

Re:All of these frameworks are mostly overkill

[AKAImBatman]

That was NOT a simple example. That was a full-up demo with all the bells and whistles in place. You don't make your point by showing the bells and whistles! The message ends up getting lost in all the excess code.

Oh, and you do realize that setting window.status no longer works on many browsers? It is considered a security hazard.

Re:All of these frameworks are mostly overkill

[Sancho]

I have to concur. I saw "simple code" and then more than a page worth of code in my browser and thought, "Simple, my ass." Sure, it may be simple for Javascript, but if the GWT actually ends up making it easier to code, I'm all for it.

Re:All of these frameworks are mostly overkill

[roman_mir]

Yep, I know about the window.status I wrote the code in question as a demo for an intranet project long time ago, so it has all the bells and the whistles and still fits into a couple of pages of text.

Re:All of these frameworks are mostly overkill

[Anonymous Coward]

That was the point you obviously didn't get.

Re:All of these frameworks are mostly overkill

[Anonymous Coward]

No, I think I understood him just fine. You, on the other hand, may want to read the rest of the thread. Especially the part where the poster defends his post as serious.

Re:All of these frameworks are mostly overkill

[roman_mir]

Until the moment you need to do something that the framework does not do, and then you have to debug into it to add your features and introduce modifications, which of-course will not be supported by the newer versions of the framework. As I said, most things that need to be done can be done with very little of very simple javascript.

Re:All of these frameworks are mostly overkill

[Anonymous Coward]

You shouldn't fight with yourself.

Re:All of these frameworks are mostly overkill

[SwiftOne]

Until the moment you need to do something that the framework does not do

One point of a framework is to standardize the things that you do, and do all the prep work to do them. There are good frameworks (ooh, a compiler that does linking!) and bad frameworks (Yay! Frontpage!). To say that a framework is a bad idea because you might need to work outside it is to argue a vague point. Pick the right framework and that doesn't happen.

Now, if you said GWT doesn't handle that, and provided examples, you may well have won me over. As it is, you sound like someone that wants to implement all libraries yourself in assembler. (Yes, a strawman exaggeration. No, I'm not claiming you said that. I'm saying I have nothing better to work with from your argument)

most things that need to be done can be done with very little of very simple javascript.

GWT provides me:
* ease of maintenance
* tested compatibility across browsers
which your "simple javascript" does not. Were I a JS programmer that kept current on all the trends, I would likely agree. GWT likely isn't written with you as an audience though.

That you don't understand why your comment was marked as "Funny" ( I know I thought you were trying for it) indicates to me that you're missing something.

Re:All of these frameworks are mostly overkill

[roman_mir]

That you don't understand why your comment was marked as "Funny" ( I know I thought you were trying for it) indicates to me that you're missing something. - understanding something and expecting something are different things and I think you are missed the difference here.

For everything else the answer is here, I don't want to repeat myself.

Re:All of these frameworks are mostly overkill

[as6o]

Programming down to the metal is fine and all, but it often unnecessarily complicates the application, forces developers to write a lot of very tedious code repeatedly, and prevents developers from concentrating on the business functionality of the application. I think AJAX is AJAX and that developers should use the technologies and patterns that they are most familiar with in order to be the most productive. Besides, they almost all support AJAX to some degree and usually abstract away all of the rote and boring JavaScript code so you usually don't need to bother with it and can spend your time concentrating on the problem at hand.

;)

Re:All of these frameworks are mostly overkill

[MikeFM]

Using a framework is like using functions or objects. If you go crazy with the concept then it'll end up being crap but if you use it in a way that makes sense then it'll help you a lot. You don't want to create a function for a single line of code you're going to use once but you may want to create one for ten lines of code you're going to use a dozen times. You don't want to create a class for a single on line function you'll use once but if you begin building up application logic in a way that needs to have self-contained data and logic that'll be reused and built on then objects become very good. Frameworks are just the same. If you're making a page with a few lines of Javascript on it then a framework is overkill. If you're creating a complex application then using a framework will save you time and make your code easier to maintain - assuming you choose, or build, the right framework.

Re:All of these frameworks are mostly overkill

[MikeFM]

You'd be assuming that the average developer writes better code than the framework developers. My experience is that the average coder, through lack of time, laziness, or inability, writes pretty crappy code. On average you probably get lighter, and better, code by using a framework. Of course I've seen some pretty crappy frameworks too.. but you can choose not to use those. :)

Re:All of these frameworks are mostly overkill

[erik.martino]

It's true that you can get far by a small amount of code without a framework. However in my experience, as complexity grows, javascript suddenly gets very hard. It is important to encapsulate complexity, which your code show nothing of. The main advantage of GWT is static types, and the ability to use a known language and mature development tools. The GWT framework is too low level in my opinion though. I don't wan't to download dubious 3rd party libraries that may or may not work.

Re:All of these frameworks are mostly overkill

[mr_e_cat]

Well I agree with you anyway, even if no one else does. Javascript is an underrated, powerful language. The sheep will have moved on from Java to the next 'Silver Bullet' in 5 years. How trendy is C++ now?

Any good programmer can code whatever subset he requires in the time it takes to understand and work around all the generalisations and limitations in a framework.

These Java guys have all their self esteem tied up in their choice of language and can't bear the thought that there are other ways of doing things which are no worse and may be better.

Re:All of these frameworks are mostly overkill

[phaggood]

> I don't wan't to download dubious 3rd party libraries that may or may not work.

Tho your example may be more security minded, it made me think immediately of Delphi, the most productive app development system I ever used. My favorite feature was the visual form inheritance; with it I was able to visually generate data-aware interfaces in minutes. The only weak link in Delphi for me was the 3rd parties; Borland would release a new version with must-have upgrades and I some important 3rd party widget (chart-generator, validator, etc) would be incompatible, with the vendor promising an update "real soon now". It's just that experience that makes my java (and now GWT) development so much slower; I now encapsulate EVERYTHING in my own wrappers to isolate core services and GUIs from these external libraries' idiosyncrasies.

Re:All of these frameworks are mostly overkill

[design1066]

notice how your script will only work in internet explorer

Re:All of these frameworks are mostly overkill

[roman_mir]

This script was tested in IE6 and FF 1 and 2 and it works in both. I never write for IE only.

Re:All of these frameworks are mostly overkill

[Anonymous Coward]

Yes I should.

Re:All of these frameworks are mostly overkill

[Serveert]

From what I have read, the GWT compiler attempts to minimize javascript code on the client by only providing code that it uses.

JS Framework bloat

[Anonymous Coward]

Folk may laugh. There was a time recently when slashdot linked 1MB of script, now it's under 300K and around 70K compressed. Scripts may be cached but first time dialup visitors are still in for a long wait with 70KB of script.

AJAX is Irrelevant

[Anonymous Coward]

Actually, it's worse than irrelevant - it is a real pain. From a lead programmers point of
view in a web-based billing environment, it's a chore trying to keep the kids focused on the
(perhaps boring) task at hand and keep them using clean, simple, classic CGI programming
techniques. Every so often, someone wants to start using AJAX and automatic form reposting
and a bunch of stuff that makes their code unreadabale and unmaintainable by the rest of the
crew. Invariably, I ask them to describe the problem that could not be solved with a
snippet or two of Javascript, and invariably, they start spouting nonsense that basically
boils down to them wanting to fiddle around with AJAX.

If you ever start waking up thinking that perhaps you'll take a gander at AJAX, just repeat
three times: "I do not need AJAX for anything", take your shower, get a nice cup of coffee,
and continue on with your day.

Re:AJAX is Irrelevant

[Locutus]

it was most likely your title that started the tone for your responses. Myself, I didn't read your thread because of the title.

LoB

Re:AJAX is Irrelevant

[MikeFM]

AJAX shouldn't be a pain. Maybe your programmers are overly excited about it and want to throw the kitchen sink at every problem but that doesn't make the concept a bad concept. My general rule is to make it work without bells and whistles first, and then you can use clean methods like CSS and Javascript behaviors to improve the apps for people that have CSS and JS.

Saying you don't need AJAX for anything isn't right. If you really can make your applications more user-friendly and avoid using bloated technologies like Java and Flash then you have a good reason to use AJAX. A well written AJAX'd app shouldn't be any harder to maintain other than obviously needing your programmers to be properly trained in writing clean XHTML, CSS, and Javascript. You do need to have a more diverse skillset to develop modern websites than you did in 1997 but then website development required more skills in 1995 than developing a Gopher site before that but I think most people think the work is worth it. :)

A simple example that comes to mind would be developing a web-based chat program. Sure you can force the entire page to reload every few seconds and when the user submits but it'll feel clunky and annoying. Using some Javascript to monitor presence and incoming messages, as well as sending outgoing messages, without any page reloads makes the experience a lot nicer for users and is more like a non-web app.

Re:AJAX is Irrelevant

[enomar]

For most AJAX frameworks, I'd agree with you. However, with GWT, almost everything is AJAX, so you're never asking yourself, "how can I use AJAX here?" It's closer to writing a traditional client-server app over RPC. The AJAX is very much "under the covers", so you never think about it.

Re:AJAX is Irrelevant

[DrFalkyn]

Every so often, someone wants to start using AJAX and automatic form reposting and a bunch of stuff that makes their code unreadabale and unmaintainable by the rest of the crew.

Well, there's you're problem. You shouold never look at the javascript code GWT generates anymore than you should look at the Java bytecode javac generates. Raw javascript might be OK for small applications, but for large, complex, apps it gets increasingly difficult to read, debug and maintain. And you can't build applications with scripting languages. At least, not without a massive headache.

javascript is Irrelevant

[Anonymous Coward]

A web app should function without js. Have the kids write things properly and let them add javascript later.

My experience with GWT

[hansamurai]

A couple months ago, I was looking into different AJAX frameworks to leverage for an internal web app my group supports. Right now, we basically have a giant tree that is loading about 40,000 nodes from a database at once and then using CSS to show and hide our hierarchy of nodes. This was starting to become inefficient at load time, taking a couple of seconds for the tree to generate and then for the browser to render it. So I started investigating dynamic loading trees using AJAX and then doing a new database call for every node expansion.

First thing I looked at was GWT because I'm a Google fanboy. Their demo seemed great, and we started getting hyped up that our solution was right in front of us. I started tinkering around with the demos, basically hacking their tree demo into something usable for us to get started quickly. Anyways, it didn't take long to find out that to make things worked, everything had to be basically compiled into this horrendous looking Javascript (yes, worse than the usual stuff) that was obviously unreadable (not that was supposed to be). For this and a few other reasons, it didn't take me and a coworker long to realize this was not the solution for us.

I'm sure Google Web Toolkit is great for building a site from the ground up with, but didn't fit into our existing J2EE app very well.

Anyways, if you must know, we looked into the Dojo Web Toolkit and I wrote our tree using that, unfortunately, that framework seems buggy and prone to memory leaks as expanding one node can take much longer than the initial load/render for the CSS tree. We're still using the CSS tree in production, if anyone has any help, let me know! But that's my experience with the Google Web Toolkit. Short and bittersweet.

Re:My experience with GWT

[CastrTroy]

Ajax is a very easy concept. If you just want to throw together some Ajax for one part of you application, it shouldn't take more than a couple days to get a solution to a problem like yours. You'll understand the code a lot better, and it will be a lot easier to fix things when something goes wrong. You'll probably need maybe 300 lines of javascript to support the Ajax calls, and rendering of the response. There's not that much involved. Just start coding and get it done.

Re:My experience with GWT

[xannik]

You shouldn't need to know what the compiled javascript looks like. If you need to access methods within your compiled JavaScript you can use JSNI to create hooks into your google web app. This way you can write your own external methods in javascript and set/get data in the compiled google web app. I had an existing inventory system that I implemented this very way. Perhaps you had other issues besides this, but if this was your main reason perhaps GWT deserves another look. I have found the code to be highly stable and it does a good job of abstracting the different browser javascript implementations, so it frees me from having to worry so much about browser compatibility.

-Xan

Re:My experience with GWT

[Anonymous Coward]

I'm sure Google Web Toolkit is great for building a site from the ground up with, but didn't fit into our existing J2EE app very well.

Note that even Google doesn't use GWT for their own services. It's a company they bought, rebranded, and open-sourced.

It seems a cool concept (if you can stand writing Java). But I wonder if *anybody* has written a serious app using it yet.

Re:My experience with GWT

[bwt]

What do you care what the javascript looks like? The whole idea of GWT is that the javascript,html, and CSS (somewhat) are an alternative form of bytecode to compile your java classes to. You "look at" the java code, in an IDE like eclipse with lots of code assist features like syntax checking, completion, problem underlining, quick assist, refactoring, etc..., etc..., etc... .

Part of the value proposition of GWT is that java is easier to maintain than javascript. There are probably a few javascript monkeys out there who don't know much java that don't agree, but most of the javascript (human written) that I see when I do "view source" out on the web is horrible stuff with negative maintainability.

Re:My experience with GWT

[brunes69]

I can back up the parent on the fact that GWT is not at all suited for plugging into an existing application.

I am in charge of a fairly large web app (hundreds of thousands of lines of Java, JavaScript, and AJAX). I looked into GWT when it first came out - it only took me about 20 minutes of fiddling with the demos to realize that a) This is a great toolkit for basing a web app off of and b) this is a horrible toolkit to tie into.

The things that make GWT so great are what makes it near impossible to integrate with. Namely the fact that you have very little control of the outputted JSP and JS means that it is very hard to tie it into an existing web applications infrastructure that already uses its own frameworks for AJAX and display layers.

Re:My experience with GWT

[SnapShot]

There are also JavaScript libraries that work at a lower level (which makes integration much easier). I use JQuery which has a nice cross-browser way for accessing DOM elements, a few bells and whistles, and, most important, a standard way to access the server via their Ajax methods. Nothing revolutionary (I've never used it but I think Prototype does the same thing) but easy to use and seems to be very well supported.

However, for my next "clean" Ajax project I think I'm going to give GWT a try. I've done it by hand... now that I understand a little bit about what's going on under the hood I'll let Google handle the details.

Re:My experience with GWT

[Anonymous Coward]

Try DWR. We use it in all sorts of places and it works beautifully.

Re:My experience with GWT

[kevin_conaway]

Try DWR. We use it in all sorts of places and it works beautifully (logged in now).

Re:My experience with GWT

[xannik]

Just out of curiosity what were you going to use GWT to do in your web app? For instance, if you have your existing AJAX framework that was communicating with your server and fetching the data and all you wanted to do was say display that data, perhaps in some sort of tree structure or whatever, you could write a JSNI method for your GWT code that accepts the data from the existing ajax framework. So in this case your existing AJAX framework would be doing the heavy lifting of communicating with the server and then GWT would be in charge of displaying that information. I would be interested in hearing more about your own particular scenario that made using GWT difficult.

Re:My experience with GWT

[anton_kg]

I would stick with any toolkit which you have a control on. If you know a bug in Dojo - open a bug file. Sign a paper and send it to Dojo developers if you have a patch and want to fix it yourself.

Re:My experience with GWT

[Dan Berlin]

What do you mean?
GWT is open source and accepts external contributions.

Re:My experience with GWT

[suv4x4]

What do you care what the javascript looks like? The whole idea of GWT is that the javascript,html, and CSS (somewhat) are an alternative form of bytecode to compile your java classes to.

And that's a great idea, unless you have account for the fact that HTML/CSS/JS *aren't* application bytecodes.

There are lots of concerns in a web app that aren't there in compiled bytecode app:

1. data/code sharing among pages (number of file read requests, repeated data in every page)
2. incompatibilities among browsers (you rely on GWT for browser compatibility, it's frequently not accounting for some rather unobvious details, then you're screwed).
3. GWT goes against MVC as it follows a more traditional "apps and forms" paradigm, which means you're severaly limited in code reuse and separation of concerns in your app.
4. They provide you with a nice Java debugger to debug your basic application logic, but in the real world you'll need to test your ACTUAL app on ACTUAL browsers and you'll find lots of problems. Good luck debugging those when the error show up in some random place in the midst of some random code bytecode-ish blob.

I've been this way, there are things you can abstract, and things you better not. I've went to abstract a template/component compiler working on the server side for me, it would compile an extended version of HTML (html with XML components, kinda like JSP) to HTML+PHP.

And although this is much easier as the produced code is browser agnostic, unlike client-side code, I still had to go to considerable lengths to make this debuggable and manageable (when ANY error occurs in the compiled file, it should point out where the error was in the SOURCE file(s) ).

On the client side however you can't do this. You can trap exceptions, you can trap some errors in some browsers in some proprietary way, but basically if you open your code to analyze in tools like FireBug or DOM Explorer, you see an unreadable mess that's impossible to tell apart.

GWT users laugh at people who use AJAX frameworks. I can't believe you laugh at a simpler and more direct, more manageable approach to a problem, and accept a few layers deeper abstraction for the sake of not having to "get dirty with JS".

I realize GWT is very cool if you're afraid of JS/CSS/HTML and want to pretend using Java when Java is not there seems very professional. But JS isn't a *bytecode* after all, it's a very readable, well-tooled for the purpose language, and you can write manageable code DIRECTLY in it.

Further more, if you prefer to work in a more Java/Desktop approach, you can always use Flex 2, which is basically a RAD application tool using JS 2 (classes, interfaces, namespaces, E4X, packages, closures.. all the goodies) that compiles to cross-platform compatible Flash 9 goodness, and doesn't have any underlying ugliness like GWT does. If you run it - and it works, it works everywhere.

Re:My experience with GWT

[Anonymous Coward]

This simply isn't true.

1) Google had a lot of existing code before GWT came out.
2) GWT is new. Google loves it and is carefully integrating it into many "serious" apps.

Re:My experience with GWT

[bwt]

There are lots of concerns in a web app that aren't there in compiled bytecode app:

1. data/code sharing among pages (number of file read requests, repeated data in every page)
2. incompatibilities among browsers (you rely on GWT for browser compatibility, it's frequently not accounting for some rather unobvious details, then you're screwed).
3. GWT goes against MVC as it follows a more traditional "apps and forms" paradigm, which means you're severaly limited in code reuse and separation of concerns in your app.
4. They provide you with a nice Java debugger to debug your basic application logic, but in the real world you'll need to test your ACTUAL app on ACTUAL browsers and you'll find lots of problems. Good luck debugging those when the error show up in some random place in the midst of some random code bytecode-ish blob.


GWT solves #1. Code up a java object to represent your data and use the GWT RPC mechanism to get instances of it to your GWT app. Write client code in java to use it. Oh, and you can eliminate some or all of the needless page transitions since they are mostly useless. GWT apps look and feel more like rich GUIs.

The amount of effort it takes to solve #2 on your own is one of the biggest strengths of GWT. Please look yourself in the mirror and say your organization is better than Google and the GWT community at understanding browser specific DHTML differneces. If you answered that incorrectly with "sure we are", go back and try again.

Your statment #3 is bizaare. MVC was originally invented for "apps and forms" in traditional GUIs. It's the page flow webapp model that made confused the issue. It means decoupling data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller. Regardless, GWT works great with MVC. You can use it with Struts2 or SpringMVC just fine. I think GWT greatly **simplifies** MVC in practice because I don't have to do a bunch of redirect/forwarding/setup actions gymnastics that serves no purpose other than to push data I gathered on one page to another. Instead, I get view reuse at the instance level and only send data to or from the controller when it needs to interact with the business services and persistence.

You miss the point again with #4. I suppose everybody that says they support browsers X, Y, and Z must test on those browsers. But at least with GWT, The code *I write* doesn't have case statements in it that switch behavior by browser. I'm spared writing the browser specific tweaks myself, because the Google team does it. The benefit is to development, perhaps not to testing. Testing isn't worse off, either. If there is a problem on one platform and not the others, I always have the same option you do, change my code to work around the bug. I have refactoring support in my java IDE to help me do this. I also have something to help prevent such problems in the first place: I'm using javascript widgets that Google has already tested and says they support to work as advertised on the browsers advertised. If you have actual bugs to talk about, then that's one thing. Otherwise you are just spread FUD without evidence. But to your point, if a bug in GWT itself occurs, you've got Google supporting it. Since GWT is open source with a growing community, you can probably solve bugs the same way you would with anything else: troubleshoot as much as you can and post on forums or mailing lists. My experience is that most open source projects will really help you if you do your due diligence and are responsive. I expect the collective ability of GWT community to understand and navigate around browswer incompatibilities dwarfs that of a typical enterprise webapp shop.

Re:My experience with GWT

[m50d]

Bear in mind that quite often that has been deliberately "compressed" (by renaming variables etc.) so it downloads faster, compared to the copy that is actually worked on.

Re:My experience with GWT

[suv4x4]

Please look yourself in the mirror and say your organization is better than Google and the GWT community at understanding browser specific DHTML differneces.

You know, I'll accept the rest of your comments as I truly don't know GWT well enough to be certain. I evaluated it, saw sufficient hurdles in using it and rejected it.

However, I don't need to look in the mirror and practice self-help exercises to know the obvious. If you've ever inspected the code of the google pages (the main google search page, google news, gmail, google apps and so on), you'll easily recognize how poorly it is on not purely technical level. They freely mix deprecated HTML 3.2, HTML 4 and XHTML, tag cases and very frequently have just plain weird pieces of code that don't seem to serve any purpose.

Google's pages show thousands of validator errors, and while I'm not a "validatorian", and don't care much if you'll skip the alt tag on images if you'd leave it empty anyways, but Google is truly pushing it.

Google is rich, Google has the biggest expertise in the world crawling messy HTML code and extracting info and delivering relevant results.

But mirror or not, I, and thousands other developers are better at *writing* good and technically well-done sites, and don't need hacks (aka GWT) to do it better than Google can.

Re:My experience with GWT

[suv4x4]

The code *I write* doesn't have case statements in it that switch behavior by browser.

You know I refuse to accept you're having sufficient experience with any of this if you'll be talking to me that you must absolutely have browser detection code branching to NEED to test in different browsers.

I've seen my share of out-of-nowhere bugs in browsers trying to interpret code they normally support but fail to render properly, including stuff like Firefox improperly rendering the DOM tree if you nest relative and absolute positions in a certain way and modify it in a certain way with JS (really I have concrete description but too long, never mind), or Opera rendering improperly its scrollbars in scrollable areas setup in a certain way. In all clean, validating, no-weird-hacks-and-tricks code.

As about the collective GWT community producing more stable product across the popular browsers than I can alone, given few (infinite? :) ) iterations, even a monkey can code properly behaving code among the popular browsers. The question is HOW. Most open source projects I've inspected achieve compatibility with incredibly twisted and lame hacks and "patches" since the people who did those patches knew nothing better.

I use a very simple library which is a subset of Prototype (the popular JS library), and I'm consistently surprised that it behaves consistently in *new* versions of browsers I never tested in (virtually all sites I produced worked perfectly in IE7 when it came out without any changes).

The fact this happens doesn't mean I shouldn't test, because sooner or later something weird pops out and I have to be there to fix it. I take my job seriously.

Re:My experience with GWT

[Raenex]

I use a very simple library which is a subset of Prototype (the popular JS library) What library is this?

Re:My experience with GWT

[suv4x4]

What library is this?

I created it on my own for personal use (I don't like all of the things Prototype chose to do).

This is the original library.

Re:My experience with GWT

[Raenex]

Hmm, ok. Could you explain what you changed?

Re:My experience with GWT

[suv4x4]

Hmm, ok. Could you explain what you changed?

Merged the $ and $$ selectors, I dropped the "enumerator" extensions, I altered the way classes are created and so on.. But why are you so intensively interested in what I changed :D

FYI I change things as I suffer mild to moderate NIH syndrome :P I just see a better/more standard way to do something and prefer doing it this way. Prototype is trying too much to copy other languages which I do not care about.

Re:My experience with GWT

[Raenex]

Thanks for your answer. The reason I'm interested is because I'm looking to do an Ajax-based web app after having been out of the web development game for a few years. It helps to know what people like/don't like about the various frameworks.

the issue of layout

[kisrael]

The short description of GWT is:
If you like the idea of web programming feeling like writing an applet, GWT is just the thing.

Probably my biggest concern after evaluating it was the layout issue; though I guess the "AbsolutePanel" or that "Instantiations GWT Designer" Eclipse plugin might help... along with hunkering down and learning the damn CSS....

Still, programmatic layout is kind of an odd duck.

Also, is it "easy" to add in 3rd party javascript widgets, per se? Seemed a little akward, or at least un-GWT-ish...

Re:the issue of layout

[Tablizer]

If you like the idea of web programming feeling like writing an [Java] applet, GWT is just the thing.

In other words, GWT is dead ;-)

Re:the issue of layout

[random0xff]

Still, programmatic layout is kind of an odd duck. Only if you're used to doing it with HTML and CSS. A basic layout often seen in desktop applications is the borderlayout. This layout can not be created with HTML and CSS without the help of javascript (onload and onresize event handlers to keep everything in place). So when you need layout such as these, you need to program them, you can't 'declare' them. Have a look at the demo (Desktop App Clone) on the GWT website to see what I mean.

Re:the issue of layout

[kisrael]

A good point, I may have been a bit corrupted by HTML/CSS, but...
I dunno, it seems like even old fashioned tables and CSS might be a more reliable way of accurately reproducing a screenshot into a screen...

"Hello World" with GWT

[A Friendly Troll]

Opera's Hallvord blogged a bit about GWT yesterday. He doesn't seem to like GWT much, and neither do I, based on what I've seen there.

I'm all for faster and easier development, but when such an app gets stuck on the client side, then you are in a lot of trouble; at first glance, it looks undebuggable (if that's even a word).

Re:"Hello World" with GWT

[nate nice]

But at second glance you realize it's very debuggable because you run in client mode. That is, you debug Java, the same Java you wrote.

A lot of people don't understamd this technology.

Works for me.

Re:"Hello World" with GWT

[A Friendly Troll]

I was thinking more along the lines of "View Source" and debugging HTML and CSS. Other examples might be different, but for this one, you have to look at the generated source somehow. Also, if there's no source, search engines go crazy, and screen readers for visually impaired people aren't very useful.

Look into DomAPI

[brunes69]

http://www.domapi.com/

It's not free for commercial use, but the licenses are cheap. It is a very powerful and robust toolkit, not only does it do AJAX but also has a ton of useful GUI widgets and other core functions.

I prefer Yahoo's YUI

[mha]

I was looking for which framework to use. I didn't look (further) at Google's offering because I wanted a JS framework, not Java, so I cannot comment on it. Yet I would like to make a posting to point out my personal favorite, the YUI, and how I got there.

First, on the page http://developer.yahoo.com/yui/theater/ the Yahoo "JavaScript Architect" Douglas Crockford gives some really *excellent* learning presentations on JS and the DOM that convinced me that there are really knowledgable people whos philosophy I like too.

Second, the license is BSD - it can hardly be any more free.

Last, if I have to rely on a framework I want to be sure it stays around. So even if some of the others are nice too and would fit, I must say I trust Yahoo a lot more to stay around and improve their framework - especially since they use it themselves for everything they do.

I also must say that I wasn't impressed at all when I finally tried GMail a few weeks ago, as a regular user of Yahoo mail for all my "public" mail (my own domain has 4000 email addresses left but I prefer Yahoo because of the excellent Spam-filter and only use my own domain-address for close friends) I find the Yahoo mail interface superior and much nicer.

What's more, there's YUI-ext, an extension for YUI (and now available for Jquery too), which provides some great-looking and very functional add-ons: http://www.jackslocum.com/blog/index.php

JBoss Seam with Seam Remoting and AJAX4JSF

[jazir1979]

Try looking at the above if you need a web-app where you can use AJAX as required, but also require full JEE integration including OR mapping with EJB3/Hibernate and a strong GUI component/event model. It makes the disjoint between the various JEE tiers SEAM-less.

GWT online documentation is sufficient

[MarkWatson]

I thought about buying a GWT book, but the general documentation at http://code.google.com/webtoolkit/documentation/ made it simple to build and modify projects.

See for yourself, use the section "Creating an Application from Scratch (without Eclipse)" at http://code.google.com/webtoolkit/gettingstarted.h tml (using command line tools).

I keep the GWT "Kitchen Sink" examples source handy to copy CSS, code, etc.

GWT is very cool, especially if you need to build one large application. I must say though, if you just need little bits of AJAX, it is trivial using other toolkits (e.g., "Java + AJAX in 18 lines" http://mark-watson.blogspot.com/2007/02/java-ajax- in-18-lines.html - my example of trivially adding AJAX support to JSP forms).

Comment removed

[account_deleted]

Comment removed based on user account deletion

IDE tools available as well

[owlstead]

As you can see on Google itself, there is already some (commercial) support for the GWT. Of course it always helps to know at least the basics of a toolkit even if you start to use an IDE GUI builder. But my experience with e.g. Instantiations is pretty good and the toolkit does not seem too expensive (and, you can see and change the generated code on the fly as well). Of course, if you really go for the GWT for a larger application, you need to know all the bits and bytes and you should at least buy one well written book.

Note that besides that I do not have any experience with any GWT GUI builder so if there is anyone wanting to share some information with me and the rest of /., please follow up on this.

Unfortunately AJAX

[Anonymous Coward]

Unfortunately AJAX has evolved to fill the void: inefficient, ugly, non-standard, and totally counter-intuitive. The reason it is this bad is because the individual components of AJAX were never designed to support rich web-applications; AJAX is a hack. No programmer in their right mind would ever choose to use AJAX over a properly designed remoting and GUI framework. So, why do we tolerate it? Because its currently the only way to build anything that remotely resembles a rich application that is accessible from (most) web browsers. Simply put, its a compromise; however, a very nasty compromise. I pray for the day when people wake up from the buzzword stupor they're in and start demanding better standards.

upload tag

[kisrael]

That's the big thing GWT is missing....clean support for uploading files

To bad it uses Java.

[MikeFM]

To bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require. Of course the saving grace might be the number of tools that exist to make building GUIs in Java easy. Still, I'd rather see something more RAD oriented than the Java is. It's impressive work even if it isn't perfect though - I think it'll lead the way for better development models in web design.

I think a domain-specific markup language designed for high power web apps is a better idea. Just compile those into HTML/CSS/JS until some browser actually supports the language native. I wonder if XUL and all that Mozilla stuff couldn't be compiled into HTML/CSS/JS the way Google is compiling the Java.

My favorite AJAX trick is still from whomever invented Javascript Behaviors that attach using CSS rules. I use that library constantly and would love to see the concept made into a real standard. I know that when I've developed GUI apps in Java for cellphones I've used libraries that would let you style the UI and attach application logic to the UI using a modified form of css and it really made development easier. With Behaviors my HTML is clean and the application logic is easy to change.

Re:To bad it uses Java.

[salimma]

Too bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require.

You can use Groovy with it, you know =)

Re:To bad it uses Java.

[MikeFM]

Am interesting point - I suppose I could develop code in JPython and compile it with GWT. I usually use Python for my non-web GUI apps so that could be a workable concept.

Still, it's not significantly easier IMO than developing with Javascript and CSS so long as you have a framework that's already developed the widgets and worked out the compatibility issues.

Just a side rant.. I have to say that I really hate Internet Explorer. Even IE7 has significant problems with it's Javascript and CSS which require hours of work to code around. Even worse since we still need to support IE6 too. Last night I wanted to write a simple tabbed pages widget and it took me longer to work out the IE bugs than to write the original code. IE7 was having an especially annoying bug where when hiding and unhiding content it'd randomly lose page elements. But if you did an alert() they'd reappear. How stupid is that? Okay.. end rant for today.

Re:To bad it uses Java.

[salimma]

I have an odd feeling that the reason IE developers are draging their feet on standard compliance is that they want to move web developers to using Visual Studio.NET for anything non-trivial.

VS.NET's WebForms does greatly simplify the development of web applications - they behave just like normal WinForms applications -- but you can only select HTML 4.0, Netscape 4.7, IE 4, 5, and 6 (this was back in VS 2003, if I remember correctly).

Web 2.0 can be very much like Unix-style programs.

[MikeFM]

Your comments seem a little odd because web design has become very much like working with Unix-style single purpose programs. If you have trouble it's probably because you aren't coding in Unix-style. My web applications are composed of many smaller programs that each do a single thing. These can be written in whatever language is most appropiate but they speak to each other in common interfaces. My back-end is composed of services that communicate with XML-RPC. The front-end is a thin layer that usually divides the front-end logic between the web server and web browser and all the code is kept mostly seperated. The web server uses PHP for templating, input scrubbing, and calling the back-end services. Most of my code is standard XHTML which if viewed without CSS, Javascript, and the rare bit of Java or Flash looks like very boring circa-1997 content. CSS makes it look nice and Javascript gives it better interaction. The applications work without either of these - they just aren't as nice a user experience. The XHTML, CSS, and JS are kept in completely different places so they are essentially discrete components. Likewise with any Java or Flash I use.

If I have to deal with interfacing with something that doesn't use a XML-RPC interface then I create a service, to sit between it and the rest of my applications, that gives it a XML-RPC interface. I've been recently doing this with Intuit Eclipse which I expect to make programming multiple apps to use much easier. Lots of libraries available, for just about any language, to interface with XML-RPC. Not to many available to interface with Eclipse's IDMS-XML. I've created similar translation services to handle S&H, payment processing, instant messaging, etc. Much easier to maintain than a single massive app.

My web applications are stiched together very much like Unix shell commands. Many small and simple parts that together can do just about anything. If you start mishmashing it all into single files then of course you'll go insane. Using discrete services also makes it a lot easier to divide load across multiple machines and to impose different security levels on different services.

Now if you just wanna bitch about how different browsers handle CSS and Javascript and can join you there. IE7 has helped a lot but I still spend more time fixing issues with IE7 than I do with Firefox, Safari, and Opera combined. Unfortunately, I still have to make sure IE6 at least works even if it isn't perfect.

AJAX is NOT irrelevant...

[javabandit]

Every so often, someone wants to start using AJAX and automatic form reposting
and a bunch of stuff that makes their code unreadabale and unmaintainable by the rest of the
crew.

I think you're crazy. Have you looked at the source code of "classic" CGI pages that do a full form post and then return back to the same page... all the while trying to retain the state of existing fields or refresh the screen dynamically based on a selection? Gimme a break. Go read some of the "classic" source code in Bugzilla sometime. Talk about coding horror. Go look at the "dynamic" query portion of the Bugzilla search page. (Sidenote: This isn't a knock on Bugzilla developers. You guys did the best with what you had at the time). If Bugzilla's search page was AJAX enabled, it would be worlds easier to read, understand, and maintain.

AJAX programming is so much cleaner. You post only what you need to, when you need to, and then update only the portion of the page that you need to. I don't know how you can say that is more "hard to read" or "a real pain". AJAX programming is the closest you can get to thick-client, event-driven UI programming in a browser. Combine it with JSON and you are talking VERY clean.

I'd love to see examples of what you think "painful" AJAX code is versus the same code in the "classic" CGI paradigm.

GWT in production

[kilkenny]

In case you are interested, a here is a list of GWT applications in production:
http://www.ociweb.com/mark/GWT.html#WhoIsUsingIt

---
check out => http://traceurl.com/rdS?r=1&l=2

Last Summer of AJAX

[Markavian]

I spent all my last summer looking into the XMLHttpRequest object, Google maps, Local Live, Dojo, prototype.js, and found them to be very resourceful and capable tools for developing web applications. Most useful for FireFox 2 for debugging js. Any programmer can take an idea and make it fly in a matter of weeks (that was my commerical task, find out the possibilities).

Since then, I've moved jobs and settled back into normal web dev. Web 2.0 is a distant memory, a tool to smooth over the mudane page refreshing we do, like submitting ratings, and quickening the auto-fill bar in answers.com (aka Google suggest?). As for GWT, I found their tools very restrictive. Compared to the flexibility of working with designs directly in HTML/CSS - GWT provided more barriers then solutions for me. Well designed software, written in JavaScript is as effective software written in any other framework GWT, VisualWeb developer, Ruby, etc..

Personally, I would prefer to develop plainly for the web using server side scripts, and add JavaScript as an afterthought. Overuse complicates user experience and muddies the code, which is bad all round. Good website and web application design does not require JavaScript.

508

[Anonymous Coward]

Still no proper documentation on dealing with google ajax webkit and 508 or accessiblity

spamspamspam

[Anonymous Coward]

lorem ipsum spamtrap thank you. http://www.geocities.com/testitestitestaaja/