The last session in the gwt.create conference was a discussion panel with speakers, GWT steering committee members and participants asking questions.

Here some questions/ answers I managed to write downâ€¦

Q: What about Dart, GWT, say in two years?

The point is: GWT is here to stay, and even if Dart becomes the real next huge big thing, GWT will be one way to do it. Daniel reiterates that we should not think of one OR another.

Q: We donâ€™t want to debug in JS in Chrome. Any way to do it better then SuperDevMode?

Well, no. DevMode is going away, and that is not GWT teams fault. Browsers are closing the door to required plugins, JS debuggers and source maps are the way to go.

SuperDevMode is no replacement or DevMode, but it has advantages, hence we start debugging in the target language/ platform. Besides, SuperDevMode is the only way to debug on mobile devices.

We also must take the improvements made by browsers/ debuggers in the past, so there is hope. IntelliJ is working on a remote debugger, nothing is known about Eclipse.

Attendees stated real life issues with SuperDevMode and the thread posed by not having DevMode ready, stable, fast, usable by the time the plugins stop working.

Discussion also showed that adoption might be better if setup is easier. Still, the worst case as described by Ray would be that we cannot use DevMode in the newest browsers â€“ specifically Firefox and Chrome. We must keep in mind that actually DevMode is already broken in Safari and mobile devices.

Q: If you had a magical wand, what would you add/ remove change from GWT?

Nice question, here some statements.
Please donâ€™t take them seriously, as no one really does have a magic wandâ€¦ Â :-)

Remove UI binder in favor of a HTML template mechanism

Incremental building

Vertical and Horizontal Panels (attendees cheerâ€¦ Â :-) Â )

Kill the Widget system (because it was original made to fix IE6 memory leaks) in favor of a light widget model

Remove the â€žSerializableâ€ś interface support for GWT-RPC, as the implications on compilation are huge

gQuery is a purely GWT port of jQuery, this way taking all advantages of the GWT compiler.

The main purpose is to enhance UI elements:

Java

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

importstaticcom.google.gwt.query.client.GQuery.*;

importcom.google.gwt.query.client.Function;

publicvoidonModuleLoad(){

//Hide the text and set the width and append an h1 element

$("#text").hide()

.css("width","400px")

.prepend("<h1>GwtQuery Rocks !</h1>");

//add a click handler on the button

$("button").click(newFunction(){

publicvoidf(){

//display the text with effects and animate its background color

$("#text").as(Effects)

.clipDown()

.animate("backgroundColor: 'yellow'",500)

.delay(1000)

.animate("backgroundColor: '#fff'",1500);

}

});

}

gQuery can also be used to create completely new HTML based widgets, while still providing the full widget component interface. Â This allows us to create lightweight widgets and repeat less code by using the core functionality provided by the library.Â Another very interesting part is that, by being entirely written in Â GWT, Â the compiled code will include only the pieces that were used.

Further, gQuery offers a set of functions very useful and missing in the core GWT distribution:

The days of the GWT DevMode are counted. Why? Because DevMode relies on a native browser-plugin to work (that approach was introduced with 2.0 and was called Â OOPHM, out of process hosted mode). Those browser plugins rely on the C++ NPAPI, which will be deprecated on chrome by the end of 2014. Safari has already disabled NPAPI support (and thus broken DevMode on the Mac + Safari setup).Â To make things worst, mobile devices never offered such an native API.

Having its days counted, a future solution must be found. The new solution is not new and have been around for while: the SuperDevmode. And interestingly, this solution will work with mobile devices too.Â So while not new (and there are a few good blog posts documenting how to set it up), there are a few things that me must know.

First, we switch over to Javascript debugging. To keep things readable, GWT provides source maps, but Chrome is the only browser where you can use them. Firefox and Safari are meant to support source maps someday, but it is not working as of today as stated byÂ Erik Kuefler.

Secondly, IntelliJ is already working on a remote debugger solution that will probably be released soon. So if you are looking for a tighter IDE integration for future GWT development, it seems like IntelliJ is the IDE of choice.

While the new approach is promising when it comes down to JavaScript to Java end to end debugging, it feels like a huge step backwards when you are used to Â debugging tools in Java development.