GWT's future: 2.0 and my wishes

[2009-06-26] gwt, dev
(Ad, please don’t block)
Programming web applications with GWT has been a revelation. Having mature tools and a single code base for client and server is great. In this blog post, we'll first look at the new features of the upcoming version 2.0 of GWT. Then I'll list a few wishes that are still unanswered by 2.0.

New features in GWT 2.0

GWT 2.0 has some incredible features in store:
  • In-browser hosted mode: see your hosted mode webapp in a real web browser. This obviates many needs for compilation. Plus both compilation and starting hosted mode will become faster.
  • Developer-guided code splitting: you tell the compiler roughly were to split to lazily load code and the compiler figures out how to package your code.
  • Better layout: the GWT team seems to have worked on better CSS-based layouts. I'll believe it when I see it, but if this works, it will fix one of the biggest Ajax problems.
Get more details about GWT 2.0 at “GWT Can Do What?! A Preview of Google Web Toolkit 2.0”.

Open wishes

Alas, a few of my wishes are still unfulfilled. I've collected them below, they are the result of my experiences while implementing Hyena. If all of these wishes were to come true, then this would make web applications true competitors to desktop applications (well, one would still have to figure out packaging and access to desktop features; Trephine is very useful here, but an even cleaner solution would be nice).

Platform

  • Server-side image generation: generate a JPG, PNG or SVG image on the server, send it to the client, display it in an image. Right now, the work-around is to use a data: URL with base-64 encoded binary data and assign it to an image. But that wastes space and does not work with SVG in a cross-browser fashion.
  • @Ignore annotation for methods: This would mark server-only methods and prevent client-side code from being generated. The current work-around is to move server-only code to static methods in a different class.
  • Swapping a server-only implementation of an interface with a client-side place holder: With custom field serializers you can control how a class is serialized but not what class is instantiated. This is a problem whenever you have a nested data structure that contains server-only implementations. I currently do my own reflection-based traversal and swap implementations to solve this problem (directed by annotations). Hardly a simple solution.
  • True dynamic loading of client-side GWT code: would be the perfect client-side complement to server-side OSGi modules. Then OSGi modules (or even just plug-in JARs) could bring their own client-side code. Currently this does not work, because GWT always compiles the reachable code of all used modules into a single monolithic "binary". The kind of code splitting that is planned for GWT 2.0 seems to be almost there, but serves a different purpose.
  • GWT API for Bespin's widget library: This widget library is completely drawn by JavaScript in the canvas tag. Sounds crazy, works really well, because JavaScript has gotten so fast.

Language

  • Full client-side regular expressions (preferably with an API that works server-side, too).
  • Non-static GWT.create(): It would be nice if class objects could be sent to the client for instantiation. Currently, the only work-around is to register serializable factories (that actually do the instantiation, statically) and send those to the client.
  • String.format(): is useful, easy to implement, and should work on the client.
  • Class.getSimpleName(): same as above.

GUI

  • Better layout: Hopefully GWT 2.0 delivers on this front. What I miss is to be able to specify “take up as little space as possible” (as opposed to * or fixed spaces). Vertical spacing is often tricky, too.
  • Better widgets: The scarcity of widgets is still one of GWT's weak spots. Mappings to JavaScript widget libraries are possible, but then one does not profit from GWT's small code size. A few widgets I'd like to see are:
    • A more flexible suggest box (that can make suggestions anywhere and has a configurable trigger character; both things are relatively easy to add to the current suggest box).
    • A tab bar where one can add widgets to the right of the tabs (right-justified).
    • A span-based HTML widget.
    • Tables: a table that can be translated back to a model (with the incubator's ScrollTable, row numbers change when sorting), a table with grouping (see SmartGwt), and a tree table.
    • More events: an OnEnterKey event for TextBox and onChange events that are fired whenever a change happens; not just when un-focusing a TextBox or TextArea.