GWT - it's not you, it's me
Having sung the virtues of Google Web Toolkit for well over a year, I did an experiment. I rewrote a section of a prototype GWT application using JavaScript and YUI. It took me less than two hours, including time to consult the excellent documentation. The YUI version was deployed this afternoon.
Those of you who follow me on Twitter will be used to my occasional rants about web development. I love my job, but almost every day think that there has got to be a better way to do things, particularly on the client-side.
As we all know, the web started out as a way of displaying documents, regardless of computer type. This collection of hyperlinked documents somehow managed to become the runtime of the 21st century. It doesn't matter if you run OS X, Linux, Windows - a vast amount of what you do on a computer these days is in a web browser. Fact. Don't believe me? Unplug yourself from the network - turn off your wireless card. See how long you last.
Due to our reliance on the browser, JavaScript has become the world's most popular language.
Douglas Crockford, creator discoverer of JSON and author of one of the few decent JS books excellently sums up the misinformation and understanding that surrounds JavaScript. "...JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures."
So why on earth did I attempt to write a web front-end in an arguably inferior language: Java, with the Google Web Toolkit?
I'll hold my hands up. Despite being able to churn out a lot of JavaScript code, I guess I didn't know JavaScript.
When Google released the Google Web Toolkit sometime in 2006, I was intrigued. I had dabbled with creating AJAX-y front ends of my own but almost consistently had ended with very brittle code. $$ and $A and $ functions made me feel unusual. Debugging was impossible. Things would stop working - yet no error messages would be given. With this in mind, GWT made perfect sense. A good UI widget library, strong typing, a compilation step to catch errors early, debugging, excellent IDEs, optimized code for each browser masking quirks and behaviour variation..... oh my, I was sold.
I enjoyed the rigidity of working in Java for client as well as server-side work. Using Eclipse I was soon refactoring frequently, being forced to define interfaces, unit testing, creating mock objects, using dependency injection, creating components, thinking in terms of events rather than forms and URLs... the list goes on and on.
However, in the last week I came to the realization that, with a bit of discipline, I could apply identical development approaches when using plain old JavaScript and YUI. For every perceived advantage of GWT, JavaScript had an answer. Unfortunately, GWT brought disadvantages of its own.
- The built in widget library - calendars, drop down menus, trees, etc - whilst comprehensive, was fairly basic and hard to skin with CSS. Remember the promise of being shielded from browser quirks and variations? Forget it. Any web front-end library is all about the widgets. YUI (and others) are arguably superior.
- Compiling five versions for each supported browser proved to be very slow: 20 seconds on a 2.26Ghz MacBook Pro for a very small app. This may sound like a minor thing, but it did slow the development process down considerably. The rapid edit-refresh-edit development model of the web is extremely productive - live in-browser CSS and JavaScript editing are now also becoming common place. Some advantages of the compilation step can be matched by using a tool like jslint. jsunit also allows in-browser unit testing of JavaScript code.
- Eclipse is a fine Java IDE and the Google plug-in is an excellent addition. Code generation, hinting and completion were all welcome additions having come from a text editor. Refactoring GWT code within Eclipse was something I did frequently - although ultimately my use boiled down to a semi-intelligent search and replace. My time with GWT reminded me how important refactoring is.
- Debugging within Eclipse only worked when running the Java code - you were not debugging the compiled JavaScript. There were differences between what happens in hosted mode and what happens in the browser. In addition, native JavaScript debugging within the browser has come a long way - particularly in recent versions of Safari and Firebug.
- Browser speed. It was easy to forget that one is targeting a web browser. It is natural to think in terms of components, event listeners and forget about the crazy HTML that is being produced somewhere. Although this is the logical assumption to make when using GWT, it is a mistake - the result is extremely slow code. Whilst this isn't such an issue in modern browsers, it is if you want your code to run well in Internet Explorer. For instance: a complicated list of objects took 20ms to render in Safari and 4000ms to render in IE7. 4000ms is unacceptable. The solution? Render HTML in a stringbuffer (or on server) and use element.innerHTML = ".." to inject it onto the page. You throw away all the object-orientated/component/event goodness. The issues with speed are no doubt due to the slowness of DOM manipulation routines in certain browsers which aren't GWT's fault. Regardless, this low-level work around defeats the purpose of GWT to my mind.
- The event bus pattern I previously blogged about is trivial to achieve in JavaScript with a lot less code. Events are core to JavaScript within a browser. Custom event models are extremely easy to implement with a good library such as YUI or prototype.js. Whilst the GWT HandlerManager worked fine, I felt a disproportionately large amount of code was needed.
- JavaScript can be fabulous. It has closures. More can be done in less code. A callback object can be defined inline, in literal form: { onSuccess: function(e) {}, onError: function(e) {} }. I intend to elaborate on this further with some some side-by-side GWT vs YUI code comparisons in a future post.
Maybe I'll be back in a future post saying that I didn't understand GWT (or Java) well enough. GWT will continue to evolve and Google Wave, which is built using GWT, will no doubt be a seriously impressive web front-end.
GWT, particularly the Java-JavaScript cross compiler, is a stunning feat of engineering. Maybe the coolness of the hack is what attracted me to GWT in the first place. But like so many tools made by developers for developers, the beauty lies within - in this case the API and the compiler. The over-engineered end result just doesn't do all of the effort and cleverness justice.
There is much I like and admire about GWT. I may use it again. Regardless of whether I use it in future projects, I have GWT to thank for forcing me to apply proper software engineering approaches to web client development.
15 comments
Thank you for your comment. I believe our views of the "pros" of GWT (and a compiled language like Java) are in total alignment. Tools jslint, while obviously not being a compiler, can help spot certain errors.
The bottom line for me was that the end result in the browser was disappointing and ran quite slowly in IE7. This could be my fault, not GWT's.
True RIA technology needs to be VM-based such as Adobe Flex, Microsoft's Silverlight, or JavaFX (if Sun is able to catch up at all). Attempting to improve user experience and attain "rich client" functionality without taking out the old trash beforehand will result in nothing but wasted money and an endless battle against the tide of browser updates. Which Ajax platform/framework/toolkit/toy of the month will take the lead next?
Meanwhile Flex and Silverlight continue to mature, without having to worry about applications malfunctioning (or having major JS engine performance problems as I've seen before) every time a new browser or browser version comes along, breaking any number of the technologies an Ajax "RIA" depends on to function.
googleFAIL indeed!
I think the point of the original post was to warn people of the dangers of over-engineering 'trivial' AJAX-like functionality. YAGNI. YUI, jQuery and Prototype will do that job just fine. JavaScript IS a good language.
When things get more complicated and you start to need test coverage and layers of abstraction, I'd argue GWT is a great choice. Enhancements in GWT 2.0 address some of my concerns:
- you can now 'debug' within Safari, Firefox or Chrome
- code splitting means the whole generated JS codebase doesn't have to be downloaded when applications start
I still don't see IE in that list for debugging. IE is not going away, especially not in business environments. So GWT "developers" still need to test more than once because they can't develop using IE. Sounds like fun. Compare this to VM-based RIA development: ONE 'platform' to test on. Working? Done.
Code splitting (modules) has been in Flex for ages. Debugging works just like a Java debugger, and again, has been around for ages. GWT is clearly behind the times and has a lot of catching up to do. It's not ready for the enterprise application environment. "Google blessing" doesn't change a thing unless you always drink the Google kool aid.
Many of the problems with GWT in the post above simply do not exist once you take out the TRASH technologies and use something with a stronger foundation. GWT/AJAX has the foundation of dependency on multiple and ever-changing browser vendors, poor/varied JS implementations, "standards" which aren't standard, constant 'browser warfare', and piss poor understanding of what the term AJAX actually means. That's a CRAP foundation to work with, why bother? WHY? Because 1 million people already know (or think they know) Java? (Speaking of GWT specifically here of course.) That's a terrible reason...
GWT doesn't create web clients. It creates *scripts* which get sent over to a (lousy) web client which interprets the scripts, allowing it to mimic the behavior of a native compiled desktop application -- a cheap imitation of the real thing. VM-based RIAs are true, compiled applications, a client running inside a client (browser) with a single point of failure instead of a million. Still not ideal, but a hell of a lot better.
Just because something can be used with great success doesn't mean it's ideal. If you're a Java dev, learn Adobe Flex. If you're a .NET dev, learn Silverlight. Or switch if you prefer. For god's sake, people need to cast this 90's "technology" back down the pit of hell from which it came.
NB: You've clearly not worked with Flex in anger if you believe it runs consistently across Flash Players and browsers.
The JavaScript standard is set forth by ECMA, whereas the DOM API is set forth by the w3c. The problem arises from the fact that neither of these two standards committees have ever met together to resolve issues that have existed since their conception.
Anyway HTML5 won't be fully implemented until 2025 from what I've read, so prepare for change. GWT isn't mature enough, AJAX itself is an inefficient, unreliable HACK which users are already starting to learn about--because it breaks so often. Large projects implemented using "AJAX" have failed miserably and wasted heaps of money. AJAX "(DHTML programmers)" are fighting an IT Vietnam. How it will end, no one knows, but a high cost is for certain. Good luck getting all these browser vendors to cooperate. =)
JJ - Please don't get technical with irrelevant points trying to make ad hominum attacks. I bundle all this CRAP together for simplicity, because quite frankly there's too damn much "stuff" needed to get it all to work. Of course I've used crappy DOM JS rubbish (why would I hate it if I hadn't?) and couldn't get away from it fast enough. What a nightmare! And I was also talking about the JS engine implementation, those turd-slow interpreters that continue the trend in IT to wastefully throw away efficiency "just because the computer can handle it".
If we're going to throw away performance with a slow, crap interpreted language, why even bother to innovate in hardware?
And the problem is worse than you let on, esp once you consider the conflicting interests of browser vendors. It's not just going to go away once two committees decide to meet...
I get it though. I understand your frustration and where you're coming from. We need new technologies that you can reliably build upon that are efficient and scalable. However, if you just want to anonymously rant and cry and bitch, it doesn't really deserve much of a response. Also, my name is not JJ so you can screw off.
It's good enough if you understand my frustration with legacy web technologies. We need new technologies that have as few dependencies on old, slow, unreliable legacy technologies as possible. VMs running in browsers aren't perfect but it's a step in a *different* direction for a change, instead of creating all kinds of quick fix "wrappers" and band-aids on top of one another.
Flex and Silverlight apps can even be converted to offline (outside of browser!) applications with little effort. AJAX/DHTML (an old miserable failure which AJAX is fundamentally reliant on to mimic RIA behavior) just can't do that.
Anyway let's face it: AJAX is a buzzword that most managers (and many technical people) don't even understand which has taken on a much greater meaning than what it originally meant. It should be banished from the IT dictionary forever.
As for the multiple targets and dependencies, I look at it as a C/C++ programmer might: try to use the STL for as much as possible, but sometimes you're might get stuck using something that's system dependent. Granted there are libraries that can abstract most of these problems away in C/C++, but the same things exist in JavaScript.
I tried a GWT for a app prototype a few weeks ago and was impressed. The default skin is a little clunky, but after looking at Google Wave and the new AdWords UI I'm satisfied that you can make the UI look really snazzy with a bit of effort.