Retour sur la conférence GWT.create 2015, la conférence dédiée à GWT

Les 27 et 28 janvier 2015 se déroulait à Munich la conférence GWT Create. Pour la deuxième fois, et pourtant avec déjà une odeur de rendez-vous annuel, les développeurs de GWT et ses utilisateurs ont pu se rencontrer, échanger et partager autour de ce fameux produit. Voici un résumé chronologique des sessions auxquelles j'ai pu assister, représentant la société LTE Consulting, experte sur GWT.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum 6 commentaires Donner une note à l'article (5).

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

GWT est un outil permettant de créer des applications Web avec le langage Java. Il est développé par Google et son code est disponible en open source. Son pilotage est assuré par un comité composé de membres issus de Google, Red Hat, Arc Bees, Sencha, Vaadin et autres. C'est un outil mature - présent sur le marché depuis 2006 - qui a énormément évolué techniquement depuis sa création. Récemment cet outil a été mis sous le feu des projecteurs avec la sortie de Google Inbox qui l'utilise, mais aussi avec Google Spreadsheets, Google Adword, etc. Ces annonces arrivent à point nommé pour redorer l'image de cet outil qui subissait un flot insistant de rumeurs de mort, alors que ses développeurs s'appliquaient à implémenter la vision de son futur.

GWT n'est pas mort ! Au contraire, les nombreux sujets abordés pendant la conférence montrent le dynamisme du projet et de la communauté gravitant autour. Il y a de nouveaux outils (Singular), de nombreuses améliorations apportées cette année (SuperDevMode et les futures fonctionnalités (support de Java 8, DeltaJS…).

Avec un peu plus de recul, GWT a aussi des choix à faire. En effet le contexte dans lequel il baignait à sa création a changé : les navigateurs sont plus performants et plus homogènes, la sortie de HTML5 a amplifié le champ des possibles, les Web Components promettent de changer les pratiques, et l'écosystème JavaScript est toujours plus grand. La programmation en Java et les nombreuses optimisations faites par le compilateur sont bien sûr toujours d'une valeur inestimable lors de la conception d'applications industrielles, mais certaines problématiques ont tout simplement évolué. Les navigateurs étant plus homogènes, la couche de compatibilité fournie par GWT devient obsolète. D'autre part, l'avènement programmé des Web Components combiné avec le nombre croissant de bibliothèques JavaScript disponibles rendront encore plus cruciale la facilité avec laquelle il sera possible de s'interfacer avec le langage JavaScript.

Alors oui, la version 3.0 de GWT apportera des changements cassant la rétrocompatibilité. Ce sera le prix à payer pour suivre l'évolution des technologies Web. En attendant, la version 2.7 sortie cette année et la 2.8 à venir nous permettent d'entrapercevoir la forme dans laquelle va se métamorphoser GWT.

M'étant rendu à cette conférence, je vais vous rapporter les éléments importants des sessions que j'ai pu suivre. Chaque session a aussi son article propre sur ce même blog. De toute façon, vous pourrez retrouver sur le site de la conférence les supports de présentation ainsi que les vidéos des sessions.

II. Les sessions

Voici la liste des sessions auxquelles j'ai pu assister :

  • keynote du premier jour ;
  • compilation incrémentale ;
  • singular ;
  • nouveautés du SuperDevMode ;
  • Google Inbox ;
  • keynote du deuxième jour ;
  • GWT et Xtend ;
  • RestyGWT et Jersey ;
  • CellWidgets en liberté ;
  • Panel GWT.

III. La keynote

La keynote a été présentée par Ray Cromwell. Cette année, GWT Create accueuille plus de 650 personnes, États-Unis et Europe confondus. 40 sessions ont été présentées.

III-A. Marketing : GWT change de logo et de page

Voilà c'est fait, le site de GWT change de visage, préférant un look plus moderne. Le logo aussi a été complètement revisité. Il est censé convoyer les notions de stabilité, d'expertise et de communauté. À vous de juger !

Image non disponible

III-B. Présentation des nouveautés et du futur de GWT

