Using GWT to Build a Large Web Application
For those new to Google Webtoolkit (GWT) its an open source framework that compiles Java into optimized Javascript for web applications. Being able to develop AJAX applications in Java allows you to build in Eclipse or Maven and use other Java tools like JUnit. The GWT team here in Atlanta (day trips) has done an incredible job optimizing their compiler and libraries. We chose GWT for DayZipping after positive experiences using it for several smaller projects. Here's an overview of what we have learned from building applications with GWT for over a year.
Optimization and Abstraction. The GWT compiler creates Javascript files for each major browser and at run-time selects the appropriate version. This allows your developers to develop highly optimized code without being aware of all the intricacies of each Javascript implementation. For example, you can embed image URIs in your original page requests and have all of the implementation details handled under the hood. Their optimization work can lead to large efficiency improvements, especially for developers with less experience writing AJAX applications.
Significantly reduce server load. The GWT project structure allows you to efficiently cache all relevant Javascript. Projects have a small bootstrap file that is never cached. This initial Javascript download requests the correct implementation file based on file content hashes. Because files are name according to their contents a new version is only requested if that specific file has been updated. After appropriately setting cacheing headers you can reduce load by not repeatedly transferring client-side logic or UI details but you also don't have to worry about having stale Javascript files. This structure allowed DayZipping to serve 120,000 pages over a several hour period on a 1.5 gig slice after a link to us was posted on the front page of Aol. Had we generated these pages server-side we are pretty confident there would have been serious load issues.
Java programmers can hit the ground running. We have found that both web developers and traditional programmers generally feel comfortable building things for the web in GWT. Since web developers understand the underlying DOM manipulations it quickly becomes clear how GWT widgets and utilities interact with the browser. Conversely, Java developers can ease their way into a web framework with familiar libraries and unit tests. One of the nicest things is the toolset available for a web development environment. Having compile-time checks with breakpoints and other tools makes a large difference once you have several thousand lines of code. One caveat here is creating a workflow that is effective for a designer to quickly implement different UI iterations. We suggest looking into the new UiBinder as one way to encapsulate the view components. That being said we have found GWT to be a less than optimal environment for designers largely because of the overhead of working in a full-service IDE. Note that Google has created a development mode so that you don't have to compile your project until you deploy.
SEO overhead. GWT comes with a nifty history manager that uses hash tags for page references. This manager can significantly reduce page load times by building new pages within the DOM as opposed to a new page request. Google has implemented an AJAX spec to make these pages indexable. Following Google's URL spec informs their spider that their is a mirrored static implementation of this page. You are obviously responsible for maintaining these static pages. While their spec effective after some work on your end, Google is currently the only search engine that supports this mapping. This means that you will currently not have these pages indexed on other search engines. Additionally, you have the maintenance of updating this additional static copy. To avoid cloaking these static pages have to immediately reflect all updates in your GWT project. If these pages are generated from dynamic content expect to have to fully rebuild these pages in a server side implementation. For an agile startup that regularly pushes code this creates a significant burden by required maintenance of an additional copy of each page.
Social intergration. Hashtag history management also comes into play with Facebook's cache. As expected, their caching ignores all hashtags. So example.com/#home is redirected to example.com/#article/57 if it was shared within the last 24 hours. The current work around is to set a page specific or random get parameter, because Facebook is not currently respecting nocache directives. Setting a unique identifier isn't ideal because there isn't an easy way to update a get parameter and stay inside the bounds of GWT's history manager.
So far we have had a great experience building AJAX widgets and non-indexed pages with this technology and our site is likely a magnitude faster than it would be with other frameworks. Our biggest suggestion for someone building a consumer web app that needs to interact with social and extensive search indexing is to map out your URLs appropriately. Those looking to employ an iterative development model with a designer in their team should take some time to experiment with different workflow arrangements to find out what works best with your team. All in all we have been very pleased with our experience with GWT and would be happy to answer any questions for teams considering GWT as part of their stack.
