GWT and XForms Series, Parts 3 and 4

The last two parts of the GWT and XForms series I wrote for IBM are up now: Part 3 and Part 4. Part 4 is fun since it is more "icing on the cake" kind of stuff as opposed to the core integration of the two technologies. I really wanted to work in some info GWT's ImageBundles. It's a slick implementation of the CSS sprite pattern.

Continuing down that tangent... I'd like to see an ActionScript implementation of that pattern. It would be cool to take a dozen images in Flex Builder, have it create a composite, and then use that for any references to those images in your Flex application. Of course maybe it's not needed. If you knew you needed those dozen images for your app, you could just embed them all in your SWF. That's going to be even more efficient since you won't have to make the HTTP request for the composite image. Obviously there are advantages to externalizing, since you could change the composite image without recompiling your SWF and without having to worry about referencing a new version of your SWF that's not being cached by users. It also allows for localization of the images. Enough rambling on that topic for now.

New GWT + XForms Series

I wrote a four-part series for IBM on using Google Web Toolkit and XForms together. Somehow IBM snuck part 1 and part 2 by me on their site. The tutorial uses JSNI a lot and touches on some of the latest features in GWT.

GWT 1.4

I recently finished writing a series of four articles for IBM on GWT. You might recall that earlier this year I wrote a two-part tutorial on GWT. The new articles for IBM aren't as introductory, though they don't require a lot of prior GWT knowledge. They're definitely more advanced though. I wrote the articles using the 1.4 release candidates, and then last week 1.4 went final. So I figured it was time to look at how GWT has progressed since the last time I wrote about it.

• Cross Platform Problems -- Hard for me to say how much things progressed. I did almost everything on my MacBook, and things had always worked well on OSX. I did do a little on Windows. I had to do a little more configuration to get it to correctly run in hosted mode than I did on OSX.
• Obfuscation -- Still a problem. Of course you can turn it off, which is good. Still, I pity the fool trying to debug GWT JS in Firebug.
• No Java 5 -- Still a problem. GWT will choke on a List, but String[] is ok. Also, any annotations will choke it as well. So no returning @Entity classes from your RPC services.
• Lots of boilerplate code to write -- Still a problem. You still have to write two interfaces and one class to create an RPC service. Inserting GWT into an existing page is easier, with just a single JS file to include.
• Better build support needed -- This has a improved a little. The ant script that is generated is slightly more useful than the previous version. Still frustrating that there's no build script generated for creating a WAR file. You don't have to use GWT with a Java application server, but obviously a lot of people are. The RPC services require it as well.
• RPC is bad -- Of course that can't change! RPC is still bad. I like how in the documentation, the GWT team mentions two different design philosophies for RPC services. One is to create RPC's specifically for the web application. The other is to have general purpose ones that can be re-used by many clients. Good luck on that last one. That would mean your general purpose services can only accept and return classes from the subset of Java 1.4 that GWT supports.

So that addresses my old pain points. Not much progress has been made. There are some new good points.

• Performance improvements -- Ok, they've really done a good job here. Things are snappy even on a page where you use lots of generated JS to create your UI.
• More Widgets -- Steady progress has been made here. You can get pretty far just using their widgets. I haven't tried out any of the commercial WYSIWYGs built for GWT, but these seem more viable and useful with more widgets. Of course, their widgets are very limited. They definitely aren't components. Compare a GWT widget to a Flex component, for example, and it's not even funny. GWT's widgets are pretty lightweight, but are low in functionality compared to similar abstractions found in similar frameworks.
• Image Bundles -- Very cool new feature. I like how they use CSS to get nice layout of the images from the bundle. It seems like a great way to optimize the static assets in your app. Seems like it might play tricks with a user who wants to right-click on one of your images and do save-as, but oh well.
• Localization -- This has always been there, but it seems better documented and exposed now. Plus there is a command line tool for it. It's pretty nice, though I question the logic behind doing your localization in code that is going to be converted to JavaScript and executed on the client.
  

So all in all, GWT has made some nice improvements and added some new features. They have not addressed the things that are their most blaring weaknesses (IMO), but then again those are probably the hardest things to address. I was surprised though. From my last big write up, I got a lot of feedback from people talking about how these exact issues were being addressed, i.e. that the work was already in progress. Was that really the case?

Flex Stocks Updated

I tweaked the Flex version of the Stocks app. I cleaned up the UI to make it just plain ol' white. I also integrated the HTML "host" page for the SWF file with the WAR and the source. So here it all is:

• Deployable WAR -- Drop it into to your web container and go to http://localhost:8080/Stocks
• WAR Source Code -- Unzip it and import into Eclipse
• Flex Source Code -- Unzip it and (hopefully) import into Flex Builder.

Enjoy!

I'm thinking of refactoring the original GWT app to use the exact same code as the code used here. More on that later.

Flex Stocks

As planned, I re-implemented the Stocks application from the first GWT tutorial using Adobe Flex. Here is a link to a short document I put together outlining the code and the interesting parts. It also has links for downloading the code I wrote.

