Retour du Google IO 2013 vers le futur de GWT

Nouveau logo de GWT

La semaine dernière, du 15 au 17 mai 2013, se tenait la conférence Google I/O consacrée aux technologies Google, rassemblant des milliers de développeurs passionnés du monde entier. Deux sessions parlaient de GWT. La première, présentée par +Ray Cromwell (un googler qui a entre autres très activement participé au développement du compilateur GWT) et +Daniel Kurka (le créateur de mgwt et gwt-phonegap) présentait le carnet de route de GWT et c’est sur celle-ci que nous allons nous attarder. La seconde, animée par +Erik Kuefler, s’intitulait « Démystifier le pattern de développement MVP et le bus d’événements dans GWT », pattern dont l’objectif est de  proposer aux utilisateurs d’applications de type SPA (Single Page Application) une expérience web classique en terme de navigation.

La raison pour laquelle j’écris ce billet est que cette session sur le futur de GWT me permets de compléter un article que j’avais écrit l’année dernière. Cet article essayait de démontrer la pertinence de d’utilisation de cette technologie en milieu industriel malgré les doutes de la communauté sur sa pérennité.

Ce qui s'est passé depuis l'année dernière

Que peut-on retenir de la présentation de Ray Cromwell ? Tout d’abord un point sur ce qui s’est passé depuis la session à Google I/O 2012 :

• La mise à disposition du code source complet de GWT sur GitHub dans le but de mobiliser de façon plus importante la communauté des développeurs et de faciliter la participation au développement de GWT aux personnes motivées,
• La mise en place d'un nouveau système de revue de code basé sur Gerrit,
• Le portage du site de GWT hors du domaine de Google, Google ayant remis le projet à la communauté (ceci avait provoqué de nombreuses rumeurs sur la mort de GWT, vous verrez par la suite qu’il n’en est rien – tout au contraire car c'est pour mieux prendre en charge les besoins de la communauté dans sa globalité et non les seuls besoins de Google en interne qu'a été initié ce mouvement),
• L’implication de RedHat dans le développement de GWT. On peut noter principalement leur engagement à héberger par l'intermédiaire de leur infrastructure Open Shift le service d’intégration continue du framework  – ceux qui aiment voir de grosses entreprises présentes sur une technologie avant de l’utiliser se sentiront à l'aise,
• Un autre nouveau venu dans le comité de pilotage, et non des moindres : JetBrains. Une meilleur prise en charge de GWT dans IntelliJ est donc à anticiper. Apparemment Google et JetBrains s’entendent bien en ce moment (voir la sortie d’Android Studio, développé par Google sur la base d’IntelliJ !)

Depuis l’année dernière, peu de changements majeurs ont été apportés à GWT techniquement parlant, le point de focalisation étant la mise en place et le nouveau fonctionnement du comité de pilotage. Nous les développeurs n’avons pas été à plaindre, le cœur du framework étant très stable et mature, les projets clients peuvent toujours s’appuyer sur la version courante (GWT 2.5.1).

Le futur

Maintenant, couvrons le thème du futur de GWT, qui était le thème majeur de cette présentation. Voici les principes directeurs des futurs développements sur lesquels se sont accordés les membres du comité de pilotage :

• Ouverture et simplicité (facilité à contribuer au projet pour des développeurs externes, les membres du comité étant autorisés à committer directement, et transparence dans la gestion du code source),
• Rapidité (compilation et exécution),
• Interopérabilité,
• Fiabilité (bug fix),
• Intégration (avec d’autres outils),
• Mobilité (phonegap et mgwt font partie du comité).

Ouverture et simplicité : en ce qui concerne l’ouverture il s’agit là de terminer le transfert vers la communauté open source principalement en rendant les meetings du comité de pilotage publics et réguliers. On facilitera aussi la participation de la communauté (avec la présence du code sur GitHub).
Au fur et à mesure de son développement, le code de GWT est devenu un délicieux plat de spaghettis, ce qui est du à la richesse de cet outil, à l’activité frénétique que les développeurs lui ont consacré et à l’intégration de multiples bibliothèques patchées pour diverses raisons (à titre d’exemple, le serveur de développement intègre du code de Jetty, parfois d’apache commons, etc).
Ce phénomène peut devenir dangereux s’il n’est pas maitrisé. Le comité de GWT en a tout-à-fait conscience et a démarré (par l’action de Thomas Broyer) la « mavenisation » du projet. Mais pourquoi cette mavenisation ? L’intérêt de ce processus est de permettre la mise à plat des dépendances (parfois cycliques) entre les différentes parties du code de GWT ainsi que ses dépendances aux outils utilisés pour implémenter GWT, je citais Jetty tout à l’heure, mais il y en a d’autres. En fait ceci permet de rationaliser l’ensemble du code source, et c’est très bien. Quiconque télécharge et chine dans le code de GWT se rendra compte très vite de la nécessité de ce travail. D'autre part ce processus modularisera le code et permettra de réduire le temps de compilation dans les cas où seulement un sous-ensemble modules sont utilisés.

Rapidité. Après, ou en parallèle de ce processus, un thème récurrent a toujours été la lenteur de compilation avec GWT. Celle-ci sera donc encore une fois un axe important d’amélioration. L’objectif est  ici de doubler les performances de la compilation. Mais aussi d’améliorer le SuperDevMode, une technique s’appuyant sur SourceMap qui permet de compiler à la volée en mode très rapide (draft) votre code pour l'injecter dans le navigateur directement en javascript avec les informations de debuggage qui permettent de voir le code source en Java dans le navigateur (mais pas le contenu des champs des objets :( - du moins pour l’instant, et c’est une des lacunes de SourceMap). Ceci permet d’éviter pour supporter le mode développement GWT la maintenance des plugins de développements (un pour Chrome, un pour FireFox et un pour Internet Explorer) et également d’éviter les allers retours réseau entre le plugin du navigateur et la JVM donc d’améliorer les performances du mode de développement. En gros donc, à terme : plus de plugin à installer sur son navigateur pour le mode dev de GWT, mais tout se passera dans le navigateur ! Et avec une recompilation du code Java en Javascript beaucoup plus rapide !

