4 More GWT Anti-patterns

4 More GWT Anti-patterns

by Zack Grossbart on September 21, 2010

My view of GWT is changing. When I wrote 5 GWT Anti-Patterns I saw it as the framework controlling my entire application. Now it’s my glue.

GWT is a wonderful foundation holding together the different parts of your application. It can grow and expand to new technologies and uses we haven’t thought of yet, but it can also hold us back. You can get stuck in GWT and never find your way out.

Each of these four anti-patterns addresses different ways to write code you wish you hadn’t. The solutions are all about opening doors instead of closing them.


GWT RPC is the sexiest feature of the entire toolkit. Making AJAX simple lets you program for the web like it was a desktop. Don’t worry about remote communications or networks, GWT RPC takes care of that for you.

The problem

GWT RPC generates the network calls for you and automatically marshals Java objects between the browser and the server, but that ease of use comes at a cost.

It isn’t that easy. GWT RPC requires you to manage two interfaces plus the client-side calling code and a servlet to make it all work.

Error handling is hard. Network programming is the art of error handling. Networks are unpredictable and abstracting that away makes it much harder to respond well when something doesn’t go right.

You can’t tell what’s going on. Try debugging your GWT RPC through a network tool like Wireshark or HTTPFox. All the ease of debugging your Java by looking at the byte code.

It’s slow. GWT RPC adds a lot of overhead to the request, but that isn’t the worst part. When you think of remote procedure calls as free you make a lot of them. That’s the recipe for an application that loads in minutes instead of seconds.

The solution

Use REST. I’ve written patterns for using REST from GWT. There are also some good built-in features and third-party plugins to support it. REST looks daunting at first, but it isn’t that bad.

REST is everything GWT RPC isn’t: fast, easy to debug, and simple. It also does more.

REST forces you to build an API. GWT RPC makes everything look like the same program so you rarely create a solid API. With REST you have to. APIs make your code better even if nobody else ever calls them.

REST supports automated testing. Once you have a REST API you can test it without worrying about the client. I’ve written test suites in Ruby just to make sure I had good coverage.

REST decouples the client and server. Imagine shipping a new version of your GWT client without changing your server. You could fix bugs and not worry about destabilizing other parts of your code. You could even write a GWT client for a server written in a different language like we did when we created a multi-value auto-complete field with GWT and REST. That article has source code of a GWT application that calls to a Java servlet or PHP using REST.

2. Securing your GWT application

I sleep peacefully at night knowing my applications are secure. So do my customers.

GWT doesn’t solve the security problem for you so you might be tempted to put it all behind a firewall, password, or Spring framework and get perfect security. Perfect security isn’t perfect.

The problem

It’s easy to put your entire GWT application behind a secure framework. Require a login before you can even download the HTML. You feel happy knowing the bad guys can’t see your JavaScript, HTML, or CSS, but securing everything makes your application less secure.

The solution

In the end GWT is just a web page. People download, run it, and maybe view the source. Let them. Don’t secure any of the files that GWT generates and don’t put secure information in your source code.

Secure your data, not your code. It doesn’t matter if you’re using GWT RPC, REST, or anything else, you’re just exposing URLs with data. That’s the right place to put your security.

Create a single path, put all of your data behind it, and secure it with a servlet filter. You can make this path something like /data so your URLs look like /data/users or /data/roles. That simple path is easy to secure and easy to test.

You can even go a step further and move the code serving secure data into a separate WAR file. That avoids many accidental security problems.

Securing just your data makes your server easier to write and test. It also helps your browser code. Don’t make login a separate step in your application. Add a single point in your client for login and make it part of your GWT application.

3. Using only GWT

GWT is an insular environment. It separates you from JavaScript and can cut you off from a world of innovations and well tested software.

The problem

There are many frameworks that wrap existing JavaScript code. They work well, but they’re little more than a drop in the bucket. GWT is a great project, but it can’t keep up with the rest of the Internet.

The solution

Wrap existing third-party Javascript with GWT. For example, GWT doesn’t have a progress bar control and JQuery UI has a really nice one. Wrapping the JQuery UI progress bar is easy. Here’s all the code you need:

import com.google.gwt.user.client.ui.SimplePanel;

