Why GWT is here to stay

I’ve been developing with plain JavaScript for several years now, long before the AJAX craze started (when my spell-checker posted a hidden iframe back to the server and such). Why would I be an advocate of GWT when I’ve written web-apps that include over 10’000 lines of JavaScript? Lets think of this a slightly different way: Why wouldn’t I be an advocate of GWT when I’ve had to maintain 10’000 lines of JavaScript?

Some of the common misconceptions about GWT:

  • GWT is for people who don’t want to or can’t code JavaScript
  • GWT is only there to hide browser differences (and there are plenty of JavaScript API’s that do this)
  • GWT produces bloated JavaScript files
  • GWT doesn’t let a graphic designer produce the User Interface
  • GWT takes away the raw power of JavaScript
  • GWT is a plain Java to JavaScript compiler

I see these complaints everywhere. Those who make them are mostly PHP developers, or people who have never worked on a commercial browser based system that requires large amounts of JavaScript.

At this point, let me say something about GWT that I don’t see explicitly said often enough:

GWT is a Web Application framework!

GWT’s space is not in putting an auto-completing text-input on an otherwise fairly static HTML page. There are plenty of JavaScript API’s that will do that for you. GWT is not “Swing for the browser” either! GWT is more like the Java Desktop Application Framework, or the Netbeans Platform. GWT is not about simply building a user-interface, it’s about reducing the load on your server.

A serious flaw in web frameworks like Struts or WebWork is the amount of data they store in the session. The unfortunate fact is that storing data in your session is very expensive for your server cluster. It’s fine running on a single machine; or if you have very intelligent load balancers, however: running on a larger cluster, or trying to handle tens-of-thousands of simultaneous users becomes really hard.

Why is the session expensive?

In Java you have wonderful Serialization of objects. References are correctly rebuilt when loading a serialized object and so on. Using an HttpSession in a clustered environment however, means that every object in the Session is re-written across the network at the end of every request. Why not just the objects that have changed? The answer is simple: how do you know which have changed?

Struts for example stores all of the Action objects in the Session. Thats potentially a lot of objects to store, and move around between servers. How does this relate to GWT though? In GWT you can place your “index” page behind a standard Filter or a <security> mapping in your Web XML to handle the login of your users, and have GWT work through a service style system, where your servers act in a stateless manor. This drastically reduces the load on your servers, since they no longer need to hold session data in memory or synchronize it with the other servers at the end of each request. In fact, the GWT application can cache the resulting data on the users browser instead of in the Session!

But what about my Graphic Designer?

When developing a desktop application, you generally have a user interface designer working with you (if you don’t, go hire one). Like I’ve already said: GWT is for building applications that happen to run inside a web browser. If you are building a web site, you should probably look at a different technology (though keep GWT in mind all the same). A user interface designer is often not a developer, and so can’t actually write the user interface.

The other side of this argument is: what is your web designer doing writing your HTML?!?!?! In my experience,the web designer produces an image (often in PhotoShop) of the look & feel for the site, and then provides you with the graphical elements you need as you write the HTML for the site. Having a web designer produce HTML is always a bad idea, no matter how much they know about it. If nothing else: HTML limits their creativity.

But I know plenty of JavaScript, why hide it behind Java?

A note to those with this argument:

  • Get off your high horse and get back to work

JavaScript is a very powerful language, GWT is not hiding it away behind Java. If you need to code JavaScript in your GWT application: use JSNI, thats what it’s there for. The problem with AJAX is not JavaScript, it’s the way it’s implemented across different browsers. You eventually wind up with loads of “if(browser == IE)” and such all the way through your JavaScript. I won’t even bother to mention the nightmare that is passing events in JavaScript. GWT neatly deals with all of that for you, without any browser checks in the produced code (well, there is one to decide which version of the application to load).


GWT does not cripple you by having you code Java, it empowers you to do more with less code. The amount of code produced is often smaller than the pure JavaScript API’s that hide browser differences. It’s also a lot easier to work with.

You spend more time working on your application logic and less time re-inventing the wheel.


5 Responses to “Why GWT is here to stay”

  1. Bruce Johnson Says:

    I don’t know know how I missed this great writeup until now, but I just wanted to reiterate how right you are in your characterization of GWT. We think of it as *leverage*, not as some sort of walled garden of abstraction. While it’s understandable for experts in “traditional” AJAX (i.e. handwritten JavaScript) to be a little antagonistic towards GWT when they first hear about it, it’s a shame if they don’t investigate GWT further, because such people would actually get the *most* benefit from GWT. Combining a deep knowledge of the DOM, CSS, and JavaScript itself with the performance and productivity leverage that GWT gives you is the best recipe for creating truly world-class web applications.

  2. Jason Says:

    Wow. Thanks for the comments Bruce! I totally agree that to truly be able to (in your words) leverage GWT’s power, you need to know your JavaScript, DOM and CSS. I feel the same way about Java and knowing what the resulting bytecode is, and what HotSpot is capable of optimizing, and how.

    I’m busy working on a little bit of code at the moment, to give to all those who are always asking “why can’t I use MessageDigest?” and “where is UUID?”, etc. 😉

  3. Paul Schwarz Says:

    Wow, you got a comment from Bruce Johnson! Well done, Jason – and I agree, this is a very clear and well written article.

    I come from similar stock, writing rich client apps with javascript code. In 2005 I decided to get up in front of my class and give a lecture on AJAX since I saw it as the next bit to add onto my existing interest in javascript. My professor was horrified and almost walked out but most people thought it was the coolest thing they’d ever seen.

    It was about a year after that that I discovered GWT while it was still a very young project and now I can’t live without it for large high quality software applications. I do spend a bit of time telling colleagues about it but I often can’t find the words so I stick to developing applications which is why I’m grateful that you’ve written this article.

  4. Why GWT… ? « jeremyp.info Says:

    […] Why GWT is here to stay qui date de décembre 2007. […]

  5. Manny Says:

    I simply could not go away your website prior to suggesting that I actually enjoyed the usual info a person supply to your visitors? Is gonna be again incessantly in order to investigate cross-check new posts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: