Google Web Toolkit has captured the minds of many a web programmer around the globe with its promise to make AJAX web development easy. But how well does it deliver, and, more importantly, how much do we need that?
First of all a disclaimer — I find the Google Web Toolkit (GWT) sexy both as a developer and a framework architect. It’s a great piece of software, made by very talented people. The trouble is that sex appeal matters little in the field of enterprise software development. I mean custom-made software that has hundreds or thousands of use cases with complex interconnected business and GUI logic. This is the software that matters to the most of the programmers out there, as it is responsible for the most of the job places. And this is the kind of web application development I am going to talk about.
Let’s begin by summing up the innovation that GWT brought to the (Java) web development community:
- A widget library that allows building UI without HTML. There are several similar efforts including Dojo, and the same J2S/RIA. Additionally there are several server-side frameworks that aim to provide the same functionality (e.g. Echo2, wingS)
- An RPC-over-HTTP implementation, which was available among others via DWR.
- A container that allows debugging the application in Java. J2S doesn’t really need it as it translates SWT/RCP code, which runs natively as a desktop application.
- Project kickoff scripts inspired by (or at least similar to) Ruby on Rails.
So Google basically went to this enormous trouble to reimplement all those available projects. Of course one can argue that they implemented a better designed, better working and better documented code (which frequently makes the difference between a successful and a failing project). But why didn’t they join the Eclipse project like countless others and lead the RCP/RIA stack?
My answer to this question is simple enough — Google wanted to solve their own problems. To understand GWT we need to understand Google motives in creating it. Google does not make business software — they make desktop software and put it on the web (e.g. GMail, Base, Spreadsheet, Calendar, etc). Such software has relatively few use cases, which usually are complex and must be very responsive.
Google needed a way to develop new applications for the web that would be
- Highly responsive
- Developed quickly
The obstacle to the second goal was that to achieve a highly responsive GUI in web one needs to resort to a lot of hacks, and, what’s worse, to different hacks in different browsers. It is this issue that makes the development of an AJAX application cost much more than a usual one.
- Restrictions on the size of the script
- Restrictions on the script memory consumption
- Restrictions on the running time of the script
- Cross domain access restrictions
- And a horde of other arbitrary restrictions, bugs and incompatibilities sent by Satan to torture web programmers
- Fits their needs
- Can be made quickly and for a reasonably price
- Does not tie them to a single vendor or partner
- Can be integrated with other software easily
It is badly analyzed software that plagues the business world, not the non-AJAX one. And it is high productivity and integration that is first of all needed from a web framework — perhaps this is one of the reasons why Struts is still so popular (the main being of course tons of legacy code written in it). And AJAX, if anything, makes integration harder and decreases productivity.
But does that mean that I am propagating simple web applications forever? Of course, not! I just think that simulating the desktop while depending on Intenet Exporer is something that a business client just can’t afford. Make already a normal rich GUI platform and I’ll be the first one to get on that train. Get Eclipse RCP polished or compile Java to Adobe Flash (which is at least a stable platform), perhaps even get Avalon to run on Linux. Just give me something that lets me write code in Java and doesn’t give me more trouble than web and I’ll sign on without another question.
So will Google Web Toolkit matter for the next years? I sure hope not, since this would mean that we build our next-generation applications on an intrinsically sabotaged platform. And no matter for my bias, I really want to see a better platform before the end of this decade.