Background
In the spring of ’06 our team set out to build a general purpose geographic information system capable of presenting massive amounts of location-specific data in a user friendly interface. Our resulting product powers MapEcos.org, launched last November. MapEcos provides pollution data and information on pollution improvement efforts for over 23,000 industrial facilities across the United States. Our team built MapEcos along with business school faculty at Dartmouth, Duke, and Harvard as both a public service and a vehicle for academic research. We organize EPA data in a way that allows the public to learn more about the facilities, companies, and industries that affect their local communities, states, and the US as a whole. In addition, we encourage facility managers to post information on MapEcos about their environmental improvement efforts.
The Google Web Toolkit is a critical component of our web application (and, while we won’t address it in great detail in this post, the same should be said for the Google Maps API). We are pleased to be able to share some of our GWT thoughts and experiences with you:
Java wins over JavaScript: For a few months, we attempted to implement some of our low-level map features in JavaScript. We were wasting our time. As a language, Java doesn’t suffer many of the idiosyncrasies and complexities which can make JavaScript programming complicated, tedious, and unproductive. Our overall productivity increased dramatically as we began to re-implement and expand previously written JavaScript features in Java; we re-did months of work in a few weeks. Now we are able to share code between our client and server applications. The ability to use standard Java debuggers to identify problems in client code is also a noteworthy plus. In short, we find that GWT (nearly) brings the desktop application programming experience to the web.
As simple as necessary but no simpler: GWT is versatile. UI components are well thought out and implemented and often sufficient for our needs. While the toolkit provides useful high level abstractions, it allows us to implement low-level solutions in unusual circumstances. We use GWT’s DOM abstraction for low-level tweaking when necessary (e.g., to force GWT elements to appropriately overlay elements drawn by Google Maps) and we implemented our wrapper to the Google Map API using JSNI (Note: there is a fairly comprehensive open source maps library for GWT which might allow one to avoid JSNI altogether, depending on the needs of the mashup).
JSON and XML are well supported: We wanted to be able to present dynamic content on our map that wouldn’t necessarily come from our own back-end (i.e., the web server for the map application). By separating our lightweight map application server from the server instances that provide the MapEcos data, we are able to scale to support site load. GWT’s JSON and XML support made our job easy. The MapEcos data servers provide marked-up content containing facility, company, industry, and geographic data to a map application that doesn’t know much about the data it displays (we note that there are some security gotchas to avoid when providing this level of flexibility). Granted, JSON and XML aren’t unique to the GWT framework, but working with these standards on the client-side of an application has never been easier.
Oh, the time that we’ve saved: GWT does away with the idiosyncrasies of JavaScript without perceptibly compromising functionality or performance. More importantly, because it’s both powerful and easy to use, the GWT framework frees up valuable development time and allows us to direct our limited energy to our most pressing needs. As a result, we feel that the Google Web Toolkit has helped us build a better site.
We encourage you to take a look at MapEcos and learn more about environmental performance in your community. Comments welcome at info@mapecos.org.
