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.

Crux allows you to create web user interfaces in a declarative and modularized way, which drastically improves development speed and code maintainability. In other words, it brings you the best of both worlds: the comfort of creating pages with HTML and the elegance of controlling those pages using Java code.

So … could we say that GWT + Crux is JSF done right?

You might want to check out UiBinder as well, which is part of the GWT Incubator. I wouldn’t wonder if UiBinder or a similar technology finds its way into GWT 2.0 or later.

For some time already Drag & Drop within the browser is a pretty common feature for web applications. The next step would be Drag & Drop interaction between your desktop and the web application … without using a plugin (Adobe Air, …).

Swell, a Javascript library, seems to be promising: Wouldn’t it be Swell to be able to drag and drop between Web and desktop
Also there is a demo on their web page: Drag and drop files from your desktop to your browser. They say “two browsers are playing well with the demo (Safari 4, Chrome 2+) while others degrades gracefully.”

Now, even cooler would be such support in the Google Web Toolkit, but it seems a common approach there is to utilize Google Gears, which again forces the user to install a plugin (except in Chrome, where Gears is an integrated component). Read more about it here and here.

Google Web Toolkit Architecture: Best Practices for Architecting your GWT App

Langsam aber sicher kämpfe ich mich durch die GWT Session Videos von der Google I/O.

Das Best Practice Video ist mit Sicherheit eines, das man sich auch mehrmals anschauen kann, bzw. sogar muss.
Grundlage für die Best Practices sind die Erfahrungen, die das Team um Ray Ryan während der Neuentwicklung von Googles Adwords UI gesammelt hat.

Kernpunkte sind:

1. Man sollte sich frühzeitig darum kümmern die Browser History korrekt zu implementieren.
2. Verwendung eines zentralen Event Busses
3. Dependency Injection (DI) mit Google Juice oder Gin + Model View Presenter (nicht Model View Controller)

Des Weiteren:

• Nur soviel Daten laden wie gerade benötigt werden. Der Rest kann jederzeit asynchron nachgeladen werden.
• Für GWT UI Code ist es besser konkrete Implementierungen anstatt von Interfaces zu verwenden: z.B. ArrayList anstatt List. Das steigert die Performance.
• Command Pattern (Cache, Failure Handling, Undo / Redo)1

Wer das ganze mit etwas Zusammenhang haben möchte sollte sich das Video anschauen oder die Präsentationsfolien herunterladen.

Kurze Zusammenfassung dieses Talks: GWT Can Do What?!?! A Preview of Google Web Toolkit 2.0

OOPHM (Out Of Process Hosted Mode)

• Supports multiple Browsers. Currently just one browser per operating is supported: Windows: IE, OS X: Safari, Linux: ancient Mozilla version
• Communicates over network with your hosted mode instance: Great if you’re working on Mac OS X but want to test in IE
• Included in GWT 2.0 available as Plugin for 1.6 Available in SVN trunk

Compiling Performance

• Prefer hosted mode over compiling code, because compiling is slow
• In 1.6: compiler option -localworkers X, compiles X permutations at a time
• In 2.0: -draftcompile: exclude certain optimizations, just get a compiled version. Great for development, not designed for deployment
• Restrict number of permutations: e.g. just compile for Firefox or Firefox and IE

Size of Scripts

• Break script blocks in multiple script blocks
• Asynchronously fetch code when needed: GWT.runAsynch()
• runAsynch creates split point in the dependency graph

Client Bundle

• GWT 1.4 introduced ImageBundle
• GWT 2.0 will extend this for many more data types: TextResouce (e.g. XML or JSON > great for configuration), ExternalTextResource, DataResource (PDFs, MP3s, …), CSSResource
• CSSResource includes a ton of cool features like: CSS Parsre, CSS Constants (@def), conditionals (@if, @elif).
• CssResource already available via Incubator!

Layouts

• “Have cold sweats when considering measuring everyting” > resizing by Javascript kills the performance of your app.
• Dealing with CSS attributes like height:100% is an endless pain
• Therefore GWT 2.0 will come up with updated Layout components like an updated Version of the Dockpanel (check out the Video to see it in action)
• These updated Layout components don’t run any Javascript code, instead they use CSS constraints

After the talk somebody asked when the GA release of GWT 2.0 will be. Bruce Johnson said something like “Q3 we will start thinking about when we could place the GA”. Also he promised it will be definitely less then a year. So realistically it’s probably Q4 2009 or Q1 2010.

Google Web Toolkit @ Google I/O
14 Videos from LA Ruby 2009: Some Great Weekend Watching

Ich beschäftige mich in letzter Zeit etwas intensiver mit GWT. GWT selbst kommt mit einer Vielzahl brauchbarer Widgets. Diese Widgets sind vom GWT Team getestet und optimiert. Beginnt man ein GWT Projekt, wird man jedoch relativ schnell feststellen, das die Grund-Widgets relativ schnell ausgereizt sind bzw. man sich eine etwas erweiterte Funktionalität wünschen würde. Man steht vor der Entscheidung die Widgets von Hand zu erweitern oder eine der vielen Bibliotheken zu verwenden. Grundsätzlich gilt: Don’t Reinvent The Wheel, Unless You Plan on Learning More About Wheels

