Wednesday, May 24, 2006

Google Web Toolkit: The Next Big Hype

Let me say something about Google (I don't put links here because everyone knows).

I love Google Search Engine.
I love Google Mail.
I love Google Chat.
I think all those people at Google are great in creating advanced (and cool) applications.

This is what I think, and this is what a lot of people also think.

Now, too bad, thanks to this kind of leadership, everything Google produces gets acclaimed by the majority like the next big thing, without a small crumb of criticism.

This is the case of Google Web Toolkit (GWT).

GWT is the new born at Google: a framework for developing Ajax applications in Java.
Let me quote its web site:

Google Web Toolkit - Build AJAX apps in the Java language

Google Web Toolkit (GWT) is a Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don't speak browser quirks as a second language. Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatabilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.
GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.

What is Google Web Toolkit?

Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translates your Java application to browser-compliant JavaScript and HTML.
Here's the GWT development cycle:

  1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.

  2. Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.

  3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.

GWT drove people literally crazy.
But before going to GWT web site and start playing with the new, acclaimed, next big thing, because everyone will do and you cannot be cut off, please think ...

Developers spend 90% of their time in developing and maintaining business components.
It is not true that you, as a developer, spend 90% of your time working around subtle incompatabilities between web browsers and platforms.
Developers should spend (and actually do) most of their time in developing the application domain model and all the business logic and components.
With GWT, developers will spend a lot of time in developing also the whole presentation layer. This is because ...

GWT makes Separation of Concerns absolutely unfeasible.
If Separation of Concerns is applied, developers can focus on business logic and only limited presentation logic, because talented web designers will do all the hard job with HTML and alike.
With GWT, developers must write every single web page like it was a SWING window, and if you think it will not be an hard job because you are a very talented Java developers, please consider ...

Writing SWING-like interfaces is a lot more difficult than writing HTML-like interfaces.
If you have ever developed a Java SWING application, you know what I'm talking about.
Moreover, consider a web application with dozens and dozens of web pages ... you'll end up with dozens and dozens of Java classes whose only job is constructing a web page.
Did I say that those Java classes construct your web pages?
I've been wrong: they are actually compiled into HTML+Javascript code, and it is that HTML+Javascript which makes up your web page.
Yes, because ...

GWT automatically generates HTML and Javascript code from your Java classes.
Just one thing: if the GWT compiler has one or more bugs, generating so wrong code, how difficult would be to debug and detect those bugs in the automatically generated JavaScript code?

Now, I'm not condemning GWT: it can be more than good for little to medium ui-centric web applications where developers can focus on presentation logic.
This is obviously my opinion: and I'm inviting you to be judgemental and have your opinion without taking as gold all Google gives to you.


Michael Beeson said...

I could not agree more about your assessment of huge amount of additional time a developer must take to construct an entire GWT page/module because GWT lacks separation between design and code.

I'd love to see GWT add TIBCO GI's ability to completely separate code from data! That would make it golden in my eyes.

nocturnal said...

I have a like/dislike kind of feeling with GWT. At one end HTML, JS and CSS you can do anything( plus there are lot of js lib as well ) but on the other hand I don't want to get frustrated by browser incompatibility and not able to effectively reuse HTML, JS or CSS.

Darren Siegel said...

The separation of concerns issue is not something that the GWT itself inherently addresses. At some point, you the developer have to build a higher-level architecture to separate your business logic and presentation layer. For instance, implementing a client-side MVC architecture in a GWT application (similar to how one would responsibly build a Swing application) addresses the separation of concerns issue, and once in place makes it easy to develop large, robust applications.

Chris said...

I agree partly. The last scenario would be a true nightmare: suppose the GWT compiler would indeed generate invalid js...

On the other end: Try comparing writing GWT (java) code to building JSP's, using all sorts of constructs to get the values from your webpage to the controller. I have the experience that GWT is extremely fast in building complex applications and that the old request/response paradigm is constantly in the way when you want to do it properly (without overloading the session with all sorts of bean).

Also, JSP gives some fine opportunities to create spaghetti of an architecture when using all sorts of logic tags, sql tags (agreed, ancient history), logic tags and all sorts of javascript stuff.