Cette année a été prolifique pour GWT.

  • Le SuperDevMode et l'intégration avec SourceMaps a beaucoup avancé. Le débogage dans Eclipse (ou IDEA) est maintenant possible grâce au plugin SDBG. Ceci redonne la main aux développeurs qui se sentaient perdus avec la perte du DevMode classique.
  • La compilation en mode développement est maintenant incrémentale, ce qui permet des temps de rafraichissement très réduits.
  • Toujours plus d'optimisations côté performances et taille des codes JavaScript générés par le compilateur.
  • Support de GSS (un less/sass à la mode Google), qui remplacera à terme les CssResource.
  • La nouvelle couche d'interopérabilité JsInterop a fait son apparition, permettant d'intégrer des bibliothèques JavaScript encore plus facilement qu'auparavant avec JSNI.
Image non disponible

Les avancées prévues l'année dernière ont donc bien pu être implémentées, la vision était bonne. Quant aux développements à venir pour la version 3.0, les voici :

  • introduction de changements « cassant » au niveau des API ;
  • intégration du langage Java en version 8. Cela va permettre entre autres d'utiliser les lambdas et donc de réduire le code glue nécessaire pour écrire des callbacks ;
  • JsInterop attaquera sa phase 2 ;
  • débogage : un outil développé en commun entre les équipes GWT et Chrome Dev Tools permettra d'afficher la structure logique des objets plutôt que les noms des variables internes générées par le compilateur (qui sont bien sûr souvent illisibles) ;
  • GWT va être découpé en plus petits modules ;
  • Elemental 2.0 : cet outil permettant d'être à jour avec les dernières API navigateur est réécrit de fond en comble. Elemental sera même étendu pour aller chercher dans les bases de données de typage de Type Script (Microsoft), afin de pouvoir intégrer n'importe quelle bibliothèque JavaScript en un coup de cuiller à pot, très prometteur ;
  • intégration de DeltaJS pour livrer les nouvelles versions des applications sous forme de patchs différentiels. Les Service Workers (une nouvelle API HTML 5) seront probablement mis à profit pour faire des mises à jour transparentes, et surtout pour délivrer un framework basique permettant d'exécuter nos applications sans connexion ;
  • des optimisations, encore et encore ! Améliorations des émulations du JRE, alignement avec les nouveaux paradigmes de ES6, etc. ;
  • les développeurs seront incités à abandonner les Widgets, au profit d'une programmation plus près du DOM.

III-C. Le Super Dev Mode

En ce qui concerne le Super Dev Mode, que s'est-il passé depuis l'année dernière, puisque la mort du Dev Mode classique oblige le SDM à devenir de qualité industrielle ? Justement c'est ce qu'il s'est passé. Le SuperDevMode encore peu mature l'année dernière, mal intégré avec les Chrome Dev Tools (une application avec quelques dizaines de Mo de JavaScript faisait planter Chrome), avec beaucoup de bogues sur Source Map, a beaucoup progressé.

À noter un travail intensif de collaboration entre les équipes GWT et Chrome Dev Tools a été mené, ce qui pour moi montre l'importance que Google donne à GWT. Les fichiers Source Maps générés sont environ 70 % plus petits que l'année dernière. Et on peut noter aussi qu'en interne chez Google, toutes les équipes sont passées au SuperDevMode, ce qui prouve bien son industrialisation.

L'autre grosse nouveauté pour le SuperDevMode est la possibilité de déboguer son application directement dans l'IDE et non pas en passant par les Chrome Dev Tools, qui sont très bien au demeurant, mais très limités si on compare à Eclipse ou IntelliJ. Ceci est donc une très bonne nouvelle. La seule limitation est que le débogage n'est possible qu'avec un navigateur Chrome, Firefox et Internet Explorer n'étant pas encore pris en charge (ceux-ci supportant pourtant Source Maps sans problème). Les API de débogage des navigateurs ne sont en effet pas homogènes, ce qui oblige à dupliquer les connecteurs. Donc nous sommes plutôt dans un problème de temps avant d'y arriver, plutôt que sur des difficultés et inconnues techniques.

Tout ceci prend donc une très bonne voie, et pour ma part, je conseille à tous ceux qui ne l'ont pas encore fait de passer à GWT 2.7 + le plugin SDBG (pour Eclipse) ou IntelliJ (avec les fonctionnalités GWT) pour expérimenter le nouveau flow de développement, qui révolutionne l'ancien DevMode !

III-D. La compilation incrémentale

