GWT

GWT is a reasonable implementation of a poor architectural choice. GWT attempts to hide many of the details of the web as a platform by creating desktop metaphors in Java and generating JavaScript code to implement them. First, in many ways, JavaScript is more powerful and expressive than Java, so we suspect that the generation is going in the wrong direction. Secondly, it is impossible to hide a complex abstraction difference like that from event-driven desktop to stateless-web without leaky abstraction headaches eventually popping up. Third, it suffers from the same shortcomings of many elaborate frameworks, where building simple, aligned applications is quick and easy, building more sophisticated but not supported functionality is possible but difficult, and building the level of sophistication required by any non-trivial application becomes either impossible or so difficult it isn’t reasonable.

In the last radar we placed the Google Web Toolkit (GWT) on hold and tried to provide a few reasons for that decision. As it turned out the conciseness of the text didn’t allow us to adequately make our points so that they were not misunderstood. We are interested in a discussion but our opinion about the suitability and usability of GWT has still not changed.

Google Web Toolkit (GWT) offers an interesting premise: write Swing-like Java code and generate unit testable JavaScript widgets and user interfaces. From a practical standpoint this doesn’t work well. First, using code-gen to produce the artifacts is time consuming, artificially extending build times and requiring manual changes to obtain optimal package layout. Second, if the JavaScript doesn’t behave exactly as you want you will have to hack the generated code. Third, using Java to generate JavaScript means that you can’t take direct advantage of the powerful features of JavaScript or numerous libraries such as JQuery. Finally, the JUnit support is quite limited, for example code using reflection cannot be tested.