38

I've recently become intrigued with Google Web Toolkit and have started playing with it on some personal projects. I've noticed though that it doesn't seem to be very popular. For example, two major freelancing job boards (www.elance.com and www.odesk.com) list no jobs for GWT and the list of projects using it on Google's official site is pretty slim http://code.google.com/webtoolkit/app_gallery.html (compare to Django projects for example http://www.djangosites.org/).

This seems odd to me as GWT has been around since 2006 and is supported by the Google brand name. It also neatly solves the problem of creating cross-browser completely dynamic websites that I haven't seen possible with any other tool. So, why the lack of acceptance?

53

I did about 6 months of GWT last year. I can't see me ever choosing to use it again. There are several reasons for this:

Firstly, the advantages of GWT (as I see it) are:

  • Type checking. Mistyping a member name or the like will give you a compiler error;
  • Use of the same value objects right through your application (more on this in a second);
  • Debugging client side code is actually good in the sense that in hosted mode you can change a Java file for some GUI code, save it and it'll be reflected on your browser. Change the interface to the serverside code however and you'll basically have to redeploy;
  • No need to learn another language (Javascript);
  • Google's name behind it counts for something.

The point about value objects is worth further explanation. If you use JPA, for example, you end up with some pretty rigid persistence objects. This can actually be a good thing. Now in a traditional Web application (where the objects are in the same VM) you can happily use these in your Spring MVC or Struts 2 (or whatever) controllers/actions. Not a problem. You can't really use these in GWT however because that would send an awful lot more information than you want (eg all the one-to-many collections) to the client.

This being Java where people like layers, the counter-argument to this is that you should be doing transformation of your data objects to presentation objects anyway so this is no different. My personal stance is that layering should add value and shouldn't be done just for the sake of doing it (which I think happens a lot now).

Google will release GWT 2.0 in late 2009 and it featured heavily in the 2009 Google I/O conference, particularly in relation to Google Wave, which is a huge, ambitious project that firmly throws Google's weight behind HTMl5 and Javascript.

This is probably the biggest, most high-profile use of GWT to date and does a lot to change my view that Google just didn't seem to be committed to GWT. This may help the otherwise low uptake of GWT but it still has a long way to go to catch up to the much more mature Javascript frameworks out there.

Now to the disadvantages of GWT:

  • Javascript is, in a lot of ways, more fit to the task of client-side scripting than cross-compiled Java. That's not surprising. Java is a general purpose programming language. Some might argue Javascript is too but it's not. It's designed to client-side browser-based scripting;
  • There are numerous mature Javascript UI frameworks;
  • Frameworks like jQuery, Dojo and Prototype give you a far more powerful yet more succinct syntax which is again more fit to the task;
  • Compiling GWT code takes a lot of time. It can take 1-2 minutes for even a few screens. Now when debugging you don't need to do that with it in hosted mode but if you change the server, you do. Compare this to, say, jQuery + PHP, which is pretty much always immediate. I believe one of the big advantages of something like PHP is that feedback is immediate. Save a file, click reload, see if it worked. This doesn't break your flow (as per the Joel Test). Jeff made similar points in A Scripter At Heart. So wasting 1-2 minutes on a compile is a big problem (imho);
  • There's really no good GWT frameworks or widget libraries. Sure you can use vanilla GWT but it's lacking in widgets (even with the incubator widgets). It is getting better though. Ext-GWT for example is (imho) a disaster written by one guy trying to extract a living from it (so no community developme
18

What I really like about GWT is that even me, who focuses more on desktop applications or server side stuff and doesn't do web programming (Javascript/HTML/CSS) very often, was able to write non-trivial browser-based application using GWT. Truth is that it sucked visually (it wasn't intended for public usage). But it was supposed to run in browser, to provide certain functionality while talking to existing server, and GWT was great tool for this.

Good points about GWT:

  • you work in statically-typed language, which catches lot of errors early. This is even better in GWT 1.5 with support for generics, enums, etc.
  • you can reuse some of your existing java code
  • Swing-like programming, with events, listeners, etc.
  • GWT supports quite a lot from Java standard libraries
  • Developement of quick-and-dirty browser-based app is really fast
  • Javascript generator produces highly-optimized code
  • GWT handles some cross-browser incompatibilities for you

What I don't like

  • compilation to final Javascript is slow
  • some browser limitations were observed only in non-hosted mode
  • generated Javascript is a mess
  • getting layout right was not so simple
  • for advanced widgets you need 3rd party module (but that's always the case, isn't it?)

Summary: I would happily choose GWT again for some kind of applications, for example Gmail-like mail client ;-)

10

Just need to chime in here to say that GWT is most certainly not a simple 20% project. GWT has a team of approximately 10-15 people working on it full time. See the picture here: http://googlewebtoolkit.blogspot.com/2007/03/google-atlanta-open-house-read-were.html

As far as eating their own dogfood goes, I don't think you can expect them to rewrite existing applications immediately. Rather I'd look to see what they do new development with. In that case: google.com/health is a good example of a large and important new Google app that uses GWT.

8

I use GWT extensively and I'm happy with my choice. There are many pros and cons but here are my favourites...

Pros

  • Compile time checking
  • Java Debugger (much easier than javascript, even with Firebug)
  • Good quality wysiwyg editors
  • Cross browser translation is excellent
  • Excellent RPC mechanism, you can forget about most RPC details

Cons

  • No good way to achieve MVC separation so that a non-Java designer can build the UI layer
  • Some bugs in third party libraries for cross browser code
  • Widgets used by Google not all in GWT

