Mar 16 2009
Google Web Toolkit: AJAX development that doesn’t hurt.
The world of web user interface frameworks is in a continuous movement. If you look at the landscape starting from HTML forms through Struts and Tapestry to the latest achievements like Adobe Flex and Microsoft Silverlight you will see a big demand to make the web applications to look and feel like a genuine desktop software. The former frameworks represent the request-response approach and the latter group I call heavy weight fighters is providing a sandboxed environment (plugin you have to instal in browser prior to use the application) within browser space. Between those two endpoints there is a growing group of AJAX based frameworks gaining more and more popularity with every day. So far they prove to be the best solution for web interface you can choose today. Because its JavaScript in guts there is no plugins required, applications are running smoothly in any modern browsers and developers have access to environment rich enough to build a complex user interface mimicking desktop software. And remember it is AJAX – there is no need to reload page to fetch a batch of fresh data from the server side.
GWT (Google Web Toolkit) brings a new approach to the web user interface development. The guys from G decided that gluing Enterprise Java with web interface through an endless AJAX calls and developing JavaScript to alter the content in browser can be somehow done in nice and developer friendly manner. And this is what they created: A compiler that can take a bunch of Java classes and produce JavaScript as the output. “Nothing stunning” I hear you say and you are right.. unless you read the entry to the end. I will show the basic features of GWT that can make your next project to be a fully interactive application the same way the well known Google Applications are. I’m not going to cover low level details, that will be presented in separate entry
Quick Introduction and overview
The idea of building the web interface with Java is not new itself. EchoPoint was first project I know to take this approach. It required you to develop Java code that was build as a servlet and served dynamic web pages with business logic kept on server side. That solution was leading to many calls between browser and server. May work fine on a fast internal network but not a good solution to be used over the internet where the connection speed cannot be assumed. GWT’s approach is similar in its basics however it took a different turn at the first corner. Your Java code gets compiled into JavaScript that is a complete working application running in a browser. In a very simple scenario where no data from server is required you can have JavaScript output that could be zipped and sent to other person and yet it would be working fine. This is possible because GWT’s output is a fully functional application. It may not use network communication at all! Of course that wouldn’t be enough so you have access to GWT API for asynchronous Remote Procedure Calls (RPC). You can use them whenever you want, as you would call business layer. You are in control of what and when is transfered between JavaScript running in a browser and the server side business logic. Check the following images comparing request-response with RPC:
As you see GWT produces application that is made of fully featured client side talking to the server only to exchange data. The graphical widgets inside browser can talk to each other in response to user’s actions without involving expensive RPC. This is the solution that can only compared with either Adobe Flex or Microsoft Silverlight. And remember: It runs in pure browser, no extra plugins is required.
User Interface widgets expressed with Java classes are presented with ordinary HTML elements and GWT encourages you to use CSS to build the look and feel of the elements. This is a very good approach that allows to not separate the component’s logic (Java code) with the presentation (CSS) – one of the good design goals. Of course if you want to hurt yourself then nothing stops you from using low level API to access DOM elements and manipulate them. All the nasty things are allowed but remember you should avoid this otherwise you may get the output not running smoothly in browser.
I couldn’t skip the amazing debug feature available with GWT. This is made of a sandboxed browser hosting JavaScript application (this is why it is called “hosted mode”) while running in debug mode within your IDE. Not sure I you realize that, so let me repeat: “UI code is running in debug mode within IDE”. This way you can setup debug traps to capture html button events just for starters. All the code flow and variables are traceable and available to view and you have GWT console provided to browse the resources loaded with application, profile the execution and to inspect HTML DOM tree if you fall deep in trouble.
The following screens show how all this looks in real life:
Benefits
- Java based development means existing skilled people can be used.
- The compilation process is more than just a conversion from Java to JavaScript, it also:
- takes care about browsers compatibility producing a bunch of different scripts to be run in different browsers ( we all know about IE/Firefox/Safari/Opera (in)compatibility right? ). Scripts are selected automatically – you don’t have to worry about that.
- combines all the images used within the application together to make one big single image. That prevents icons from popping out on the screen as they are loaded. There is only a single image that loads at once.
- generates as small JavaScript as needed. No matter how big libraries you are using, only necessary pieces will get to the output.
- your application may not hut eyes when presented to the audience. You are not limited to squared frames and boring left hand side tree view. With CSS and skilled web designer you can develop a really nice looking applications.
- developer may never have to stick his nose outside Java code, e.g. in applications developed only with components from the standard library.
- It is possible to design and build a library of common reusable components that can be shared among different projects.
- well designed component can be a black box with look and feel altered through CSS.
- all the solution is provided by a well known company that is not going to abandon the project within next few months.
- communication to the server goes over HTTP protocol. It is common enough to not worry about firewalls. If the application can be served, it will talk to the server for sure.
Drawbacks and warnings
- nesting user level security may be a bit of a challenge
- Spring integration may be a problem.
- high use of java together with compilation process may at some point cause big troubles with application maintenance if you put presentation specific declarations within Java code (use CSS instead)
- developing own composite widgets may be a real pain in back. I had many fights with laying out widgets on the page.
- there are UI designer tools that may not always work. I had an example of GWT Designer not working with project created with Maven.
- Developers may easily come with solutions not suitable for the destination environment. Example: Idea of caching objects and overusing listeners came to me very quickly. You have to keep in mind that at the end of the day it is a JavaScript running in a browser.
- Design your application with RPC in mind. Asynchronous calls require you to design communication with server with special care. You have to keep in mind that data may be returned after a very long delay or never.
- Some of the other people’s arguable negative thoughts
Summary
This entry is just a top of an iceberg of the features and optimizations offered you for free with Google Web Toolkit. I just name a few more to treat you into reading through the links provided in Resources section.
- JavaScript Native interface – allows to define Java methods with your very own JavaScript
In my humble opinion you should check GWT as soon as possible. This solution is a reliable way to build rich web user interfaces without loosing time in low level browser compatibility issues and JavaScript nuances. Just check the GWT-Ext demo to see what can be achieved.