GWT, an important Java technology: features, future and wishes

The Google Web Toolkit (GWT) has become one of the most important Java technologies, as it gives that language a credible web platform strategy. I used to be doubtful of the extra compilation step and developed with DWR and Dojo, but have since become a convert.

Cool features:

• A single code base for client and server.
• Great development tools, via Eclipse: refactoring, code navigation, etc. This was one of the reasons the creators of GWT chose Java as the source language. Server-side JavaScript certainly would have been a possibility, and compiling JavaScript to JavaScript is not unheard of, either.
  
• Quick turn-around: after making changes, the server and client can be reloaded quickly to reflect those changes (only the first start of the client is a bit slow, subsequent reloads are fast).
• Easy install of development tools: All you need are two Eclipse plugins and you are done.
• IDE support: One of the Eclipse plugins helps with various coding tasks and errors (such as keeping Service and AsyncService consistent).
• Easy deployment of applications: GWT produces a WAR file. Drop it into a servlet container such as Jetty or Tomcat. Done.
• Fast and reliable GUI layout: Still limited compared to what Swing and SWT offer, but for the first time acceptable.
• True client-side technology: GWT is tightly integrated into the browser environment and stays close to JavaScript. This makes it easy to keep pace with the rapid progress that browsers are making. GWT is also one of the few Java frameworks that can be used to write offline web applications, because it relies so little on the server.
  

Extending the basic features: For someone who has already programmed Swing or SWT, it is very easy to get started with GWT. After a while, you will probably be looking for advanced features. Luckily, a lively community has grown around GWT to fulfill this kind of need.

• gwt-dnd: Implements Drag and Drop in pure GWT.
• Smart GWT: GWT does currently not have too many widgets. Smart GWT is a GWT wrapper around the SmartClient JavaScript library which has lots of widgets. While GWT is really good at this kind of wrapping, there is some baggage involved: load times of web applications increase, and there is a new API to learn.
  
• GWT Mosaic: Also extends GWT, but as pure GWT and with less widgets/features.
• Other wrappers for JavaScript libraries exist. But beware, some of them have very restrictive licenses.
  

What the future will bring:

• Currently, the GWT incubator hosts experimental features. Long-term, its parts will be migrated to either separate projects or the GWT core.
• A post reveals interesting things about GWT’s future. For example, it will get data-backed widgets.
  

What I am missing:

• More widgets: The current widgets are limited (menus don’t ensure that they are visible, no support for shortcuts, no resizable dialogs, no context menus, etc.) and there are not enough of them. I expect this area to improve quickly, though, now that all the important foundations have been laid (event handlers, modular CSS, layout panels).
• Switching back-ends: Many computers are only intermittently online. Programming an offline mode for a GWT application is difficult, because the server usually hosts important functionality. A hypothetical way of solving this is by installing a back-end locally. The client could switch between this back-end and the server. Managing installed back-ends should work similar to Java Web Start. A local back-end could also provide a GWT application with desktop features, because it has access to desktop resources such as the file system.
• Better client-side modularity: I love Eclipse’s modularity, especially when working in a team. You can have a core plugin that is extended via other plugins residing in separate projects. It would be nice if one could extend a GWT application in a similar fashion. On the server side that is possible via OSGi. On the client side, that is currently not possible.
• Sending binary data from server to browser: For example, one cannot create images on the server and send them to the client via RPC. Data URIs are a work-around, but a poor one.
• Annotations for hiding code from the client: If an object is transferred back and forth between client and server, there are often some server-only methods. An annotation would allow one to hide those methods. There is an issue for this feature. You can star it, if you would like to see it fixed.
  
• Instantiating classes via class literals: There is no Class.newInstance() in client-side GWT. One has to resort to sending a factory to the client.
• Two two useful methods: Class#getSimpleName(), String.format() are simple to implement, so I don’t see the reason for not doing so in client-side GWT.
• Simpler unscrambling of GWT method names: If you want to invoke GWT code from JavaScript you need to prevent GWT from scrambling your method names. Doing this is a bit more complicated than it should be. A simpler solution would be to add an annotation to methods whose names one wants to preserve.