Détaillons un petit peu plus les avancées faites sur ce sujet. Une session de John Stalcup y a été entièrement consacrée. Tout d'abord, rappelons le principe de la compilation incrémentale. Lors de la compilation classique, le temps que prend le compilateur à compiler votre application est fonction de la taille des sources utilisées dans votre application. En effet, plus votre application contiendra de source, plus la compilation sera longue. Et justement comme GWT est principalement destiné à écrire des grosses applications, le serpent se mord la queue et nous nous retrouvons souvent avec des compilations prenant plus de cinq minutes.

L'idée de la compilation incrémentale est de rendre le temps de compilation non pas fonction de la taille des sources de l'application, mais plutôt fonction de la taille des changements dans les sources depuis la dernière compilation. Et c'est dans ce sens qu'a évolué le compilateur GWT depuis l'année dernière. C'est un chemin qui avait été défini de longue date, mais évidemment il faut réviser entièrement l'architecture du compilateur et ce n'est pas une tâche aisée.

Un « proof of concept » avait été montré l'année dernière, mais il était largement immature, encore inefficace. Mais surtout cela a permis de défricher le terrain afin de soulever les inconnues liées à l'évolution du compilateur dans ce sens. Grâce aux efforts fournis par l'équipe GWT cette année, d'énormes progrès ont été réalisés. En effet, pour des applications réelles, le gain apporté par la compilation incrémentale va de 5 à 15 par rapport à l'ancien Super Dev Mode. Tandis que les temps de chargement des applications sont eux aussi réduits (en général 3 à 4 fois plus rapides).

Pour l'histoire, l'équipe a dû changer plusieurs fois de stratégie pendant l'élaboration de la nouvelle architecture. Visant au départ à fractionner la compilation par bibliothèque ou carrément par fichier, cette stratégie s'est révélée trop compliquée pour gérer les dépendances au sein d'un projet. Même si compiler de façon indépendante les différentes parties d'une application semblait au départ une bonne idée, il s'est révélé qu'il était très pratique d'avoir un compilateur connaissant l'ensemble complet des dépendances du code d'une application, de façon justement à pouvoir calculer l'impact de changements dans une partie sur les autres. Le compilateur prend donc connaissance dans une première phase de travail de l'ensemble des dépendances de l'application pour ensuite passer à un mode « par classe » au fur et à mesure des compilations incrémentales.

Finalement, la première compilation (lors du lancement du SuperDevMode) est encore un peu longue (quoique des améliorations déjà implémentées, mais pas encore publiées sont d'ores et déjà capables de diviser par deux le temps de cette compilation initiale). Par contre, la recompilation après avoir apporté quelques changements au code est quasi instantanée dans la plupart des cas (je confirme, ndlr). Ceci va être une révolution pour les développeurs GWT habitués à un DevMode couteux en mémoire et très lent ! Si vous voulez déjà bénéficier d'une partie de ces améliorations, je vous conseille vivement de passer à GWT 2.7 !

Reste encore un problème de taille : les générateurs. Ceux-ci pénalisent en effet le temps de recompilation, car le concept « incrémental » n'avait pas du tout été préparé au moment de l'écriture des interfaces entre les générateurs et le compilateur. Notamment, un générateur n'a pas la possibilité de spécifier ses dépendances au compilateur et donc un tas d'astuces ont été mises en place dans le compilateur pour essayer de « deviner » au mieux ces dépendances afin de ne refaire tourner un générateur que lorsque c'est nécessaire. On peut noter quand même l'apparition d'une nouvelle classe permettant à un générateur de spécifier plus de choses au compilateur. Mais qui a envie de réécrire tous ses générateurs ?

Quant à l'avenir de la compilation incrémentale, ce ne sont pas les idées qui manquent : déplacer le mécanisme des générateurs vers le build system plutôt que dans le compilateur afin de limiter les problèmes cités plus haut, revenir à la compilation par bibliothèque (ce qui améliorerait les temps de compilation d'applications réutilisant ces bibliothèques), une plus grande intégration avec Closure pour générer du code JS encore plus optimisé… D'autres idées (plus risquées pour l'instant) aussi : avoir une sorte de class loader GWT pour charger du code dynamiquement dans la page, cache d'application automatique et mises à jour delta grâce aux Service Workers, généralisation du compilateur SDM à un serveur de compilation plus générique.

III-E. Le framework Singular

