Every Flavour Beans

So why should an Ajax developer be interested in the recently released Google Web Toolkit(GWT)? One possible reason could be to overcome the shortcomings of the typical Ajax web development model as noted in my earlier post. Firstly, a framework always provides a head start to a project, allowing the developers to worry only about writing the application logic; user interface elements, the plumbing work needed for the communication between the client and the server are provided by the framework itself. The more specific benefits of using the Google Web Toolkit are:

1. The developer is relieved from the thankless job of understanding every single way in which the browsers differ from one another in handling the same web page, allowing them to create websites such that all these web browsers handle a page in (roughly) the same way.
2. GWT allows the developers to interact with the browser’s history stack which means that the Ajax applications created using GWT can allow the users to use the ‘Back’ and ‘Forward’ buttons of the web browser and to bookmark the various pages of the website.

   Refer to points 2 & 3 in my earlier post.

3. Developers can use a more modular and statically typed programming language in Java to create the interface and other components instead of hacking their way out with Javascript. Ultimately, its still the JavaScript code that is generated and served to the web browser, but GWT provides an abstraction layer that shields the developers from having to do much with the JavaScript language. The flip side of this is that for pure interface code, Javascript might offer a more natural solution than Java language when it comes to creating web pages; see the discussion below.

   Refer to point 1 in my earlier post.

   Being able to use Java to create Ajax applications also means better integration with the rest of the Java web development technologies like JSP, JSF, etc(note that code written using GWT uses the Java Web UI class library which is not related to any of the Java standard libraries and this code is statically translated to Javascript and HTML code before making available to the server. Integration would be limited to sharing something like a Java component between a JSP page and the code written using GWT). This may not appeal to those who are using other server-side technologies like PHP and ASP.NET.

   Java language also boasts of better programmer IDEs and tools with good support for Unit Testing and Refactoring. In fact, GWT itself has good JUnit integration through easy to use class libraries in the package com.google.gwt.junit.

   Javascript code can still be embedded within the Java code if only the services of the Javascript language are going to solve a particular problem, by using the Javascript Native Interface(JSNI)(on the lines of JNI). See this for more information.

4. The biggest advantage of using GWT for creating Ajax applications is the relative ease with which the data can be communicated between the server and the client by just creating serializable Java objects.
5. Good support for debugging. Eclipse IDE and GWT host mode form a good combination for convenient debugging of the GWT applications.

Having said all this, I am not a big fan of static translation of one programming language to the other. If it were as unified as in ASP.NET(see ASP.NET WebParts; all the translation happens at run-time), I would have welcomed it whole-heartedly. But different programming languages are created to solve different problems, and they are optimized to that specific job. I hate Javascript language for many reasons(as I do in case of Java) but still believe that Javascript is better oriented towards creating client-side code for the web browsers than Java language is(when the intention is to create a web interface). Are we going to use Java idioms here or are we going to try to imitate the Javascript idioms in the Java code? How many Java libraries are supported by the GWT SDK tools? What about the unsupported libraries whose functionality is needed for the application?

Secondly, the entire translation process is lengthy and inefficient: create an empty GWT application using the GWT SDK, fire up your favourite Java editor(eg: Eclipse) and create the Java source files in it, translate these Java files to Javascript + HTML files and finally integrate them with the rest of the server-side code(PHP, JSP etc). But there are advantages we get out of this investment as noted in the above mentioned points.

Not all the standard Java libraries are supported by GWT. For example, only java.lang and a part of java.util are supported by the GWT tools, which means the code written using Java libraries not supported by GWT cannot be translated by the GWT tools. The developer needs to make a call whether to achieve the desired functionality by writing custom Java code or by writing the code in Javascript.(I would be tempted to go the second way as that would allow me to use the same code in other applications that don’t make use of GWT).

By the way, why don’t we have the access to the GWT source code? Isn’t Google a big supporter of the Free Software community?

For developer centric GWT related discussion, go to the GWT Support Forums.
Related Post: A Case Against Ajax Web Development Model