Jusqu’à aujourd’hui, Google était le principal contributeur de cette technologie dont l’acronyme signifie « Google Web Toolkit ». L’an dernier, pour des raisons organisationnelles, le projet a été rapatrié au siège de Mountain View (alors qu’il était initialement piloté et développé à Atlanta). Ce changement a eu comme répercussion le départ de plusieurs contributeurs importants mais aussi l’arrivée de nouveaux talents, notamment de développeurs externes. Dans le même temps, GWT lui-même, il faut l’avouer, a pris de l’ampleur à l’extérieur de Google et a dépassé les prévisions les plus optimistes. De nombreuses entreprises (parmi les plus renommées) ont retenu cette technologie pour le développement d’applications (souvent stratégiques) Web ou mobile. La communauté a grossi, les contributeurs externes ont commencé à peser sur le projet.

En marge de cette situation, plusieurs voix se sont élevées pour poser la question de la pérennité, surtout avec les récents échecs de Google sur Buzz ou Wave. Cette sorte de floue dans lequel fût plongé la communauté avec d’un côté Google, moins en prise, et la communauté, plus insistante, a sûrement influencé la décision d’aujourd’hui. Google devait tôt ou tard décentraliser GWT pour qu’il puisse réellement s’émanciper. En créant un comité responsable de son développement, Gwit (le nom court du projet) n’appartient désormais plus officiellement à Google. Attention, la firme reste encore un contributeur majeur mais n’imposera plus sa vision à la communauté.

Ce comité constitué de plusieurs poids dont Google mais aussi RedHat, JetBrains (éditeur d’IntelliJ), Vaadin ou Sencha décidera du futur de GWT. Des changements ont dues être opérés sur la marque avec un nouveau logo (la modification de l’acronyme pour supprimer « Google » est en cours de discussion), l’hébergement et le système de soumission de patch (désormais plus ouvert). L’idée est clairement de rendre GWT plus transparent et plus efficace en termes de gouvernance. Des objectifs de visibilité ont été définis jusqu’en 2014 qui verra la release de la version 3.0. De nombreuses évolutions, améliorations ou corrections de bugs sont prévus à court, moyen ou long terme.

Attardons-nous un instant sur ces évolutions car c’est bien là tout l’intérêt de la technologie qui reste, malgré ce qu’on peut dire, une technologie de tout premier plan en 2013, notamment pour le développement d’applications métier.

Ouverture et simplicité

Comme évoqué précédemment, l’idée est d’ouvrir le projet à l’extérieur et d’utiliser des outils beaucoup plus performants d’un point de vue de la modularité. Concrètement, l’outil Maven sera utilisé pour gérer les dépendances (nombreuses) internes du projet. Un vrai travail titanesque entrepris il y a quelques temps par quelques contributeurs dont Thomas Broyer que Google a tenu a remercier pour sa ténacité (il faut vraiment comprendre le code interne de GWT pour s’apercevoir à quel point ce travail de déleiage a été fastidieux). D’un point de vue de la simplicité, tout le code déprécié sera définitivement supprimé du projet (on pense notamment à l’ancien système évènementiel).

Vitesse

La vitesse est le principal reproche fait à l’égard de GWT. Le compilateur est lent (ce qui s’explique d’ailleurs par les nombreuses optimisations réalisées sur le code JavaScript final) et le mode développement mérite quelques améliorations. Pour pallier à ces défauts, le compilateur sera optimisé pour gagner plus de 50% de temps, ce qui aura un impact sur le nouveau modèle de développement appelé SuperDevMode (ou SDM). Pour résumer, à terme, nous aurons la possibilité de développer et déboguer directement du JavaScript en passant par les débogueurs des navigateurs (comme le font actuellement les développeurs JavaScript) ou de coder (et déboguer) avec son IDE préféré. Une richesse incontestable.

Il est également envisagé d’améliorer la fragmentation de code JS (code Splitting), d’orienter le code compilé pour utiliser les spécificités des nouveaux navigateurs et des nouvelles machines virtuelles JS.

Interopérabilité

GWT s’appuie sur Java comme langage source. Or, dans la pratique, faire communiquer du Java et du JavaScript (en mode développement) est un vrai challenge technique (sans entrer dans les détails). Il existe plusieurs pistes pour rendre cette communication plus naturelle et surtout plus performante. L’idée est aussi de supporter des applications « hybrides » avec du mélange de Java et JavaScript (pour pouvoir réutiliser plus facilement des bibliothèques JS externes). Cette interopérabilité est aussi un frein lorsqu’il s’agit de maintenir les plugins GWT des différents navigateurs.