Ce nouveau framework présenté par Daniel Kurka pourra vous intéresser, car il est destiné à :

  • permettre la génération d'applications hybrides, c'est-à-dire que pour un même code en entrée, il est possible d'obtenir : une application Web classique, une application native Android, une application native iOS ;
  • intégrer un mécanisme de data binding bidirectionnel à la façon d'Angular, mais sans ses désavantages (pour faire court Angular devient très lent à mesure que l'application grossit). En gros, l'idée de Singular est de faire un maximum de travail à la compilation de façon à produire un code très efficace à l'exécution (pas de timers pour le dirty-checking par exemple).
Image non disponible

Daniel nous a même fait une démonstration de son produit (qui devrait sortir officiellement d'ici quelques semaines d'après lui). C'est très sympathique : le développeur écrit sa logique applicative indépendamment de la plateforme, puis écrit ses vues spécifiquement pour chaque plateforme, Singular gérant la liaison entre les deux parties.

Singular intègre une partie de PhoneGap pour délivrer une API unifiée pour toutes les plateformes prises en charge (Web, Android et iOS). Donc à terme j'imagine une bibliothèque de vues associée avec le look « material design ».

Le bilan est celui-ci : Singular permet de gagner en productivité, car la logique applicative n'est codée qu'une seule fois. Les applications compilées avec Singular sont d'autre part très efficaces, car en version native sur les plateformes mobiles.

Même si ce framework est tout jeune (il n'est même pas sorti d'ailleurs !), les concepts qu'il embarque sont très inintéressants. À surveiller…

III-F. Google Inbox

Cette année, Google a fait grand bruit dans le monde GWT avec la sortie d'Inbox. Cette application a en effet servi de laboratoire pour établir un modèle de production d'applications hybrides. Par hybride, on entend que la même application Web peut être compilée dans une version native pour les plateformes mobiles.

En gros cette session raconte les problématiques qu'ont amenées le développement de cette application et les réponses qui ont été trouvées. Voici les points clés de cette architecture.

  • La partie logique applicative est codée en Java et est partagée par toutes les plateformes cibles.
  • L'application Web est codée avec des vues Web et générée avec GWT.
  • L'application Android est codée avec des vues Android et générée avec javac + dex.
  • L'application iOS est codée avec des vues iOS natives, la logique applicative est transpilée en Objective C grâce à J2ObjC, puis l'ensemble est compilé avec les outils iOS.

En conclusion, même si cette approche est certainement plus lourde qu'écrire simplement une application Web éventuellement wrappée pour les plateformes mobiles, l'approche permet de conserver du code commun entre les plateformes et surtout de conserver de bonnes performances sur les mobiles, tout en restant isofonctionnel. Cette lourdeur (écrire trois fois les vues) doit donc être justifiée. Pour Ray, une des plus grandes utilités de ce genre de pratique est de pouvoir embarquer des bibliothèques complexes qui devraient être portées pour chaque plateforme sinon. Il cite quelques-unes de ces bibliothèques qui sont utilisées dans les produits Google et dont la réécriture (en Objective C par exemple) aurait été une énorme problématique :

  • transformations opérationnelles (utilisées dans Google Spreadsheets) ;
  • calcul de formules (Google Spreadsheets) ;
  • mécanismes de synchronisation ;
  • cryptographie, Codecs, etc.

Pour autant le framework mis en place pour Spreadsheets et Inbox n'est pas vraiment industrialisé, donc pas de sortie grand public prévue pour le moment.

III-G. Le panel GWT

La dernière session de la conférence réunit les membres du comité de pilotage de GWT devant l'assemblée qui pose ses questions à volonté. Au menu des questions : trouver un argumentaire vendeur pour GWT, la qualité de la branche master du dépôt, le futur des Widgets, la tendance à programmer sur le DOM directement, les outils de build et l'interaction entre la communauté et les développeurs.

IV. Conclusion

Cette année encore GWT Create fut une conférence passionnante. Elle permet de consolider sa vision sur cette technologie et d'appréhender ses futurs axes de développement et donc de garder dans ses projets industriels une cohérence avec son futur. Mais surtout, c'est un lieu de rencontre où l'on peut échanger sur ses pratiques, et échanger tout court.

Cet article a été publié avec l'aimable autorisation de la société LTE ConsultingLTE Consulting.

Nous tenons à remercier Claude Leloup pour sa relecture attentive de cet article et Mickaël Baron pour la mise au gabarit.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2014 Arnaud Tournier. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.