public class ProgressBar extends SimplePanel
    private int m_value = 0;

    public ProgressBar(String id)

    public void onAttach()
        addProgressBarJS(getElement().getId(), m_value);

    public int getValue()
        return m_value;

    public void setValue(int value)
        m_value = value;
        setValueJS(getElement().getId(), m_value);

    private static native void setValueJS(String id, int barValue) /*-{
        $wnd.$('#' + id).progressbar('destroy');
        $wnd.$('#' + id).progressbar({
            value: barValue

    private static native void addProgressBarJS(String id, int barValue) /*-{
        $wnd.$("#" + id).progressbar({
            value: barValue

That’s it. Add JQuery and JQuery UI to your GWT HTML page, include the JavaScript files in your WAR, and write 42 lines of code. Now you have access to the JQuery progress bar in GWT and you’ve added strong typing to the control.

Don’t like the JQuery progress bar? Wrap someone else’s. You can always change your mind later, since none of the calling classes know you’re using it. I’ve wrapped the progress bar, the date picker, and half a dozen third-party JavaScript controls.

4. Using GWT for layout

We all know the evils of FlexTable, but we need to go further. The layout technology of the web is CSS.

The problem

GWT provides FlexTable, DockLayoutPanel, VerticalPanel, and many others to do layout in HTML. They put the layout in your code and make GWT feel a lot like Swing. So why shouldn’t you use them?

They’re ugly. CSS isn’t just for aesthetes. Look at any big professional website – Google, Amazon, Facebook – they all live and breathe CSS. Without it you can’t really control or customize how your application looks.

You have to recompile. Needing to recompile for every pixel you change hurts your productivity. It also means your customers can’t customize your application after you’re done with it.

You can’t use Firebug. All user interfaces require tweaking and Firebug lets you do it live. Stick with HTML layouts and you’re poking around in the dark hoping your changes are OK.

The solution

Put all of your layout in CSS. This was one of our fundamental rules on my last project. Assign classes to your elements, write tags first GWT, and make a professional application.


Our understanding of good on the web is changing. Just working isn’t enough anymore. Good applications run fast, look professional, and are easy to use. Most of these anti-patterns are advanced. They represent subtle new ways of thinking about GWT. Patterns at this level are a sign of maturing technology and our maturing understanding of it.

  • Nice article, thanks for taking the time for the post. You mentioned “There are many frameworks, like Ext GWT, that wrap existing JavaScript code.” Ext GWT does not wrap any JavaScript code, rather, it is fully implemented in Java using GWT.

  • Thank you very much for the correction Darrell. I’ve updated the article. I think I was getting confused between Ext GWT and GWT-EXT.

  • UiBinder has done a lot to remove layout from code, and LayoutPanel provides easy programmatic access to complex CSS layout. You can also write CSS code directly into UiBinder xml files. Do you still recommend doing all layout in CSS?

  • Thank you for your comment.nnI still recommend doing all your layout in CSS on two levels. The first level is to make sure that all of your layout is using CSS in the end instead of HTML tags for layout. That means no FlexTable or other tag-based layout mechanisms. Styling with CSS is much more manageable and flexible. nnThe second level is to put your layout into CSS files. I think that is the level you were asking about. CSS files give your more direct control, can be edited without recompiling GWT and are easier to manage. It also means you can have designers edit your CSS who don’t know Java very well.

  • Stefan

    The question is: Why would you use GWT? It is much better to separate presentation layer (done in HTML/CSS) and application logic (let it be Java, PHP or whatever).  With HTML you have full control of your layout. You can write standard compliant pages. Using JQuery or Prototype JavaScript library will make even your Ajax calls simple.

  • That is a very difficult question. JavaScript and GWT can work well with Java, PHP, or any other server-side technology you choose. I’ve written many projects with each and I haven’t come up with a single best approach. When I’ve worked on small projects with a lot of low-level DOM manipulation I’ve done them in JavaScript, but larger projects are often in GWT.

    A big part of this decision is just a personal/team preference about working on Java vs. JavaScript. They are very different languages and each has pros and cons. GWT has some amazing advantages for larger teams and I normally find large GWT projects easier to manage than large JavaScript ones.

    JQuery, Prototype, and many other frameworks make AJAX easy, but REST calls, error handling, and reusable modules still need work.

    This is all a long way of saying that I don’t have a good answer to why you should use GWT. It has some amazing advantages, but so does raw JavaScript. Like many technology decisions there isn’t always a clear winner.

  • raivis

    I was searching the web for some GWT related questions and found your article. It is just a common sense to use CSS for the layout in static webpages, but I’d like to ask if you would still prefer CSS if we talk about dynamic RIA that looks and behaves like desktop app with many internal windows that can be re-sized by the user? I am currently developing one and as it’s my first webproject ever I just want to know “the right way” of doing that.

  • We work on a lot of desktop-like web apps and we always use CSS layout. CSS is the layout manager of the web.

    You might be interested in Fluid Grids, Vertical Rhythm, and CSS Blocking.

  • Piotr Sobczyk

    Thanks for nice post, Zack. We really tried to keep all our layout driven by CSS. By in at least one case GWT driven layout was helpful for us:  it were dock layouts. We have some situations where we really need some components to have fixed size and one component to grow to fill ale remaining space (changing dynamically when user grows browser window etc.).

    I managed to simulate simple GWT dock layout with north and center elements by trick with position:absolute; top: some-number-of-px; bottom: 0; left: 0; right: 0; for central component to take all remaining verical space under upper component. But I couldn’t by any means simulate dock layout with south and center elements :(. So I had to fall back to GWT dock layout panel and it works good :(.

    Have you met similar problems in your projects? Do you maybe know how to simulate dock layouts in CSS? I spent some time searching but I didn’t found nothing working fo us.

  • Hi Piotr,

    It sounds like you’re running into a well known problem with CSS called pixels plus percent. You could do a dock layout easily in CSS if you could set the size of an element to be something like 75% of the width of the page minus 125 pixels. The problem is that CSS doesn’t support that until version three.

    CSS3 does have support for pixels plus percent style notation so you can do dock layouts easily. The only problem is that CSS3 is only supported in modern browsers.

    You have two choices if you want to support a dock layout:

    1. User CSS3 and don’t support older browsers.
    2. User a little bit of code (JavaScript or GWT) to set the width of your element dynamically.

    The dock layout in GWT is using option number two, but writing it yourself only takes a couple of lines with a framework like jQuery.

    Good luck,

  • Piotr Sobczyk

    Thanks for your wise words, Zack. I don’t really like option two: If I already have components doing it for me, why should I rewrite their functionality and adding complexity to my code?

    Option 1. feels much more better, unfortunately we still have to support IE8 so using CSS3 is out of question in our case :(. 

    So we’ll probably stick with GWT components until we’ll be able to use CSS3 (our company standard browser will be changed to IE9). Anyways, thanks again for sharing your wisdom!

  • Mark Davis

    Thanks for sharing your experience here.

    Here is what our team experienced in developing a dozen of GWT projects.
    GWTRPC is easier to use and debug (specially if u use maven plugin),
    because less options for  TYPOs, we noticed no difference of  performance of GWTRPC vs REST in intranet projects (do u have any benchmarks that proves different?)
    REST is by no means an easier programming model, it only brings on more layer of headache (parameters binding). If it is only for flexibility reason, can u tell what % of your projects u had to port to other server(python/php) or client(JavaScript/Flex?) platform from java?
    We totally agree that the number of server hits should be minimized (for startup we usually send everything application needs in a one response, which is collected from several concurrent threads getting everything from the database, works fast as a rocket).
    Agree on security statement, however it is hardly an antipatern – even GWT team has an article on what issues we can face in a security field.
    About “Using only GWT”, it totally depends on project requirements, sometimes it is easier to rewrite  something in GWT, sometimes it is easier to borrow from prototype and others, so not an anti pattern from our point of view.
    Using GWT for layout – saying using Swing approach is a bad idea for applications building  is like saying using that the whole  ThickClient application industry was going wrong way for 15 years. This approach has it’s disadvantages but it is so much easier to program when it comes to something complex (that is layout is changing on a fly). In other words, for static layout declarative approach is OK, for dynamic layout an approach with layout mangers was invented more than 15 years ago.

    Best Regards

  • Hi Mark,

    Thanks for asking.  It’s about two years since I wrote this article and I still love REST.  The biggest reason I love it is because it forces us to write better code.  We create more documentation and cleaner separation between the client and the server when we use REST.  It’s also much easier to debug.

    As far as porting the code I rarely move to other servers, but every one of my projects has had multiple clients.  Sometimes our customer write custom clients and sometimes we do.  REST has been a life saver when we add native mobile clients and don’t need to change anything on the server.  

    As far as layout goes using CSS has also saved my projects time and time again.  We can easily change colors and fonts and maintain consistency throughout the application.  We also let our customers write CSS to overlay ours so they can do everything from adding their company logo to moving the labels to the right of fields instead of the left.

    You might be interested in checking out Spiffy UI.  It’s the framework we use for all of our GWT applications.  It includes CSS frameworks, security, and REST utilities.

    I hope it helps.


  • Mark Davis

    Hello Zack,
    Thank  you for clarification.

    Since we our applications run in Intranet we don’t have clients using our API at all. Now it is clear why you prefer REST approach.

    Thank you very much for the link to Spiffy UI,
    am I right that your team uses http://www.spiffyui.org/?rest to simplify calling REST services from GWT?

    PS Getting back to CSS approach, we give a style to each GWT container we use, this allows us to change colours and fonts on a fly as well but for Layouts we prefer programmatic approach since it is much more flexible than declarative (css).


  • We are using the methods outlined on the Spiffy UI REST page. It gives us a single interface to control all of our REST calls and handle security integration.

    As for CSS layouts I’m surprised to hear you describe CSS as less flexible. I’ve found CSS much more flexible in many cases that layout out with GWT which often uses table tags. You might like to check out the scrolling navigation on the Spiffy UI CSS page here: http://www.spiffyui.org/?css.

    Once button changes the entire navigation mechanism of the application. We can make that happen because we use CSS for layout.


  • Ebaka

    Aspiring bullshit!