Ray a aussi cité la piste de la génération d’un code Javascript plus en phase avec les machines virtuelles Javascript modernes. Le compilateur GWT ayant été développé avant même la sortie de V8 par exemple, il faudra prendre le temps de réaliser une investigation afin de peut-être revoir le code généré. Peut-on y voir aussi un signe de l’intégration de la technologie ASM.JS qui est en train de faire un gros carton en termes de performances sur firefox, notemment avec Emscripten ? Nous verrons bien (attention ce propos n'engage que moi et des débats sur ce sujet existent). En tout cas ce travail présente un gros potentiel pour l’amélioration des performances du code compilé. Le projet GWT émanant à son origine de Google, nous sommes de toute façon déjà très contents de l’efficacité du code JS généré aujourd’hui. Nous savons bien que pour Google, chaque milliseconde compte !

En ce qui concerne l’Interopérabilité, outre le support complet des nouveaux Java 7 et 8 (Ray promet l'utilisation des lambdas à l'instant même où Eclipse publiera son ECJ/JDT pour Java 8), un effort va être fait pour faciliter l’échange entre le monde Java-GWT et le monde JavaScript. Il s’agit de simplifier la syntaxe JSNI et de mettre en place des outils permettant l'intégration automatique de code Java <=> Javascript, car GWT on le sait interopère déjà sans problème avec le monde JavaScript.

En termes de Fiabilité, nous retiendrons principalement que les navigateurs Internet Explorer dans sa version 6 (au moins) devraient être retirés de la couche de compatibilité du projet. Une façon de dire aux décideurs IT : « si vous voulez profiter de la dernière version de GWT 3, soyez prêts à lâcher IE6 ! ». Sur un plan plus technique, cela permettra aux développeurs de GWT de s’affranchir d’une lourde dette technique qui met un frein notamment au développement de widgets destinés aux plateformes mobiles. Outre ce point, Ray mentionne l’objectif de fixer les 100 bugs les plus importants du framework. Ne nous attardons pas dessus, mais GWTUnit devrait aussi se voir amélioré.

Intégration. Toujours dans la ligne qui consiste à simplifier la structure du code de GWT, le projet devrait être découpé en plus petits modules, avec l’adjonction de plusieurs points d’entrée destinés à faciliter l’intégration de GWT avec d’autres outils. Une des raisons à cette ambition est de faciliter l’intégration de GWT dans  des produits industriels s’appuyant sur le cœur de GWT (Vaadin, JBoss ERRAI).

Sur le plan de la Mobilité (et à ce moment, Daniel Kurka entre en action), il est évident qu’il n’est plus possible aujourd’hui de parler de développement Web en évinçant les terminaux mobiles. Et le comité de pilotage de GWT l’a bien compris puisque l’accent va être mis aussi sur l’optimisation de GWT pour le Web mobile : support des navigateurs mobiles, applications hors-ligne, widgets optimisés pour mobile, déploiement sur des plateformes de distribution d’applications mobiles (Apple Store par exemple !), etc. Tout ceci avec l’idée sous-jacente que la prise en compte des contraintes des terminaux mobiles est essentielle : les CPU ne sont pas aussi rapides que ceux des machines desktop, les applications mobiles sont dépendantes de leur consommation en électricité puisque les batteries de nos smartphones se déchargent assez rapidement, et puis malgré la couverture des réseaux mobiles modernes sur nos  territoires (3G ou 4G) les débits sont forts différents de ceux que l’on peut obtenir avec une connexion de type ADSL. Il faudra prendre tout cela en compte, et c’est prévu. L’avantage de GWT sur ces points est que lors de la compilation d’un projet écrit pour GWT, toutes les ressources de l’application sont connues et peuvent donc être optimisées au maximum.
A titre d’exemple prenons les animations graphiques : il est prévu que l’ensemble de celles-ci soient décrites en CSS par le compilateur GWT, ce qui permettra aux navigateurs mobiles de les faire exécuter sur le GPU, par le biais de leur moteur CSS au contraire de certaines bibliothèques qui exécutent les animations en Javascript.

On peut noter que les bibliothèques mgwt et gwt-phonegap permettent d’ores et déjà de prendre en charge les terminaux mobiles en répliquant un graphique « natif » et en permettant l’accès aux fonctionnalités natives de ces plateformes.

Pour couronner le tout, on nous présente la migration et refonte du site GWT qui sort du domaine Google. Vous le trouverez à l’adresse suivante : http://www.gwtproject.org (au passage, ce site est une application GWT).

En ce qui concerne les livraisons des nouvelles versions, nous allons avoir des nouvelles révisions mineures tous les six mois et des livraisons majeures tous les ans. Ray remercie chaleureusement +Thomas Broyer pour le nombre incroyable de bug fix qu'il a apporté cette dernière année.

Conclusion

En résumé, ce fût une très belle session que nous proposa notre cher Ray Cromwell (comme à son habitude) et son acolyte Daniel Kurka. Ceux qui suivaient déjà les activités du comité de pilotage ont reçu la confirmation de ce qu’ils attendaient. Et ceux qui doutaient de l’avenir de cette technologie se verront rassurés : l’avenir est brillant et les axes dans lesquels s’engagent les développements futurs de GWT sont en adéquation avec le sondage qu’avait effectué le comité auprès des utilisateurs de cette technologie.

Pour terminer, outre mon envie de communiquer ma grande joie suite à cette présentation, je me contenterai de relayer le mot d’ordre : « Start contributing ! »

Post-Scriptum :
- Si vous souhaitez voir un article plus détaillé sur le sujet, je vous recommande vivement celui de notre grand expert et spécialiste français sur GWT, j’ai cité +Sami Jaber. Voici le lien.
- Merci à +Thomas Broyer pour ses commentaires qui m'ont permis d'affiner ce post.