[Be el o ge]

One of the exciting new features of HTML5 is the Canvas element. Today evening I checked out two libraries implementing the Canvas element for the Google Web Toolkit.

• GWT-Canvas by Oliver Zoran
• GWTCanvas as part of the GWT Incubator

I can’t really tell which library is better. Both seem to handle the Canvas API well. The biggest disadvantage at the moment is that you can’t run your code in hosted mode. The Incubator version promises that hosted mode works on Mac systems though. Users of other operating system will probably have to wait for OOPHM (Out Of Process Hosted Mode) which will be released along with GWT 2.0.
In my opinion one argument speaking for using the Incubator version is that this version is maintained directly by Google and that you get a lot more cool features by including the Incubator JAR.

The past few weeks I’ve been playing around with the Google Web Toolkit and I’m pretty persuaded that it’s the best choice for implementing Rich Internet Applications. Google itself used it for the Google Waves front-end and for a complete re-write of the Google Adsense admin application. There are other companies out there using GWT in an enterprise environment ,e.g. Lombardi Blueprint.

How to communicate with the server?

GWT supports two ways to communicate with the server. The first is GWT-RPC which requires a Java server side because you need to implement a Servlet. Now this sounds more painful than it is. In fact it’s pretty straight forward. The really nice thing about it is, that you don’t have to think about serialization / deserialization of your objects. The Google Web Toolkit will take care of that.
The second approach is rather classical and that is to send and receive JSON or XML. Clearly this enables you to use whatever server side framework and that is great. The downside of this flexibility is that you have to take care of serialization by yourself. Luckily Ryan Dewsbury provided a code generator in his GWT Applications Book which automatically generates the serialization code for you. Check out the code on his webpage.

Ok cool, so that means I should take which framework?

There are so many web frameworks out there that it’s not hard to loose completely overview. For my personal preference I can narrow down the number of frameworks to consider to these two: Ruby on Rails and Grails, the Java web application framework based on the Groovy programming language.

Ruby on Rails is currently by far the most popular web application framework. What I really love about the framework is that you get all in one. A descend MVC architecture, Templates, easy REST, testability, database migrations, a very healthy and active community (which is really really important), Ruby, hundreds of plugins, you name it. The framework has gone through two major iterations and can be considered business ready. Companies like Thoughtworks generate a big part of their annual revenue with Ruby and Rails projects. There are great hosting companies (Engine Yard, BrightBox, Heroku to mention just a few), the deployment became much easier than in the early days and when it comes to performance you have a whole bunch of great choices to improve it (check out this series of screencasts).

Grails uses Groovy as language. Both Grails and Groovy look very similar to Rails and Ruby. Grails is still pretty young but I believe in the coming years we will see a lot more Grails applications. One reason for this is the very tight integration with Java. So are for example most valid Java programs also valid Groovy programs. This makes it really easy for Java developers to try it out. Also Grails builds up on proven Java technologies like Hibernate, SiteMesh and Spring. So though Grails might still have some quirks, the technologies underneath are out there for quite a while and used in thousands of applications. This also makes it easier to re-use existing code and infrastructure and sort of gradually move towards a more agile environment. It’s really made simple to use technologies like JMQ, JMX or libraries like Lucene.
Despite Grails is build upon things you know from JEE you don’t have to go through configuration hell. Grails puts Convention over Configuration and sets useful defaults just like Rails does.

Conclusion

Ruby on Rails is the original, it’s proven and you finally don’t have to worry any more about the Java technology stack. The only downside in terms of using GWT on the front-end is that you can’t use GWT-RPC.

Grails is great if you need to integrate with Java. Because of the big Java community we will see more talk about Grails in future. It’s also a good choice in combination with GWT. There’s a plugin for GWT and also AppEngine.

All in all I believe you don’t do anything from with either framework. It’s about personal preference. I’d like to see some performance comparison between GWT-RPC and the JSON/XML approach with generated serializer though. Your choice might be influenced by existing systems or libraries you have to use. This is true in both directions. With JRuby becoming a more and more mature Ruby implementation, Java integration is not anymore just a dream, although it’s not as tight as in Groovy / Grails.

Update:
Mastering Grails – Grails in the Enterprise
Proof of Concept : Learning Groovy, Grails, JRuby, and Rails

It might have been announced somewhere else already, but I read it first in this forum post:

REST : It’s maybe time to add Http methods PUT & DELETE

HI all,
The GWT team also agrees with you. See Issue #3388 (link below) to receive updates once the fix for this has shipped. It is currently planned for the GWT 2.0 release and is marked as a high priority fix.

Issue #3388

Cheers,
-Sumit Chandel

This is great news!

I already wrote about the great GWT Best Practices talk by Ray Ryan on the Google I/O.

Now there’s sample code for the Model View Presenter pattern online: http://code.google.com/p/gwt-mvp-sample/

I just finished reading two articles about Patterns and Anti-Patterns in the Google Web Toolkit. They’re not exactly about rocket science but nice summaries. Also some patterns are not specifically GWT patterns rather RIA patterns in general, but I don’t want to split hairs here…

Patterns + GWT + Ajax = Usability

Key points

• Client-Side validation. In the article called “prevalidation”, meaning making an async call to the server via Ajax in order to validate input data
• Code Sharing. Since you write your client side code in Java you can share code with the server side to a certain degree. Validation code and data objects are good candidates for code sharing.
• Caching. GWT provides several possibilities to cache data on the client side and thus reduce calls to the server. The user has to wait less and your server has less work.
• Prefetching. You can try to guess what data the user wants to see next. This can be very beneficial, but you be careful: sometimes the user thinks quite different than the developer
• Thread Simulation. Javascript runs in one thread. No chance to spawn a second one. Use the GWT Timer class to simulate threads or GWT’s deferred commands.

5 GWT Anti-patterns

Key points:

• To many Ajax calls. Solution: Use DTO’s to transfer bigger junks of data in less requests.
• Inline Javascript. Meant are not native Javascript methods, but manually added Javascript code as a String to onclick, onmouseover, etc. attributes. The compiler can’t optimize it, debugging is hard or rather almost impossible. Solution: Use GWT’s event handlers.
• Listeners instead of CSS Pseudo Classes. Solution: Sometimes it’s more effective and efficient to use CSS Pseudo class instead of GWT Listeners. CSS is easier to change, to deploy and faster because it’s handled by the browser, not the browsers Javascript engine. But be aware of browser differences, specially if you have to support IE6.
• Window.alert: Window.alert and async calls don’t go well together. Just don’t use it. Plan some area in your application which displays the error and warnings.

The article mentions a fifth anti-pattern: FlexTable. FlexTable is a powerful GWT class to display data which is supposed to be displayed in … well… rows and columns. Additionally to this obvious usage it’s used to layout applications and that is what the above article criticizes. If you look to the comments on that article you’ll find the typical flame-war CSS-based layout vs. table-based. In my opinion it just depends very much on the use case, therefore I wouldn’t go so far to call it an anti-pattern.