It was really pretty easy to do this. Of course this was a pretty simple application. I might try to re-implement the advanced version of the Stocks application from part of the GWT tutorial. First, I'll do the easy one in Silverlight.

GWT Tutorial Part 2

The second part of the GWT tutorial I wrote for IBM is now online @developerWorks. The second part adds some more server-side logic for persisting data (in this case a stock portfolio) to a database. Of course it makes judicious use of GWT to accomplish this auto-magically.

GWT Tutorial on IBM

Part 1 of the tutorial I wrote on GWT is now up on developerWorks.

Thoughts on GWT

I recently finished the second part of a two-part tutorial on the Google Web Toolkit. It should appear on IBM's developerWorks in the near future. I read a lot of materials on GWT during that time, including quite a few criticisms of it. So I figured I should take the time to put in my $0.02 about it.

GWT is an interesting engineering solution to a hard problem: generating standardized, cross-browser AJAX applications. What makes it unique is that it doesn't require you to understand JavaScript at all. You barely need to understand HTML even. That is really cool. But is it worthwhile?

The answer is, I don't know. It seems like a toy at times, but a really powerful toy. It's hard for me to imagine creating a real website using it, and there is really no way to even use it just for prototyping. As I understood it more though, I realized that there was a real-world workflow possible with it, and maybe that's its biggest strength.

If I were using GWT to build a real site, I would have a web designer build a complete prototype that I would check in and deploy -- as is. Ok, maybe I'd make sure that various visual components had the proper IDs or classes, since that's what GWT uses to identify and replace components. It's the replace part that is really important. The GWT runtime would replace the components created by the designer. It would replace it with JavaScript generated HTML. However, all the CSS created by the designer would be applied. So as long as the CSS was tight, then the GWT-generated component should look how the designer wanted it.

That's nice, really nice. I think having a good workflow between designers and developers is huge. Just look at what Microsoft has tried to do with Web Forms and now with XAML. Web Forms arguably inspired Java Server Faces, which is now part of the JavaEE specification. So maybe that's the real strength of GWT. Everything else is icing on the cake. That being said, here's my favorite and least favorite things about GWT.

Good Stuff

• Debugging -- Being able to debug client side code inside Eclipse (or any IDE) is really nice. I don't know how much time FireBug has saved me in debugging JavaScript. Every JS developer I know uses it. I show those guys what it's like debugging GWT code inside Eclipse and they freak out. The Visual Studio debugger is also really nice, but it's still got nothing on a Java debugger. GWT just enables a Java debugger. Of course it's only valid for hosted mode, but that's another topic.
• Unit Testing -- Ditto for writing unit tests. I know that there are initiatives for creating JavaScript unit tests, such as JsUnit. I've looked at it a little bit, and it's really clever. It still requires all your code to be deployed (of course.) Being able to run a unit test either inside your IDE or with an Ant/Maven target is really nice. Easier unit testing == more unit tests == better software.
• Nice HTML Abstractions -- Really like the FlexTable for example. It's also interesting to port layout managers to HTML. I can definitely see possible conflicts with CSS though. I'm not sure what would happen if your CSS specified a position that really conflicted with the layout algorithm. I'm sure CSS would win, I'm just not sure how bad it's going to make things look.
• RAD Tools -- Nice tools for setting up your project, etc. A lot of GWT was clearly inspired by Ruby on Rails, and this is one of the notable inspirations.
• Architecture -- Encourages UI logic being pushed to the client. Make use of the user's computer, and offload from your server.

Bad Stuff

• Cross Platform Problems -- All those RAD tools are OS dependent. In my experience they work really well on OSX, but are haphazard on Windows. I love OSX, but that's not good.
• Obfuscation -- The generated JS is dense and heavily obfuscated. Maybe that is useful for Google projects, but how is it good for the average developer? It creates a dependency. If you can't debug your client code in hosted mode, you have no chance of debugging it at all.
• No Java 5 -- It's understandable that GWT only supports a subset of Java classes when it comes time to generate JavaScript. But it's really annoying that you can't use things like the improved for loop, generics, and annotations. The annotations present a real problem if you're using Java Persistence or EJB3. An annotated entity bean cannot be passed to the UI essentially. You're forced back into a data transfer object anti-pattern.
• Lots of boilerplate code to write -- To use a remote service, you have to write a client side interface for it (not too bad), an asynchronous version of the same interface, and the actual (server side) implementation of the interface. Then you have to write some obscure looking client side code for registering the service at runtime. Doesn't this all sound familiar? Doesn't this sound like creating remote and home interfaces for an EJB and then having to use JNDI to look it up at runtime? We all know how that turned out for EJBs.
• Better build support needed -- Hosted mode is great, but it's kind of a pain going from hosted mode to a real deployment. GWT can't solve this completely obviously, but they can do more. Hosted mode lets you switch to a "live" mode where GWT creates a Tomcat directory and installs the web application to Tomcat. So clearly they understand the deployment issues, like exposing the RPC servlet endpoint in web.xml.
• RPC is bad -- Ok, I'm not quite as convinced of this as I used to be, but I think it is mostly true. RPC encourages a lot of strong coupling between server and client. However, I think the distinctions between server and client are fading anyways, so this is becoming less of an issue. You're probably going to want the services called by the client to be facades to the "real" services anyways, just because you don't want your real services to be compiled into servlets (which is what happens because you have to extend the RemoteServlet class in GWT.)
  

