As GWT evolves into a senior technology we are developing some good patterns for writing applications and finding some anti-patterns too. This article presents five GWT anti-patterns that are short-term gains and long-term losses. They are found in many applications, and even some of the GWT documentation, but they can get you into trouble. Avoiding these patterns keeps your applications fast, maintainable, and high quality.
1. Too Many AJAX Calls
The problem
GWT makes AJAX calls amazingly easy, but it can’t make them any faster. Every time you make an AJAX call back to the server it creates a new HTTP connection. HTTP is based on the idea of making a small number of requests for a relatively large amount of data. To support this, HTTP uses a connection scheme called a three way handshake. This handshake makes sure that you can send data back and forth without losing any of it. It is also expensive.
Every time you make an AJAX call you’re creating work for the browser, the server, and the network. The browser slows down dedicating system resources to establish a new server connection. The server spends time allocating a new thread to respond to the request, parsing all of the headers, and creating a set of new objects. The network slows down because it must handle all the traffic required to set up and tear down the connection.
The solution
Combine your AJAX requests into one call that sends back more data. This is the same idea that makes CSS sprites work so well. For each GWT page I like to create two AJAX calls getData and sendData.
getData is called once when the page first loads. It gets whatever data the page needs from the server. If your page isn’t showing dynamic data you can skip this call. sendData is called whenever the user changes data and tries to save it. Sure there are some complex interactions that need more, but two requests is enough for most pages. Combining requests makes your pages run faster and your servers handle more concurrent users.
2. Inline JavaScript
The problem
The promise of GWT is that you don’t have to write JavaScript and it delivers on that promise very well. Sure you have to write the occasional native method, but mostly you can focus on your Java code. Native methods can be difficult to maintain, but inline JavaScript is impossible.
The most common way to insert inline JavaScript is generating attributes like onclick, onmouseover, or onmouseout with one of the DOM helpers or as a string. You might do something simple in response to these events like change a CSS class for a hover effect or call a helper method, but it will get you into trouble. This type of code is difficult to maintain, can lead to cross browser incompatibilities, and prevents the GWT compiler from checking and optimizing your code.
The solution
The solution is simple, use the GWT listeners and handlers to handle these events. GWT provides a complete set of listeners to let you respond to mouse clicks, hovers, and drags with a clean coding model. Almost every instance of inline JavaScript can be replaced with a listener. If you absolutely have to use inline JavaScript, then make it a native method so the compiler can check and optimize it for you.
3. Listeners Instead of CSS Pseudo Classes
The problem
One way to make your code easier to maintain is pushing as much as possible into CSS. Style sheets are easier to change, don’t require a recompile, and are more likely to work in every browser the same way. It also gives you a single place to change the look and feel of your application that guarantees UI consistency. However, GWT developers often ignore CSS pseudo classes.
A pseudo class in CSS is a way of identifying a specific state in the DOM. The most common pseudo class is hover. It looks like this in a CSS file:
.myclass:hover {
background: red;
}
|
The solution
This simple example will turn the background red whenever the mouse is over any element that uses myclass. You could create a mouse listener and hope you got all the events right, but the browsers do that work for you. Using pseudo classes means you write less GWT code, generate less JavaScript, and make faster running applications. It also make the code much more maintainable since you can get the effect by just adding a class declaration.
4. Window.alert
The problem
Window.alert, like e.printStackTrace, does not belong in deployed code. I know it is easy to write and useful for debugging, but the end result is ugly and unprofessional.
Window.alert can also cause bad behavior when someone clicks a link too fast. If your GWT page is in the middle of an AJAX call while a user click a link for a new page it will cause an exception. If you pop up an alert dialog it prevents the user from actually going to the next page.
The solution
The solution is to properly user-proof your application. Instead of showing an alert box create a place within your UI for error messages. Look at the way they handle errors in this example.
5. FlexTable
The problem
FlexTable is the workhorse of many GWT applications, but using table tags for layout is like mowing your lawn with a weed wacker. FlexTable feels like using layout managers in Swing. GridLayout works well in Swing, but a web browser is not a windowing toolkit and GWT is not Swing.
FlexTable uses table tags for layout under the covers and you should never use HTML tables for layout. The two biggest reasons for avoiding table tags are lack of flexibility and maintainability. Tables aren’t flexible. That means you can’t position then right or make them look really good. Tables aren’t maintainable because you can’t easily move things around or mix them with other elements. Try moving a table cell outside of a table and you’ll see what I mean.
The solution
The salvation from FlexTable lies in CSS layouts. CSS doesn’t just do fonts and colors, it can be your layout manager. There are many good articles out there about CSS layout, but it comes down to one simple fact: CSS works better. It is easier to maintain, looks better, and works more reliably across browsers. Need more proof? Check out any of the big websites, they all use CSS positioning. If you want to use GWT well you must know CSS
Further reading
- Tags First GWT by Zack Grossbart
- Fluid Grids by Ethan Marcotte
- Free CSS Layouts and Templates from Smashing Magazine
- Tableless layout HOWTO from W3C.
Conclusion
As technologies mature we develop patterns and anti-patterns. They help us learn from the experience of others and avoid solutions that look good but come with hidden costs. I hope the anti-patterns in this article are helpful, but it is far from a complete list. What are the anti-patterns you’ve found with GWT?
4 More GWT Anti-Patterns
If you liked this article check out 4 More GWT Anti-Patterns.