It seems that Google is continuing support for GWT (probably because they use it themselves) so I'm happy to continue to use it. The lack of MVC separation is the biggest disadvantage but that's not a biggie for me because I keep my ui as simple as possible. For the rest, I save lots of time by forgetting about cross browser code and javascript loose typing errors.

7

Personally, I have an instinctive distrust of code generation.

7

I have extensive experience with GWT (started with version 1.3 then jumped to 1.5), and to me, GWT is probably the greatest SDK to come out since the JDK itself.

Yes, it does have some shortcomings, as anything else. But for the development of web applications with a Java back-end, no other alternative comes close, in my opinion. Most of all, because not having to divide the codebase between two different languages is a big boost to productivity (not to mention that tools for JavaScript are much more limited), and because UI code really belongs in the client (ie, why overload the server with the responsibility of running UI code when there is a powerful runtime platform - the modern Web browser - in the client machine?).

Compile time from Java to JavaScript is too long, but developers should be using hosted mode most of the time (and out-of-process host mode, coming in GWT 2.0, will improve this considerably).

Another significant difficulty with GWT is bridging the client-server divide. Coding specific DTO classes is no good, but it can be avoided. Unfortunatelly, no one yet developed an OpenSource solution to that. I did create such a solution for a closed-source project, using a single RemoteService implementation on the server, which would populate beans with data in a generic DTO object, and dispatch the call to an appropriate business method, as specified through Java 5 annotations in the RemoteService interface. It worked really well, and I am thinking of implementing it again, this time as OpenSource.

I think we will only see GWT grow in popularity. The only real alternatives would be Adobe Flex, Silverlight, and JavaFX. For a large business web application, coding in JavaScript is not an option, and running UI logic in the server is obsolete.

4

I think the relative cost of java developers compared to other popular web languages may also be a factor

4

I don't know why GWT is not very popular. I used it and all my javascript was wrapped by java classes, it dramatically decreases debugging time.

Maybe there is not enough blogger/writer/books on this technology.

Microsoft have project Volta (it's in beta I think) has well, which is the equivalent of GWT on .NET plateform, but nobody talk about it.

3

I used GWT for over a year before 1.5 came out. I loved it at first but I eventually decided that the huge amount of time that it took to go from java to javascript was too much of a productivity killer.

If a really complex GWT app is all finished then debugging it is undoubtedly much easier than debugging really complex javascript. But all together GWT just added too much overhead to the development process.

If I write code in javascript and then modify a little bit I can just refresh the page and it's live again. Doing the same with GWT results in 90 seconds of wait time until it's live. That can be a huge deal when I'm making a lot of changes.

These days I generally write everything in javascript but use DWR to push as much of the code to the server side as possible.

As much as I love the concept, I can't see myself ever using GWT again unless they get the code generation time down to less than 10 seconds.

2

I see some answers with the pros and cons of GWT. Any framework has pros and cons. There is no such a thing as "best framework". You must decide which framework is best for you depending of your context.

There are certainly popular framework. But even the most popular framework may not be the best choice for you!

That said, there are some factors that limit the adoption of GWT. Thus resulting in less visibility of GWT, fewer books and fewer libraries for it. It's a chicken and egg problem, especially compared to the more popular framework.

Personally, after developing in GWT for almost 3 years, I think the most limiting factor is that there is no good GUI designer (1). Considering that a very large part of GWT is the GUI, no wonder it has not been widely adopted. If someone could build a "Matisse" like designer for GWT, then it would be much more easy and quick to develop rich internet application. I found it quite tedious to build even the most simple layout.

(1) There is only one that I know of: GWT designer. It only works with GWT vanilla widgets though.

2

Hi,

I dont intend to publish a self-plug on SOF but my thoughts on choosing GWT for most of our applications can be found on my blog (Google - sushrut bidwai gwt). In a nutshell, GWT is as good as most of the frameworks out there. The best thing I liked is, you are not tied to Java on the backend. You can use any language, python/ruby/java, heck even perl, as long as you implement JSON communication between them.

Where do we use GWT?

We found GWT very usable and awesome actually for implementing enterprise applications with complex UI side requirements like drag and drop etc. We also implemented few UI side design patterns to handle inter widget communication.

Why its not as popular? Well I have not followed market very closely over last 10 years, but most programmers specially, developing web applications were using PHP/.Net already. Not a lot of Web applications (not browser based, but web) were written in Java. So moving from PHP/.Net to Java is not happening IMO.

Hope this helps.

1

It's probably either due to the recent boom in really good JavaScript/AJAX frameworks or because a lot of Java developers are moving on to newer languages.

1

Contact Office is build entirely on GWT and there is an excellent presentation by the CTO on why the made the GWT bet and how it worked out:

ContactOffice at Google Dev Day

0

I guess nobody want to convert vast number of applications from struts/jsf to GWT.

0

Hopefully now that GWT2 has been release this will change. A lot the missing feature that people point to in GWT (pre version 2) are now there. Many of them have been they been there in trunk for a while (a year + in the case of oophm now renamed dev mode). People are reluctant to develop against trunk and has missed out on some youbute feature till now.

0

Personally, I'm glad not many are choosing to use GWT. In my opinion GWT is almost an unfair advantage, it's that good.

0

I find the java-javascript cross-compiler too "noticeable". By that I mean you have to think too much about how the cross compilation is going to happen. You must be aware of that Java features (some runtime exceptions, generics, some java libs etc) that won't be available to the cross-compiler. By the time you learn all of these tricks, you might as well learn to do things natively with javascript.

-1

This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT

Fundamental Advantage

GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.

Fundamental Disadvantage

The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?

This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?

Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.

Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.

Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.

But by not using it you are missing the object oriented programming from Web Pages. Quite bad. I have a solution for that as well. But for that you have to read my web page http://ercilla.webs.com