Enfin, dernier objectif et pas des moindres, le support de Java 7 et (c’est important) Java 8. Les nouveaux mots-clés, les lambda expressions et les nouvelles structures syntaxiques seront implémentées.

Fiabilité

La décision a été prise de fermer 100 des bugs les plus importants, ce qui est un effort de développement non négligeable. Cela passera aussi certainement par la dépréciation des navigateurs IE6 et IE7 qui alourdissent considérablement le code de GWT.

Packaging

L’idée est de casser le SDK en plusieurs modules avec des points d’extension possibles ici ou là. Aujourd’hui, gwt-user.jar est un fichier monolithique qui oblige le compilateur à parcourir d’innombrables classes, potentiellement non utilisées pour au final être supprimée de l’arbre syntaxique JavaScript final. Avec plusieurs « petits » JAR, la compilation sera plus performante et le code plus modulaire. Nous aurons également la possibilité de « sortir » des API telles que RequestFactory plus facilement.

Mobilité

La mobilité a clairement explosé ces trois dernières années. Cette multiplication des périphériques en tous genres est le terreau idéal pour GWT qui a été conçu à l’origine pour les performances et le support de plusieurs navigateurs. Pour aller dans ce sens, Daniel Kurka, le créateur de m-gwt (mobile gwt) a été engagé par Google pour développer cette intégration et réutiliser les bonnes recettes de m-gwt. Concrètement, cela signifie des permutations (les scripts JS générés) différentes avec des CSS différents, optimisés pour certains périphériques et générant du code JavaScript performant car compilé. L’objectif à terme est bien évidemment de développer une seule version de l’application HTML 5 en GWT qui s’exécutera sur tablettes, mobiles Android ou Apple avec les mêmes performances qu’une application native. L’accès aux ressources locales (Offline, Camera, GPS, Accéléromètre, …) étant possible grâce au packaging phone-gap (https://code.google.com/p/gwt-phonegap/ ) permettant de déployer une application GWT comme une application native (disponible sur Google Play, AppStore, etc …).

Conclusion

Il existe plusieurs cycles dans un projet de développement qui se veut pérenne. GWT est arrivé à la fin d’une ère et démarre un nouveau cycle. Cette session Google I/O officialise ce nouveau départ et apporte une réponse claire et sans équivoque aux questions que se posaient la communauté ces derniers temps. La réponse sur la pérennité est apportée par le comité constitué de nombreux acteurs, Google n’est plus seul à diriger. La transparence est apportée par le comité qui communique et s’engage sur une roadmap jusqu’au minimum 2014 avec la V3 en ligne de mire. Et enfin, les réponses sur la maintenabilité et les améliorations de l’existant sont apportées par le support des technologies futures (mobilité, navigateurs récents, mode développement, performance, …). GWT est né officiellement en 2006 et reste en 2013 plus que jamais une des technologies les plus adaptées au développement d’applications métier multi-périphériques.

Concernant le contenu, il est toujours très compliqué de creuser avec 45 min. Il y a souvent deux options dans ce cas de figure, traiter un aspect très spécifique d'une technologie en ouvrant Eclipse et en parcourant du code (c'est ce que j'ai fait avec le compilateur en 2007) ou montrer un cas concret d'application stratégique tout en énumérant les défis techniques. Vu le type d'audience de Devoxx et le nombre de clients nous demandant au quotidien " qui utilise GWT et comment ?", l'option REX (Retour d'expérience) nous semblait un bon moyen de faire connaitre la technologie.

J'animerai sûrement dans l'année des conférences ou séminaires plus pointues lors de la sortie de la seconde édition du livre, mais sachez que tout ce qui a été dit lors de cette session est un ressenti très personnel de l'équipe de développement. Que ce soit notre regard vis à vis de JavaScript, la productivité de notre environnement ou les choix technologiques du projet, nous ne voulons en aucun cas en faire un projet "référence", chaque client a ses contraintes et ses particularités. En revanche, nous voulions insister sur le fait qu'aujourd'hui, en 2012, de nombreux clients utilisent GWT dans leurs applications stratégiques. Ils en sont tout simplement satisfaits et viennent le dire à la tribune avec nous.

Un dernier mot sur l'organisation, j'avoue que je ne connaissais pas (assez) la marque Devoxx pour n'être jamais allé à la version Belge de l'évènement. Mais la version Française m'a définitivement convaincu que c'était un évènement majeur et surtout incontournable de la communauté Java. L'organisation a été (de mon point de vue) parfaite. Je remercie donc l'équipe Devoxx pour m'y avoir invité et je leur souhaite une longue vie. Pour avoir organisé 5 Symposium DNG (dont un au Mariott), le plus dur est de durer...