7

After a long debate between many RIA/Ajax framework, we settled on GWT. When reading about it, this framework seams to be doing everything well and easy. But like any technologies, there is always down side and we we learn them the hard-way.

What are the main downfalls or problems when using Google Web Toolkit (GWT)?

(eg: Back/Forward Button support, Slow Response time, Layout Positioning, JavaScrit bugs, etc)

So far, I got the following from the response:

  • Lots of code for simple UI
  • Slow compilation

Thank you

Aerosteak
  • 987
  • 1
  • 11
  • 21

5 Answers5

14

I have been using GWT for nearly 2 years. Although I could be called a fanatic about GWT, there are some issues that one should know ...

  1. As others have said, JavaScript compilation is slow. My application requires nearly 4 minutes for core i7 CPU, 8 GB memory. Total size of generated JavaScript is about 5 MB. But thanks to development mode, compilation to JavaScript is not needed frequently.

  2. GWT RPC is extremely slow in development mode. It is 100 times slower than hosted mode. It was quite a big problem for us. We did consider giving up GWT just because of this reason. the reason for this sluggish performance of GWT RPC in dev-mode is serialization. Serialization of types other than String is unbelievably slow in dev mode. We did implement our custom serialization, it is nearly 30 times faster than GWT built-in serialization.

  3. Claims that writing GWT application requires only knowledge of Java is just an illusion. You should have solid information about CSS and DOM. If you don't, you will spend too much time debugging your user interface.

  4. You should consider that you can only use a small subset of the JDK to implement GWT applications. Reflection is not available; you should use third party libraries, such as GWT ENT, or write your own generator for reflection.

  5. Another caveat that one should consider is the size of generated JavaScript by the GWT compiler. Most of the GWT applications consist of a single web page, as opposed to multi-paged traditional web applications. Therefore, loading of the application requires significant time. Although it could be mitigated by using a multi-module approach and code splitting, using these techniques is not always straightforward.

  6. All calls to the server are asynchronous. You should adapt yourself to writing asynchronous code. And the downside of asynchronous code is it is more complex and less readable than the equivalent synchronous code.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
Gursel Koca
  • 20,940
  • 2
  • 24
  • 34
8

Here are my observations on the downfalls:

  • steep learning curve if one wants to use GWT effectively in large applications, due to enormous number of high level conventions associated with GWT.
  • asynchronous requests require different mode of thinking when it comes to designing the whole application
  • long compilation time, it does not affect Development Mode as much as full builds (all the permutations for all the browsers and languages are compiled which can take hours for big projects). JRebel can reduce requirement of Development Mode restarts a bit.
  • problems with unit testing - GWTTestCase starts so long that it is unusable for unit testing. However thanks to GWTTestSuite it can work well for integration testing. Thanks to keeping clean MVP it is also possible to unit test Presenter logic by mocking Displays (see my answer).
  • it requires some experience to decide whether specific logic should be implemented client side (compiled to JS) or server side.
  • and of course there are some small bugs, especially in new features like Editors and RequestFactory. They are usually resolved quickly with new releases, however it could be annoying when you encounter some GWT issue. Anyway the last downfall applies to any Java framework I have been using so far. ;)
  • lack of reflection on client side, which could be resolved with Deffered Binding and Generators, but it is another convention to learn.

If I was to start new GWT project I would:

  • add dependency on Google GIN library (unfortunately it does not work with GWT 2.2 at the moment, but should be compatible soon).
  • design general layout with LayoutPanels
  • structure application "flow" according to concept of Places and Activities.
  • put all the Places into separate GWT module (common navigation references)
  • put each Activity in own GWT module (it could help in application code splitting later on)
  • treat Activity as glue code which has View and Presenter providers injected with GIN
  • design data entities to be compatible with RequestFactory
  • create all data editors with UiBinder, MVP and Editors framework in mind
  • use RequestFactory in Presenters, as well as in Activities (to fetch initial data to be shown).
  • inject with GIN every identified common component like standard date format, etc.

The spring roo tool can generate a lot of GWT based code for standard application elements.

Community
  • 1
  • 1
morisil
  • 1,345
  • 8
  • 19
2

I did a prototype app with GWT some time ago, and I found that the time it takes to compile the java to javascript took a very long time. Even more the time to compile increased noteably with each line of code we wrote.

I just wasn't happy with the code, compile test phase getting slower and slower through time.

Another question on SO about the compiler: How do I speed up the gwt compiler?

Community
  • 1
  • 1
Nathan Feger
  • 19,122
  • 11
  • 62
  • 71
  • 1
    You don't mention what version you were using. There have been steady improvements in compile time, including the quick-and-dirty draft compile. Plus, if you're using development mode properly then you won't have to do compiles very often at all. – Isaac Truett Feb 19 '11 at 15:39
  • In my experience, it's *very* rarely necessary to compile to JavaScript. Development mode can be used with most browsers on most OS, and its behavior is very close (practically 100%) to the final, compiled result (except for performance tests). Also, it's usually not necessary to re-start the server. A browser refresh (for client side changes), or a [server reload](http://stackoverflow.com/questions/4557342/gwt-force-update-on-server-during-development-mode/4562176#4562176) is almost always enough. – Chris Lercher Feb 19 '11 at 17:30
  • Plus, you can even improve the development cycle some more by attaching a Java Debugger, which works even on client side code. (As always with debuggers, this technique obviously doesn't work for all kinds of code changes). – Chris Lercher Feb 19 '11 at 17:36
2

I think that main disadvantage is that GWT often requires to write lots of code, to acomplish simple tasks (but it's getting better and better with each release). On the other hand it's brilliant when it comes to developing complex, custom widget where it shines. During couple of projects GWT has proved to be very good in terms of performance and there hasn't been many bugs - it's very good in terms of cross-browser support imo.

jgrabowski
  • 1,521
  • 12
  • 7
0

as a fan of nativity... I prefer JQuery rather than GWT, because, it's easy to animate or accomplish complecated tasks without writing many classes..

Bellash
  • 7,560
  • 6
  • 53
  • 86