What is the current status of GWT

Overview GWT - Google Web Toolkit (PDF)

Authors:
Papick Taboada
Orientation in Objects GmbH
Steffen Schäfer
Orientation in Objects GmbH
Date:December 2010

Google Web Toolkit

The Google Web Toolkit (GWT) received a lot of attention last year, because Google AdWords and Google Wave were the first major GWT-based applications from Google. The innovations in the current version 2.0 of GWT itself have caused a stir. But what is GWT? Customized JavaScript applications are created with an optimizing compiler and clever code generators, but they are developed in Java. The following article introduces the basic GWT concepts, followed by a brief overview of what's new in version 2.0 and architecture “best practices”.

Web 2.0 software development

Web development today puts both decision-makers and developers in a difficult position. Due to a technologically hardly definable "Everything is possible with Web 2.0" expectation of the client, very high goals are set, on the other hand one would like the web of tomorrow (see box of the same name) today in the worst case based on one dominated by Microsoft Internet Explorer, Version 6 Operate yesterday's landscape. Sustainable decisions should then be made within this framework. And it is not uncommon for the right choice of a web framework to mutate into an uncontrolled corporate policy requirement for a long-term client strategy.

The strategy of the future often bears the title "RIA". Under the umbrella term "Rich Internet Application" (RIA), various approaches were presented on how to transform the original HTML terminal (browser) into an application platform. The aim is to combine the advantages of both client models (web and rich client) in one solution:

  • Uncomplicated software delivery:
    Web applications do not need to be installed and updated, the application is always up-to-date. Changes and bug fixes can be imported and rolled out quickly compared to rich clients.

  • Low latency in operation:
    In principle, rich clients process the user interaction locally (apart from incorrect implementations ...) and can relocate the server communication to the background.

  • Appealing user interface:
    Rich clients often offer a greater variety of GUI components and thus greater flexibility in the design of (complex) user interfaces.

An RIA strategy is not without consequences. In this approach, the seasoned web application developer is confronted with a paradigm shift: Known and tried and tested architecture patterns, idioms and tools from classic web application development lose their validity, their meaning and / or their usefulness. While design patterns from rich client development are experiencing a renaissance here, development tools are faced with completely new requirements. Most of the libraries that have been used up to now can no longer be used, and solutions that have been developed no longer work in the new architecture.

But what is the web development of tomorrow? A look into the past shows a browser that over many years - despite technological and security deficiencies - was able to establish itself as the market leader as the de facto standard. Also with regard to standards (HTML, CSS, JavaScript, HTTP) there has not really been any further development. Seen in this way, web frameworks have had a stable goal for many years - and yet no standard has been able to establish itself here: A phenomenon like the one we experienced with the Struts project has not been repeated in modern GUI component-based web development.
A look at the current events shows earthquake-like progress. With HTML5 the stuck web standards are moving: Flash and applets have - among other things - filled gaps in the capabilities / possibilities of pure DHTML development. These gaps are now partially closed by HTML5, with the result that even more can be solved with JavaScript in the future. Web 2.0 applications are already partially characterized by the fact that they do not use non-DHTML technologies (Flash, applets). So we already know today that there will be no less JavaScript tomorrow.
What remains is the daring look into the future: Two large companies have placed themselves behind HTML5 - namely Google and Apple. With the exception of Internet Explorer, all modern browsers largely understand the unfinished HTML5 specification. Microsoft has announced HTML5 support in principle. This means that it is already clear: tragically, HTML5 will not play a role in the medium term - we will have to wait for Internet Explorer here. In recent years, companies have not shown themselves to be particularly willing to migrate. If this behavior does not change, then HTML5 will not play a role in the long term.

Due to the massive use of JavaScript, RIAs are now possible without the use of proprietary solutions (plug-ins). However, you suddenly find yourself in a pure JavaScript development. This leads to new problems:

  • A good Java developer is not necessarily a good JavaScript developer.

  • While the implementation of the JavaScript language in the browsers is now sufficiently compatible, the DOM manipulation required with DHTML is very different in the browsers.

Understandably, many shy away from this route, as the necessary JavaScript and browser know-how is rarely available. In this environment, the Google Web Toolkit came in to solve the problems in team scaling and the lack of software engineering in web application development.

The Google Web Toolkit 2.0

The Google Web Toolkit (GWT, often pronounced "Gwit") is probably one of the most misunderstood technologies in the Java environment:

  • GWT is not a JavaScript toolkit such as B. Dojo

  • GWT is not the transfer / imitation of the Swing component model in the browser

  • GWT does not use any services from Google

  • GWT is now also used by Google [Schu09]: Google AdWords and Wave are developed with GWT

Technically, GWT is a Java-to-JavaScript compiler and allows the developer to write an application in Java and then compile it in JavaScript. The GWT compiler reads the Java source text (Java 5 syntax) and converts it into JavaScript. The GUI component model provided by GWT is primarily a mapping of the HTML components. In addition, a handful of complex GUI components such as tab panels, dialogs and trees are offered. GWT also provides very special solutions for internationalization, RPC communication, browser history management and many more. From this perspective, GWT can also be viewed as a framework.

