When should you choose Google's GWT for your web app?

Up until about ten months ago, very few people would have considered javascript as a language in which one could build significant portions of the UI of an enterprise application. If, say, I needed to display a table of information with support for sorting and filtering, I would have been far more likely to do this processing on the server than to write it in javascript - simply because clean, maintainable and testable javascript code is not very easy to write - in contrast to something in say Java, C# or Ruby.

I guess it's pretty obvious where I'm coming from. I'm talking about the classic enterprise application where the focus is developing a robust code base with excellent test coverage which allows for easy maintenance and where the language of choice has good tool support so refactoring is joy for all concerned. These constraints pretty much eliminated javascript. Why is this so?
  • Javascript is a dynamic language. This requires that the developers be more disciplined.
  • Javascript (and other dynamic language) tool support has improved dramatically over the last couple of years, but still lags far behind Java and C# (with ReSharper installed, that is ;-))
  • Unit testing, while it exists, isn't very convenient.
  • This is a bit of a repetition but whatever; good Object Oriented Programming is very hard to do in javascript. And while you can do some pretty powerful stuff with blocks and closures, it takes a certain kind of developer to do a good job of it.
  • Cross browser compatibility. This is a complete nightmare. Of course I'll be the first to admit that on most enterprise projects there is just one target browser.

Bottom line - the life saving test-code-refactor cycle is far more difficult to implement when coding in javascript.

Once GWT comes into the picture, the scenario changes dramatically. GWT allows you to code in Java and compiles all that code into Javascript. What's more, the DOM element wrappers that GWT provides mimic Java Swing. As far you're concerned you are now in Swing territory with all it's tried and tested approaches and patterns. GWT also provides it's own implementation of JUnit which look and feels much the same as it's parent (no setUp(), but you can't have everything, what?) Most of the overheads of working with javascript for UI are removed (and yes, a few are added, what with Java not being dynamic :-))
You can now bring the awesome power of IntelliJ or Eclipse to bear on the problem. You can write all the unit tests you want. You're no longer worrying about that annoying javascript filterable table which five different developers have worked on and the customer really likes but which is now brittle and utterly unreadable.
You've now got a neatly separated domain model, presentation model, controller and view.
And it's all unit tested.
And you can refactor all you want.
And async calls/AJAX become utterly trivial.
And it's browser compatible.
No more muttering about having to manage with simple text renames instead of Alt+Enter/Ctrl+1. No more muddling around with explicit XMLHttp or JSON calls. The latter are now abstracted to simple RPC style method calls.

Of course, nothing is perfect. First, you need to choose between GWT layouts and CSS. Second, GWT apps are single page apps with all changes handled via DOM manipulations. If you're developing a site where users are likely to just drop by to view a single page for a short span of time (IMDB, Amazon - you get the picture...), then it doesn't make sense to dump 200KB of javascript on them - which is pretty average for a sample GWT application. The biggest danger is of course the temptation of trying to develop a full fledged thick client in the browser. Javascript executes pretty slowly compared to thick client UI written in managed languages - and this remains true even with the dramatic improvements in performance we see in Firefox 2.0 and IE7. Just try creating a simple application supporting the kind of complex drag-drop we see in many thick clients. Performance starts to degrade rapidly and soon the app practically freezes in the browser. The pitfalls are many and it is very important to keep in mind that GWT only offers the convenience of developing with a thick client paradigm and that your code is ultimately interpreted javascript which is going to be doing plenty of DOM manipulation. There are dozens of such nits one can pick - 'nuff said.

To summarize - thanks to GWT, we are now in a position to develop complex, rich, AJAX web-applications considerably faster and more reliably than we could using hand-coded javascript. The code base is more robust, easier to maintain and enjoys much better tool support. There will probably be some loss of performance, but one of the goals of the GWT team is to make the GWT compiler be to javascript what modern C/C++ compilers are to assembly. You just assume that most of the time the compiler can optimize far better than you can. GWT also costs you nothing and is completely OSS under an Apache licence and is being developed by a crack team of Google coders. It's just as important to remember what GWT isn't. GWT isn't a javascript library - it's a compiler. GWT also isn't a full stack solution - for that you'll have to whip up your own (I've had good experiences with Hibernate and XStream) or you can look at something like Spring.

Update: 2007-06-07
There were several thoughts which came out of this, one of them being that the whole model of web development is pretty messed up for certain kinds of applications. I've written a post explaining what I mean by this and why we should have our business models on the browser in javascript and use AJAX only to keep them synced with the server. You can find it here.

You may also want to read: The difference between a web application and a website
You may also want to read: Bringing business logic to the browser, or why you should develop in JavaScript
You may also want to read: JavaScript on Rails is here, and it promises to be as good as Ruby on Rails!

16 comments:

Eelco Hillenius said...

But who actually codes javascript for Ajax manually anyway (not that it's that difficult btw)? There's a zillion of libraries for it, like Dojo and many frameworks, like Wicket and Echo, have 'native' support for it.

Imho, GWT works for Ajax-only sites with a domain model that isn't too crazy. If you have a complex, database intensive domain model, using a framework like Wicket is easier and by default more efficient (because of locality, though if you optimize properly, which probably results in a maintainability penalty, GWT is hard to beat). Also, whether using a layout manager works for you depends on your taste and what your team looks like.

Anonymous said...

It is good that GWT itegrates so well with Java. How about other languages? I am usually on the fence about such itegration of javascript with a server-side language. I feel comfortable coding them separately. How about YUI library? It has very good maintainability and documentation and also a successful application in the form of Yahoo beta.

Rashmi said...

Good to hear about GWT. It will be a relief to most of the web designers currently using Javascript (and breaking their heads over it), since it’s a lot easier to code in Java. Also, handling the static nature of Java wouldn’t be as difficult. Above all we can now reuse parts of code as they are written in Java and do away with modular programming:)

Ved Prakash Jha said...

GWT is a gift for those who are not in depth with JavaScript. All you have to do is: write your codes in Java and your GWT compiler will translate the working Java application into equivalent JavaScript.So why to screw up your head in writing JavaScript.
Unit testing in JavaScript is not easy, at least not convenient.So, better to go for dynamic web contents with GWT.

fsilber said...

I see two advantages of the GWK approach:

You can code the logic of business rules once to enforce them on both the client and the server tiers.

As your design evolves, you can move business logic from client to server or vice-versa. Good design is an iterative process; it is naive to imagine that you can get it just right the first time. If the tiers are written in different languages, refactoring the architecture requires throwing away and re-implementing good code.

Unknown said...

I have been using GWT for a while. My opinion is that for small applications GWT is OK but if you have a large domain model it is hard to integrate the front end & back end well. I have the the model part of my application represented by EJB3 session/entity beans & have found there is a lot of massaging(like copying entity objects from EJB compatible(i.e. Serializable) to GWT compatible classes(i.e IsSerializable)) which needs to be done at GWT service layer before you can show meaningful data in the front end.
Databinding for complex UI components to the back end object is not straightforward. Validation is another pain. All this results in a large codebase which can be avoided if you start with a full stack frameworks like RIFE or Seam. I am seriously looking at Seam to see how much less work I'd have to do for a similar application.

Unknown said...

Eelco,
You're right in saying that GWT makes sense only for AJAX sites. That's it's forte. But it also kicks ass for complex presentation models (believe me, I'm doing this every day at work - MVC is a breeze :-)). Tie it into Spring and those database problems are no longer problems. The domain model on the GWT (client) side should have minimal complexity - they should little more than dumb DTOs, possibly with validation. All the business logic should be on your server - if you're seeing that stuff in your GWT code and tests then it's definitely a code smell.

GWT is a essentially compiler while Dojo et al. are frameworks - comparing them is a bit of an apples and oranges thing. While they do try to achieve the same goal, the paths taken are completely different.

