GWT in 2016
Until the release of the 2.8 version, let’s do a retrospective and look what happens in the past year. A little refreshment is needed. 2015 has not been the GWT 3 release year nor the 2.8’s. Nevertheless the fact remains that the team worked hard and that the community is still active.
Many questions arise for developers and project managers on the direction to be taken to continue using this tool and the ecosystem (the Web) in which produced code runs (HTML / CSS / JS browser or even Node JS, why not ?).
What happened in 2015 ?
Note that the beta version of GWT 2.8 is available on maven central , using the 2.8.0-beta1.
First here are the technical improvements that have been developed. These were presented during the GWTCon 2015 keynote, a conference especially dedicated to GWT which was held in Florence (Italy) for the second consecutive year. A kind of GWT.create organized by the user community.
GSS: The replacement of ClientBundle (CssBundle) is now stable (at Google, all the GWT applications were migrated to GSS). The old implementation CssBundle will be deleted right after the release of GWT 2.8. Contrary to what was initially planned, GSS will not be used by default in version 2.8, so as not to block the migration to GWT 2.8. GSS produces much better optimizations than CssBundle, so there is an obvious interest at migrating to it (although in my humble opinion, i prefer to use tools like HexaCss which I find much more flexible).
New features have been added to GSS: including the
loopfor the function
@gen-webkit-keyframesto optimize the generation of CSS keyframe animation.
Compilation time: the SuperDevMode is 6x faster than GWT 2.7. For example, compiling Inbox took 30 seconds with GWT 2.7, the time was reduced to 3 seconds with the 2.8 version. 100% of GWT applications at Google use SuperDevMode with incremental compilation. The production compilation has also been improved with the introduction of a new optimization: during GWT compiler optimization phase, only the code that has changed is re-analyzed to find possible new optimizations. This gave a 20% gain on compile time on large applications at Google.
Java 8 support : syntax is fully supported (lambdas, reference methods, default methods, …). For JRE emulation, only some parts will be implemented as
Optionaland more importantly, the streams will be delivered with official 2.8.
Integration IDE (Eclipse): Brandon Donelson is now responsible for the maintenance of the GWT part of the Google plugin for Eclipse.
Using Source Maps: The generation of source map files is very important to ensure minimal debugging experience, both on a browser with SDBG. The Chrome Dev Tools team has incorporated many improvements and Java debugging in Chrome has been greatly improved.
Web Components: nothing on this side. The gwt team waits for the official release of Web components and their support in Ecma script. The problem is that the specification does not progress much - and it does not give very incredible value over the usual encapsulated object model in GWT (Widgets).
Performance: Operations on
HashMaps are 2.8 times faster,
Longdivisions are five times faster.
Booleanare no longer boxed, which brings a good performance gain.
It may be noted also the possibility to access the GWT compiler properties in the standard Java way, ie
System.getProperty("foo.bar"). The property “foo.bar” can be defined in a
define-propertynode of the gwt module.
GWT 2.8 release was announced for mid-December at the GWTCon conference in Florence November 11, 2015. The deadlines have not been held since version 2.8-beta1 is still opened and receives final patches in number proportional to the amount of issues reported by the beta testers… So please do not hesitate to test this version, to check compatibility with your code and especially to report anomalies.
GWTCon 2015 Conference
This conference was held in Firenze (Italy) on 11 November 2015. A day dedicated to GWT. Members of the steering commitee were almost all represented, with Julien Dramaix for Google.
Here are the sessions I attended, there were often two conferences simultaneously. Check the website to see videos and slides.
- Keynote (Julien Dramaix - Google) announcements related to GWT 2.8 and 3
- Gwt with Polymer : Web components in action! (Manuolo Carrasco - Vaadin)
- Best practices with Gwt (Christian Goudreau - Arc Bees)
- JsInterop deep dive (Julien Dramaix - Google)
- Augmented reality WebGL (Francesca Tosi & Alberto Mancini - Jooik)
- Introduction to Errai 4 (Max - Redhat)
- GXT and TouchEvents (David Chandler - Sencha)
- Maintaining large applications : the JBoss WildFly console (Harald Pehl - Redhat)
- Write applications without
gwt-user(Cristiano Constantini - Thales)
- An introduction session to design for beginners (Manon Gruaz - Arc Bees)
- Introduction to annotation processing (JSR-269): to replace old generators GWT (Arnaud Tournier - LTE Consulting)
Here is a video of GWT Con, which has its own channel on YouTube:
Many people ask what happened with this framework … Singular is a project that had been presented and even announced at GWT.create 2014, aimed at cross-compiling a Java code base to both the browser and mobile platforms. All this with the generation of native code on Android and iPhone and a programming style à la Angular - without performance problems because the data bindings are resolved at compile time and do not use dirty-checking to operate. In short, a very attractive project.
A demonstration was conducted by Daniel Kurka and the upcoming release of a beta current 2015 was announced. But it has not happened! Silence…
And the community seems to wait for it, well at least waited for it. As you can check, the project-related mailing lists are now very inactive - when this is not a message from a person who asks what is happening.
Julien Dramaix clarified the situation at the conference: Singular is indeed on stand-by, at least the time needed to assemble the first version of Jackal (the future GWT compiler 3, see below) which is the number one priority for Google.
So there is nothing to expect on that side for the moment … Nevertheless the project is not necessarily dead so far. In short, those who were impatient to use it to their next application: it’s not for now.
Roadmap for 2016 and beyond
GWT is pulling a lot of burdens. This tool has indeed more than ten years and the architectural decisions made at the design time are no longer necessarily ideal.
In reality GWT actually does too much: permutations, code generation, optimizations, the SuperDevMode server with source files monitoring, logic libraries (widgets, rpc, UiBinder, …), etc.
J2CL which is pronounced
Jackal, like the animal. This compiler will issue ES6 code featuring jsdoc Closure annotations that will enable the Google Closure Compiler to handle the optimization part.
What on the other side will not be Jackal :
- will not be an optimisation engine nor a linker (closure takes this role),
- will not be dependency injection tool (eg use dagger2)
- will not have a specific mechanism of code generation (use the standard Java JSR 269 instead)
- is not a web UI framework. Actually J2CL will not even be designed around the DOM.
The roadmap is not yet fully defined but J2Cl advances quickly. It will be open sourced later, when the first prototypes will have been confronted with internal Google needs.
Meanwhile, GWT is now a mature tool. Version 2.8 will LTR (Long Time Release). There will be more changes, but only fixing bugs.
For GWT 3, the future is not yet decided. J2CL will certainly be independent from GWT. At the same time, nothing will prevent it to be integrated with GWT in the future. Google leaves that decision to the steering committee.
In short, everything is done for GWT remains a competitive product for the next ten years !
Where is GWT going ?
So that’s about it for the “official” information. Let us try to anticipate trends and guess what form will this project take in the coming years.
First, one can notice that programming in Java is still relevant (see TIOBE ranking last year). This is especially true for teams that also use Java on the backend (JEE server, for example), where having the same language on client and server can even have a social impact - developers are using the same language and have a common vocabulary and environment.
Producing rich applications (we do not speak of “to-do list” or form applications, but industrial applications) in the browser still has an interest, obviously. Both in terms of deployment, compatibility (the web runs on PC, Mac, Linux, Smartphones …) and in terms of technical scope offered by the platform (WebGL, access to gps, local storage, webcam, etc.).
Despite these still relevant points, some technical paradigms have evolved over the last ten years:
- modern browsers are now more standard and compatible, and we no longer need to have the homogenization layer that GWT gives (for another example, the interest of JQuery is no longer the integration of different browsers but a simplified presentation their API). The technical scope achieved without using compatibility layer is now wide enough for most applications. The web platform has become a de facto virtual machine (HTML5 rich APIs), and provided we do it in a good way, an application is able to run on both Mac, Windows, Linux, tablets and smartphones.
It is therefore natural that the place and role of technologies like GWT evolve too.
And this movement is accompanied by the announced removal of a large part of the foundations of GWT today.
So where do we go ?
How then anticipate a gradual migration (consistent with the future development of GWT which is not yet fully defined, if not uncertain) when we have a big code base to maintain? What are the challenges? Of course the goal is often not to stagnate on version 2.8 but to follow the development of the tool, as it provides new interresting features. In this spirit, we can see GWT 2.8 as a transitional version, to prepare ourselves for the future.
What will disappear
Let’s examine the parts of GWT doomed to extinction: generators, Widgets, GWT-RPC, UiBinder …
First, the generators can be migrated to the JSR-269. This represents a cost, and sometimes trade-offs, but it remains in the domain of the feasible. As for the other parts, let’s examine them one by one:
It is quite possible to migrate to another RPC layer. Indeed, the functional scope of GWT-RPC is relatively small (it generally boils down to generating stubs and proxy and takes the form of Java interfaces). Migration to the JSR-269 should be possible, dosing with carefully relationship between migration cost and complexity of the solution to mimic the exact GWT-RPC behavior.
There, the integration between the tool and the application code is much stronger, and the object oriented approach they provide is still helpful. Indeed, a GWT application often contains many classes that inherit or use
ComplexPanel or other
Widget. All these classes are based on the GWT widgets system which will disappear soon.
Two choices will certainly be possible: gradual transition to presentation tools such as
Angular (with JsInterop, Elemental and future automatic imports from definitely typed, integration of a presentation framework should easy enough), or to continue to develop the presentation layer in vanilla GWT, or by relying on libraries (which might manage the migration for you). Others who rely on libraries like GXT will have to wait for decisions taken by these tools.
What is the value of Widgets? An object-oriented view of the hierarchy of the DOM and therefore encapsulation for the DOM, some syntactic sugar, as well as a special management of events. Indeed, created at the time when browsers differed greatly in this respect, GWT provides a unified overlay to the native event management made by browsers. This overlay has now become entirely obsolete with the standardization of browsers.
The added value of Widgets hence is encapsulation and the object oriented approach (for those who love it). To be able to give a code localized in a class the responsibility for a part of the DOM hierarchy is very useful. The value of this may disappear with the domination of web-components, but for now the Web Components is does not bring much more to the practices of GWT developers (CSS encapsulation, object oriented development on the DOM) … The object oriented vision that provides the Widget system makes it very modular programming and assembly of heterogeneous software components easy.
On the other hand, a number of classes are becoming unnecessary as more and more functionalities are handled by the platform. For example, the class
TextBox to manage a single
<input/> element. The behavior of this tag is standard and advanced enough to rely on the native tag.
From all this, we can draw that to maintain an application one will have to make old Widgets and DOM elements interoperate (in both ways). And it will have to be efficient, fast and easy. Why not imagine writing a manipulation library of object-oriented DOM, x% compatible with Widgets, and based on JsInterop. This would provide both an integration layer and migration, and programming for the DOM object.
In terms of Widgets and managing DOM therefore, it is clear that the number of possibilities grows a lot ! Everyone will be able to choose its client application stack. And it is this question that will arise when creating new projects: what combination to choose? All in Java? Java + JS? Java + Typescript? Java + Coffee + C# + …? GWT-CSS or PostCSS, Less, SaSS? GWT + Angular, GWT + Meteor, GWT + + Redux React, React + GWT + Flux, …?
Regarding UiBinder, the problem is twofold: it is based on GWT generators and the Widgets. The generator part can also be worn to the JSR-269. As for the Widget part, it falls to the problem raised above. Migration therefore has a cost.
In summary changes are afoot for the tool and the developer’s habits. Today a GWT project is pretty standard (JEE backend, Widgets, RPC). But tomorrow nothing will prevent to integrate Java development with some Coffee (!), Typecript, d3.js and web UI components developed with dart. The build can be managed by gulp, development is done with Atom, WebStorm or VS Code. In a today GWT application, GWT is very central (all the code is written in Java for GWT and usually there is not much of JSNI). This might change and GWT will more and more integrate with other Web technologies.
GWT can also find its place in the mobile development where the issue is in the compilation to native targets such as mobile devices and perhaps even then the IOT: Java as a language, javac, GWT, Android SDK and J2ObjC as compiler to the Java platform, Web, Android and iOs. Inbox has in any case proved this model.
In short, the world is changing and GWT takes a major turn to ensure his place. Opening to standards is the spirit, and two keywords drive the GWT future : integration and performance.
Information collected by different sources: GWT Con 2015, websites, code …