In development, GWT distinguishes between two modes:

  • In development mode, the application is started in the "Development Shell" supplied with GWT. This internally starts a Jetty server as a web container. There is no complex "packaging & deployment". Since GWT version 2.0, the application can then be tested with different browsers. Since the bytecode is executed in the development environment at this point in time via a special mechanism - completely without JavaScript generation - and no JavaScript was generated, a code change in the development environment is immediately visible through an update in the browser. This special mechanism also enables the setting of breakpoints in the Java source code and even debugging of the application in the Java source code.

  • The application is then finally converted to JavaScript using the GWT compiler. This is called production mode, the application is no longer executed via the special mechanism, but as a pure JavaScript application.

By using clever code generators during the compilation process, not just a single web application is created, but variants for all supported browsers and declared languages ​​(i18n) are generated. So z. For example, the GWT compiler for an application that has been internationalized into three languages, eighteen different web applications. This ensures that every browser only has to load the necessary JavaScript code and the language used that is suitable for it.

GWT can compress the generated JavaScript (GWT calls it obfuscation), pack images and other resources into a file, generate lean RPC code and do a few other optimizations. Since GWT version 2.0, the developer has been able to define so-called split points: The compiler examines these points for cross-dependencies and tries to generate reloadable fragments using the marked areas. This makes the initial download of the JavaScript application a little smaller, since independent parts can be reloaded if necessary.

Usually a GWT application (the products of the compilation process) is delivered as a WAR archive. The need for a Java EE web container is only given if the application uses the GWT-RPC mechanism. This is based on the servlet specification and requires a corresponding runtime environment.

The modern web application follows the "single page" principle

Thanks to Ajax and DHTML, there is a change in the architecture of web applications. The browser is suddenly no longer used as a stupid HTML terminal, but as an application platform.
At this point we speak of the “single page” principle: A web application is loaded into the browser once, and there is no more page hopping. The latency generated by the request-render-response cycle is completely eliminated in this approach. For this, the user has to accept a larger initial download of the application (the first HTML page), which can then remain in the browser's cache.
In contrast to the classic approach, not every user interaction leads to a reload of the page. All user interactions are processed in the browser. Communication only takes place when data is required by the server. Only the required data is then requested and not the entire page again, because the data is then processed and displayed by the web application.
In an Ajax-ified architecture, server communication is reduced to a minimum. This not only saves server-side resources, but also reduces the latency in the application.

Since, according to the HTTP specification, a browser can only establish two connections to a server, GWT offers mechanisms to reduce the number of resources to be loaded. In GWT one speaks of so-called "ClientBundles", in which, for example, images are combined as a mosaic and CSS resources. Images are then displayed correctly again in the browser, for example via CSS clipping.

The compilation process does not become a weakness but a strength of GWT. This enables a separation between development or project and deployment layout. For maintenance reasons, resources are pragmatically managed individually in several fragments during development. The compilation process then repackages the resources so that HTTP connection bottlenecks and caching aspects can be taken into account.

The Google team provides a plug-in for development in the Eclipse IDE. For other development environments there are various solutions from third-party providers or from the open source community. In the meantime, a very large community of developers is gathering around GWT, which is evident in the number of books, projects and blogs on the topic of GWT.

In direct comparison to other JavaScript toolkits, the components provided by GWT perform very poorly. The GWT team has so far considered its own component model as a pure representation of the HTML components, but the modest appearance and the lack of complex GUI components such as a data table are often seen as a major shortcoming. The lack of data binding, as known from other web frameworks, is also often criticized. Various open source and commercial projects have now filled these gaps.

That is why GWT does not stand for "eye candy", but much more for software engineering in web application development. Discussions, unofficial announcements in the official GWT mailing list and the current commits in the SVN trunk of the project strongly indicate that the problem of data storage components and data binding is currently being tackled for the next release. On the subject of "eye candy", the message is clear and precise: GWT applications can and should be adapted via CSS. Toolkits with extremely sophisticated GUI components all have one thing in common: The components are difficult to adapt because the CSS provided is very extensive (and confusing). Sometimes less is more ...

GWT and software engineering

The development of a JavaScript-based RIA redefines web application development. Known approaches lose their validity, old design patterns are used again. In classic request-response-based web application development, various approaches to solving the problem of page navigation have been developed, a problem that RIAs are not familiar with. On the other hand, RIA applications as well as rich clients are allowed to deal with the problem of data transfer between client and server, a problem that technologies that work on the server side are cleverly solved by ORM tools and lazy loading and a handful of "best practices" to have.

As with any software development, expansion and maintenance costs play an essential role in the life cycle of a web application. We are looking for methods and procedures that lead to better software quality in advance, and architecture patterns that promote sustainable maintenance of the web applications.

Fortunately, thanks to the "Java to JavaScript" approach, we can also use the same tools and methods for web development that we have been using for years for quality assurance during Java software development. Refactoring as a method and findbugs, PMD and Checkstyle as tools are representative here.

Unfortunately, due to the fragmentary Java support at runtime, neither Reflection nor Dynamic Proxies are available to us, so that some of the established frameworks and techniques from rich client development cannot be easily transferred to GWT development. This restriction makes sense, however, because integrating all the required metadata and providing a runtime environment similar to Java would cause the JavaScript application to swell to an unacceptable size.

Architecture "Best Practices"

The "Best Practices" presented here for the architecture of GWT applications come from a lecture by Ray Ryan at Google I / O 2009 [Ryan09, pgt09]. These architectural patterns were obtained from the new development of the AdWords application from Google and presented in the lecture:

  • EventBus:
    Communication of individual components in the application via a central event bus.

  • Command pattern:
    Client-server communication via action result object pairs.

  • Model-View-Presenter:
    Structure and behavior of the UI components. In this approach, there is no direct access between model and view, the entire behavior of the user interface is encapsulated in the presenter and can be unit-tested.

  • Places:
    A "Place" abstraction and the use of GWT's History API are used to regulate forward and backward navigation as well as jumping to the application via a bookmark.

For reasons of space, only EventBus and Command Patterns are presented in more detail in this article.

EventBus
A well-known phenomenon in software development for developers and architects is the proliferation of references between objects, which makes changes difficult to implement.
An EventBus is introduced so that individual components (the definition of the granularity of a component is ultimately left to the developer and / or software architect) are not linked to one another via references. Since GWT allows the event model to be expanded, the existing infrastructure can be used at this point. Typing is guaranteed by introducing own event classes.

Illustration 1: Fig. 1: Master-detail view using the EventBus

A simple master-detail view is presented as an example. Instead of wiring both components (MasterView and DetailView) to one another via a reference, the perceived detour via the EventBus can also be selected (see Fig. 1). The procedure in detail:

  • An event class and the corresponding event handler interface are defined

  • The detailed view registers with the EventBus for a specific event class

  • The MasterView fires events via the central EventBus when data records have been selected

  • The DetailView is notified of the data record selection by the EventBus and displays the data

In principle, it is the well-known observer pattern. In the case of an extension (another component, for example a bread-crumb navigation component introduced afterwards), you can also register on the EventBus for the same event and update the navigation display accordingly when a selection event occurs.

Not only is it easy to expand, it will also be possible to remove the bread-crumb navigation that has been introduced without any side effects: it is sufficient to remove the component from the system. As a result, the component no longer logs on to the EventBus and is no longer notified.

Command pattern
The command pattern addresses, among other things, the problem of uncontrolled growth in service interfaces. In client communication in client-server architectures via RPC interfaces, it is not uncommon to find a multiplication of data transfer objects that are technically assigned to one and the same domain object. This multiplication arises from the technical approach to solve the problem of partial data transmission for different masks. In the following interface, this is demonstrated using the "customer" domain object as an example:

This interface is then used by all components in the software that want to display customer data in some form. The restriction of the data to be transmitted can be both technically sensible and technically necessary. The definition of several transfer classes ensures type safety in the different use cases. Such interfaces quickly lead to software that is difficult to maintain, as they cause an explosion in the class model on the one hand and create links across the various components on the other.

The approach proposed by Ryan with the command pattern replaces the interface-oriented RPC approach with an event-oriented approach: The communication to the server is modeled via action / result and handler classes (see Fig. 2) - the interface as such is omitted without type safety must be abandoned. The granularity of such action / result pairs can vary in the application. Coarse-grained actions in the sense of "Give everything the mask needs for the initial display" up to very fine-grained actions such as the individual validation of an input are conceivable.

Similar to the EventBus, the effects in the maintenance of the software are remarkable. The communication system is expanded or shrunk by simply adding the triple (action / result / handler) or by deleting a triple. The result classes are linked to the action classes and are only used in their context so that there is no explosion or wild growth in the object model. Even the problem of operating several versions of a service is taken into account by optimizing the way of the interface.

Figure 2: Fig. 2: Structure of a dispatcher infrastructure

The heart of the command pattern is the dispatcher infrastructure. There is already one or the other ready-made approach in the open source community. Thanks to the central nature of the dispatcher service, error handling, caching, retry algorithms, security information, etc. can be implemented centrally at this point.

Conclusion

Thanks to GWT, software engineering can finally find its way into web application development. Even if the GWT components do not win a beauty contest, it is the inner values ​​that make GWT so attractive. GWT left the perceived "early adopters" status with version 2.0 at the latest and is now "production ready".

GWT enjoys the unusual status for an open source project of not having to worry about funding. Google not only has a strong interest in more and more developers writing JavaScript applications (and thus possibly indirectly creating customer loyalty by creating mashups), in the meantime Google is also developing important products with this tool itself.

However, there is still a lack of experience in developing complex GWT applications. The deficiency was addressed thanks to Ray Ryan's architectural "best practices". The clear requirement is: decoupling. The open source community has already reacted and, in line with these experience reports, has launched a number of projects so that the introduction and practical implementation of these design patterns are made easier.