fsilber,
I couldn't agree more.

aejaz,
I'm afraid I've never worked with EJB's - Hibernate and Xstream have been the weapons of choice in ThoughtWorks - but my colleagues tell me that Spring goes pretty well with GWT. I don't see a way to avoid the Serialiazable to IsSerializable conversion layer, though. Thanks for the tips on Seam and RIFE - I'll be sure to check them out.

Unknown said...

PS: I totally agree with that full-stack comment by aejaz. If someone could just replace Rails' ActionView with GWT...

Eelco Hillenius said...

I agree with the apples and oranges argument, though the same applies for comparing frameworks like GWT, Wicket and JSF. In the end you want to create web applications with any of them :)

I think it is a matter of getting comfortable with a framework as well. Whatever framework you use, you have got to know the gotchas and optimizations etc. Whether GWT is a better choice than, say, Wicket or Echo, depends more on style and preferences than them being inherently better than the other. That said, I believe, JSF is full of wrong choices and the 'web mvc' frameworks like Struts and SpringMVC weren't very helpful in the first place.

Eelco Hillenius said...

The Rife framework and everything around it is very well done. Big kudos to Geert on that. However I disagree with it's continuations-centric philosophy, which basically forces you into a procedural programming model. I believe a (stateful) widget based approach is more suitable for developing user interfaces (which Geert thinks is too heavyweight btw).

James said...

I would be interested in whether you have evaluated thinwire, which removes the need to javascript compile...

Thanks

Anonymous said...

GWT is a gift for those who are not in depth with JavaScript. All you have to do is: write your codes in Java and your GWT compiler will translate the working Java application into equivalent JavaScript.So why to screw up your head in writing JavaScript.

This attitude is what really fuels GWT adoption: people are, by nature, lazy and do not want to make an effort to understand that different platforms do require different skillsets, knowledge of different APIs and languages. Really, why screw your head trying to understand anything at all.

Juergen.Beckmerhagen said...

Namaste Sidu, Thanks for sharing your thoughts on GWT. I happened to find your blog when searching for "GWT JCR". In your profile you refer to a project using both components, I am very interested in your "end2end" experience and in the tools you use to glue the two frameworks together.

Thanks.

Unknown said...

Hi Juergen,
The overall experience was quite good.
We provided access to Jackrabbit through a layer which exposed functions like getNode() and search() through Axis webservices hosted in Tomcat and which used XStream for serialization.
These services were consumed by another layer which in turn exposed more business domain specific web services. We had a requirement that there should be 'raw' access to the repository available for other applications to use, hence the two layers.
The GWT server was one of the consumers of these business services and through the GWT server, the GWT client had access.
Authentication and authorization is one area in which we had a fair amount of trouble. Jackrabbit has quite a way to go before it can support users and roles for node level access.
I know this is a very superficial explanation so let me know what areas you want clarified and I'd be glad to go into greater depth :-)

Kingsley Joseph said...

Server side (generative) approaches are great from a programmer productivity perspective, but they are pretty useless when doing client side mashups, which is where I see a lot of value in AJAX.

Plus, most web designers I know find Javascript easier to deal with than Java. Procedural programming isn't pretty, but it provides an easier to understand segway into programming than something like Java.

Unknown said...

Take a look at the Activ Mobs site - it's pure client side GWT compiled javascript with no server interactions. The server on which it's hosted (at the time of writing) doesn't even support Java. GWT javascript isn't generated at runtime by a server - it's a one time thing when you do a compile.

Developing procedurally in javascript is ok when all you're doing is validations or the occasional effect. But for something like, say, netvibes.com, you need a really good developer. And this is not because the language is weak - frankly as a language I prefer javascript to java for more reasons than I'd care to go into - but what is difficult is doing it in a disciplined manner. Developing large applications which have business logic is easier with GWT because it's easier to be disciplined as a developer when you have the support of all those tools like IntelliJ and JUnit.