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 Java-To-Javascript compiler with a java.lang API implementation — although the idea is great it is not exactly a new one. At least one more project (J2S) provides similar features and in fact provides a more advanced JavaScript generation facilities.
- 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
- Sexy
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.
An obvious solution to this problem was to encapsulate the hacks behind a clean interface. A less obvious solution was to also encapsulate it in a statically typed language with a host of IDEs and debuggers and try to avoid JavaScript alltogether in the application itself. So GWT is a perfect solution to quickly develop AJAX desktop-like applications that will run on majority of browsers with considerably less testing.
But what about the rest of us (especially those who write large business applications)? My opinion is that it would be a great view technology, if it wasn’t based 100% on JavaScript. The problem with HTML and JavaScript is that there are at least 4 large incompatible implementations of the platform in the wild. We are talking about a language having 4 virtual machines that loosely correspond to a hindsight standard — James Gosling’s nightmare come true.
One of the main reason web is used so much for business applications is because it delivered on the Java promise to Write Once Run Anywhere (as web platform is much simpler than Java and less dependent on the client environment). And it also gave us the possibility of easy mashup, integration, retrofitting design, etc. But JavaScript makes this promise moot, browsers have:
- 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
All of this means that you can only encapsulate so much — sooner or later some more resilient bug will crawl up or you’ll need to do more than possible with the standard toolkit and you’ll have to resort to JavaScript hacking. In fact I can almost promise that in any sufficiently large and complex application this will be rather sooner than later (and I mean bugs like memory leaks, which are next to impossible to debug on this platform). Indeed, HTML and HTTP were never meant for applications, they were developed to share knowledge among scientists. And although later the dynamic DOM, CSS, XML and other abbreviations were added on top of it they fit almost as well as a saddle on a cow — one can ride, but one doesn’t get very far.
Now let’s switch for a moment from AJAX to the business applications themselves. A typical large enterprise application has different UI requirements than a typical desktop one. Business application GUIs have large complex workflows, but only small part of them need to be highly responsive (typically some kind of lookup or searching). These requirements are easily satisfied with HTML and a little browser independent JavaScript slapped on. In fact if we examine what business customers want it is the software that
- 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.
).