My Take on GWT

Mon 08 February 2010

The Google Web Toolkit is a set of tools that allows you to write, in Java, Rich Internet Applications, that is applications running in your browser while looking like desktop application with features like rapid GUI updates, drag & drop,... At its core, GWT is a compiler of Java to Javascript, but it also includes a full development environment, and generates very nice serialization mechanisms for your application to transfer objects from your server to the client browsers. In the latest 2.0 version, it also includes tools to profile the performances of your applications.

I have now been using the Google Web Toolkit at work for 13 months. I can consequently talk about it confidently, even if what I will say is already out of date, since I am still working on the 1.7 version, while the 2.0 version has been out for three monts, fixing a lot of my gripes with the toolkit.

The standard workflow for writing GWT apps is as follows :

  • first, write a backend in Java using your libraries/framework of choice (backend in other languages are possible, but definitely will not feel as natural).
  • second, write some servlet on top of your backend, implementing a GWT interface that will cause serialization code to be added at compile time. Now your servlet can be queried by a GWT compiled client.
  • Third, write, still entirely in Java, your client designed to be ran in a browser, using classes reminding Swing for the interface (TextBoxes, FlexTable, ...). This java code will be compiled into javascript (which is at the same time genius and evil, IMHO).
  • During the development, and during debugging, you can use a hosted mode, where your code is running into an embedded browser (an old version of Internet Explorer until the 2.0 version of GWT, if you are working on Windows) and compiled on demand. This means that you can modify your client code, hit reload, and see the changes immediately and that you can debug it using the standard Eclipse debugger view. Even if it is a bit slow, especially while debugging, since all code is compiled on demand, it works flawlessly.
  • On the client side, when you make call to the server, those calls are executed asynchronously, meaning that a call to your servlet method MyObject getMyObject() will return immediately without output, deferring the response of the server to a later date and to a method handleSuccess(MyObject myObject). This constraint is clearly coming from the browser constraints (not many threads are available, and to keep UI responsive, you can not monopolise a thread too long), and cannot really be avoided.

Now, from the trenches some remarks about this nice theory :

  • The development process is quite slow : I think that waiting too long between the moment I write some code and the moment I can see the results on the screen can make me loose a lot of momentum. With GWT, when your application reaches a reasonable size, if you write a piece of code spanning over your client and your server (adding a parameter to a backend public function), you will have to recompile you server code, launch the hosted mode (which takes about a minute on my pc), and suffer the sluggishness of your interface in hosted mode to get to the feature you want to test. I often find myself wondering what it was I wanted to test, after so much time ... Furthermore, once you are happy with your new feature, you still have to compile your project completely, and it can take a lot of time, since the compilation has to take place for every supported browser (a different compiled version is made available for each one, taking into account discrepancies in the javascript engines implementations) and it definitely consumes a lot of CPU.

  • The toolkit in development consumes a lot of resources : I think it is quite unpractical to use GWT without using the corresponding Eclipse plugin and consequently, without using Eclipse. In my case, Eclipse easily consumes 1GB of ram. When you launch the hosted mode of GWT for my app, about 800 megs of ram are eated again. As Windows XP, my database (MySQL), my server (a JBoss) takes about 1GB of ram together, and since on 32 bits windows, it is difficult to enjoy more than 3 GB of ram, programming in GWT, especially when you use the more memory demanding debugging mode, is a game of attentiveness: I always must carefully avoid to get to the point where my system is swapping, a state from which it can take many minutes to get back from. (A solution could be found by using more memory and a 64 bits OS, but until recently, the hosted mode of GWT was not running nicely in 64 bits mode and I do not know what is the current state of affaire about this).

  • Fortunately he abstraction of javascript is not leaky. I never needed to take a look at the generated javascript and was always able to use the Eclipse debugger. In my opinion, this is quite astonishing. That said, on the contrary, for the layout of your application, the abstraction is VERY leaky. To get beautiful interfaces, you will have to use CSS a lot and understand it very well. Furthermore, you will have to understand the DOM to master your app layout. For example, getting a nice resizing behaviour can be quite demanding : the only trick I know to ensure that a resize goes well is to empty a DOM parent of all its DOM children, wait that it takes its size according to the grand parents constraints, then put back all the children in the right size. This is not exactly abstracted from the DOM intricacies. That said, if you have better tricks for handling "windowing" apps, I would be glad to hear about it.

  • Having access to all the Java base language is great. For example, it is totally possible to throw an exception on the server side that will be caught on the client side. I use that for example to report errors during data imports and this is much better than handling special error return codes for my functions. Furthermore, being able to use complex data structures (TreeSet, for example) and objects built on the top of them and debugging them easily is a great advantage, and probably the main reason why my current project would not have been possible without GWT. I can not imagine myself handling very complicated structure in pure Javascript, with its broken object model. That said again, one downside is that not all the Java standard API classes are present in the GWT libraries usable on the client side. For example, Calendar is not available, which lead to major pains in my project.

  • Finally, do not be fooled by the fact that you are writing in Java: you are still very limited by browser imperfections and you should save your resources, as much as possible. I for example, discovered too late that displaying one hundred labels of text in a FlexTable takes MUCH too much time to render in Internet Explorer 8. That said, obviously, I should have known that hundred is a limit number that no computer should ever be forced to handle....

In conclusion, I can say that I have a love/hate relationship with GWT, but that I sincerely hope that when I will be able to use version 2, once we have refactored all legacy code, most of my gripes will disappear: I will have faster compilations, less resource consumption (thanks to the new development mode, where you can use your browser of choice ? ), and less leaky abstractions (thanks to the new Layout Panels ? ). That said, I think that GWT is very alone in its niche : allowing to build intricate web applications that will not depend on an external browser plugin to work, while allowing you to use a battle proven programming language and relying on its community. In fact, I think that GWT is alone in this niche which makes it the de facto king of the hill...

(well, there is Pyjamas a Python port of GWT but it lacks the support of a big company like Google).

Feed - About me

comments powered by Disqus