Ok, so maybe I named more good than bad, but that's always the case, right? The bad things always stick out more because you spend a lot of time working around them.

I'd like to see GWT leverage Java 5 a lot more. It needs to support generics. It should not only ignore most annotations, it should use them to eliminate the boilerplate code that developers have to write and the redundant interfaces that have to be declared.

GWT, Eclipse, and JUnit -- Rants

I love the ideas behind the GWT command line tools. They remind me a lot of Ruby on Rails. They seem to have some surprising shortcomings though. The projectCreator works pretty good for creating an Eclipse project. However, it doesn't include the gwt-dev-.jar (for example gwt-dev-windows.jar) in the classpath of the project. So you can't launch in Hosted Mode because the executable class is in that jar. Thus you can't use the Eclipse debugger either. If you add the jar to your project classpath, it seems a little better. You still need to configure the run profile, similar to how the -shell script does. Seems like these are obvious things that the projectCreator could do.

The junitCreator seems even worse. It needs a GWT module name, but none of the artifacts created by the applicationCreator or projectCreator contain this. The .gwt.xml file has the module of course, but not it's name. It took me some trial and error to get this right. Even when I did, I could only launch my unit tests using the generated command line tools. I could launch these files directly from Eclipse, but I couldn't launch the unit tests using Eclipse. Thus I could not attach Eclipse's debugger.

I'm sure there's a way to do this. I'm sure that either I 1.)didn't use the right junitCreator command option, 2.) need to configure my project differently, or 3.) need to configure my run/debug profiles differently. Whatever this case, this is all very un-Ruby on Rails like.

Oh, one last complaint. The projectCreator has an option for generating an Ant file. That is borderline useless. The build file only builds a JAR and does not include the gwt compiler as part of the build. Guess what, if you're using gwt, you're building web applications. You don't need a JAR you need a WAR, and you need it to include all the web files, i.e. all that gwt-generated JavaScript. You need a web.xml file, which gwt knows how to generate (it creates one when you launch web mode.) WAR files have a very standardized structure, so this should not be very hard. Just package up what gets deployed to the bundled Tomcat in web mode.

Update: Strangely I don't have a lot of these same problems when I run everything on a Mac. No idea why, since even though the command line tools are platform specific and some of the runtime is platform specific, one would think that the underlying Java code that creates the projects, artifacts, etc. is pretty much the same.

Google Web Toolkit and Firebug

Today I was working on a small web application that uses the Google Web Toolkit. I think a lot of the appeal of GWT is that Java developers have distaste for JavaScript. So what do they do? They build a framework to generate all the ugly JS for them.

I like JavaScript, and I'm not worried that saying so will cause me to take a pay-cut. I have some tools I like to use to deal with it. One is a bookmarklet I found for viewing XMLHttpRequests and responses. It works really well in Internet Explorer 7.

I was playing with my little app on IE, and decided to open up my bookmarklet to see exactly what the GWT-generated JavaScript sent to the server. What did I see? Nothing at all...

Ok, time to get serious. I switched over to Firefox, where I have every web developer's best friend, Firebug, installed. I flipped the switch on Firebug and repeated the same process. What did I see here? Again nothing. Nada.

What the heck was going on? I see the request hitting the server and the response causing the data on the page to be changed. Yet somehow these common debugging tools were oblivious to what was going on. Was there an inviso-IFrame being used? That would be so Web 1.0-ish.

I probed around with Firebug, and indeed there was a massive hidden IFrame on my page. I opened it up and saw that there was a GWT-generated HTML page that was being dumped in here. That page contained tons of JavaScript. And not just any JavaScript, but amazingly obfuscated JavaScript. Here's a sample of it:

function gX(hX,iX){hX.aX = iX;}
function jX(kX){return kX.cX;}
function lX(mX,nX){mX.cX = nX;}
function oX(pX){return pX.bX;}
function qX(rX,sX){rX.bX = sX;}
function tX(uX,vX){uX.fo(eX(vX));uX.cq(jX(vX));uX.fo(oX(vX));}
function wX(xX,yX){gX(yX,xX.jo());lX(yX,xX.Ep());qX(yX,xX.jo());}

I don't know what to say about this stuff, but it's not the point. This wacky IFrame was where all the magic happened. It's the use of this IFrame and its Skynet-like JS that allows the GWT guys to claim:

Your GWT applications automatically support IE, Firefox, Mozilla, Safari, and Opera with no browser detection or special-casing within your code in most cases.

They're not using the sexiest flavor of AJAX, they're using the lowest-common-denominator version of it.