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.
- 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 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).
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).