Welche Bibliotheken gibt es also? (siehe Stackoverflow.com)

• EXT-GWT
• GWT Components Library
• GWT-EXT
• GWT Widget Library
• GWTiger
• Rocket GWT
• Dojo
• SmartGWT

Nun gibt es zwei grundsätzlich unterschiedliche Arten von Bibliotheken

1. Sogenannte Wrapper, z.B. GWT-Ext und SmartGWT
2. “Echte” GWT Bibliotheken

Meiner Meinung nach schließen sich Wrapper Bibliotheken von alleine aus. GWT kompiliert Java Code und erzeugt dabei für einzelne Browser optimiertes HTML und Javascript. Neben vollem Java IDE-Support sind das die Hauptvorteile von GWT. Da die von den Wrapper-Bibliotheken gekapselten Javascript-Bibliotheken bereits in Javascript vorliegen, kann der Compiler nichts mehr optimieren. Wenn GWTs Hauptvorteile also wegfallen, warum sollte ich aufwendig ein neues Framework lernen? Nur um anstatt in Javascript in Java zu programmieren? Für die meisten Projekte lautet die Antwort nein. Sind einige der Features einer Javascript Bibliothek derart wichtig für ein Projekt, dass man nicht darauf verzichten kann, ist man meiner Meinung besser beraten die JS Bibliothek direkt zu verwenden, ohne GWT zwischen zuschalten.

Bleibt noch die zweite Möglichkeit, die “echten” GWT Bibliotheken. Diese passen in soweit besser ins GWT Modell, als das sie auf die gleiche Art und Weise funktionieren und somit im optimalen Falle die Gründe warum man GWT verwenden möchte nicht ad absurdum führen: Javascript-Optimierung auf Performance und Browser-Kompatibilität.
Die umfangreichste GWT Bibliothek ist momentan wohl Ext GWT (auch GXT genannt), welche nicht zu verwechseln ist mit GWT Ext auch wenn die Namen zum vertauschen ähnlich sind:

Ext-GWT (formerly MyGWT) is a “pure” Java/GWT port of the well known Ext-JS JavaScript library, not to be mistaken for gwt-ext, which is a Java/GWT wrapper around Ext-JS… Still following?

In short, gwt-ext requires Ext-JS, while Ext-GWT doesn’t. Ext-GWT is from the same company that makes Ext-JS (appropriatley called Ext), while gwt-ext is an independant work. Also, since version 2.1, Ext-JS removed LGPL from its licensing options, which effectively prevents software like gwt-ext from using it, so it’s stuck with v 2.0.x.

Quelle: blog.gerardin.info
Ich habe eine Weile mit Ext-GWT gespielt, schnell fallen einem aber Nachteile auf:

• Einige Widgets rendern nicht korrekt im Hosted Mode Browser (fairer weise muss ich an dieser Stelle zugeben, dass ich mit Ext-GWT 2.0 RC-1 getestet habe, Version 1.2.4 mag sich besser verhalten). Das ist insbesondere deshalb nervig, da der GWT Compile-Vorgang recht langsam ist.
• Das First-Page-Load Volumen steigt drastisch, nicht weiter verwunderlich, aber eine Tatsache, die man im Auge behalten sollte: Braucht man nur ein einziges Widget der Bibliothek wird viel Javascript geladen, das nie ausgeführt wird.
• Nicht alle Widgets entsprechen den Performance-Ansprüchen, die man an eine RIA stellt. Die Benutzerfreundlichkeit soll verbessert und nicht verschlechtert werden!

Weitere Vor- und Nachteile von Ext-GWT kann man hier nachlesen: Why Ext-GWT MVC is broken, GWT 1.6 and GXT 2.0-M1 upgrade experience, gwt libraries (die erste Antwort ist äußerst hilfreich!), Best GWT widget library.

Zwei Bibliotheken gibt es dann doch, die den Ansprüchen genügen: Incubator und Mosaic. Beide bei weitem nicht so umfangreich wie Ext-GWT, dafür aber auch viel einfacher und gefahrloser in bestehende Projekte zu integrieren.

Zusammenfassung

• Wrapper: Ist man auf eine Großzahl der Features einer der großen Javascript Bibliotheken wie Ext JS, SmartClient oder Dojo angewiesen, sollte man sie besser direkt verwenden, als GWT zwischen zu schalten. GWT verkompliziert an dieser Stelle Integration, Entwicklung, Upgrade, Deployment, ….
• Echte GWT Bibliotheken: Ext GWT beherbergt viele gute Widgets, man erbt aber auch viele Probleme: Upgrade auf neuere Version, schwer erweiterbar, festgelegte Templates. Für ein internes Projekt, das selten aktualisiert wird mag das Ok sein, für andere Fälle nicht. Mosaic und Incubator erlauben die maßvolle Erweiterung von GWT und bringen wenige oder keine Probleme mit sich

Ich hoffe das geschriebene und die Links helfen weiter.

Einfacher, schneller UML Editor. Implementiert mit GWT:

GWT UML

Wichtig ist der Hinweis ganz unten:

This app is NOT meant to be run under internet explorer !!!