GWT.create EU 2013: A glimpse into the future of GWT – Nextgen Js Interop and Widgets 2.0

GWT.create EU 2013: A glimpse into the future of GWT
Nextgen Js Interop and Widgets 2.0

Presented by Daniel Kurka (Google).

In the beginning, Daniel quoted a phrase from google internal GWT docs:
“Widgets allow you to create high-level components out of DOM elements and tie them together in a widget hierarchy. This is very difficult to do in a coherent way with DOM elements, because you cannot create new DOM element classes.”

This will change in GWT 3.0. With Web Components support, we can define widgets with a level of visual richness and interactivity not possible with CSS alone, and ease of composition and reuse not possible with script libraries today. Daniel showed us a demo which simply used one element to realize text blinking, and one element to trigger a predefined animation when mouse over the element. We can also extend an existing element like this:

Then we can use it like this:

This will extend traditional button with mega-button component’s features.

To be able to implement Web Components in GWT, add all other HTML5 features and have better support for complex hybrid apps built with GWT and JS together, a new JS Interop API will be integrated in GWT. Then with certain java annotations, we can easily call native JavaScript functions or objects, and easily export GWT objects or functions to JavaScript scope. Today, to interoperate JavaScript code in GWT, we have two standard ways:

  • By creating native functions(which we called “JSNI”);
  • By using  JavaScript object (which we called “JSO”).

They work very well if you use correctly, but:

  • The JSO cannot be constructed with “new”, must use the common static method to get a JavaScriptObject instance and then cast it to the correct type;
  • All public member methods need to be final, means no more method overridden;
  • Only one single JSO may implement a specific interface;
  • We can’t mix and match type hierarchies from two domains (ie. JS and GWT);
  • We can’t extend a JS object.

At last, we lost almost all advantages of “Object Programming”, and there as a lot strange syntax /*-{…}-*/ to write to make it works. While now, with the new JS Interop API, we can simply write:

interface Window {
  void alert(String msg);
  boolean confirm(String msg);
  void addEventListener(String event, EventListener listener);

To realize what we do in current GWT version:

class Window extends JavaScriptObject {
  public native void alert(String msg)/-*{
  public native boolean void confirm(String msg)/-*{
  public native boolean addEventListener(String event, EventListener listener)/-*{
var callback = function(evt){*)(evt);
    this.addEventListener(event, callback);

As you see, no more strange syntax, but only one annotation @JsInterface. There are many others: @JsProperty for accessing property, @JsExport for export GWT functions or object to JavaScript scope, GWT.jsni(…) for JSNI without native methods, @JsConvert for type conversion, @JsInterface, @JsAware, @JsWrapper, JsObject, JsArray etc.

The second part of Daniel’s talk, was focused on the next generation widget API in GWT. With a live coding demo, he showed us how to use a predefined Web Component as Widget in GWT 3.0, and how to combine multi Web Components into one custom Widget. He also presented the generated HTML element, instead of a “div” element for common widget in GWT 2, we saw a meaningful root element for the custom widget like “”. This will allow us to have a more semantic DOM tree in browser for better debugging experience. And the Web Components widget can be easily reused in pure JavaScript scope.

But we should know this is still a working process. GWT 3.0 will be released on or around Google I/O 2014, and the integration of new widget API depends on Web Components support in browser. There is another question, since we are going to completely change the Widget API in GWT, how to maintain the compatibility with older browser is still in discussion in GWT team. The latest GWT survey showed in 2014, there are still 44% developers are expecting to support IE 8,9% developers are expecting to support IE 6/7.

Here are some links for anyone who wants to know more:



Leave a Reply

Your email address will not be published. Required fields are marked *