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

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 !

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.

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.

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 !

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.

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).

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…

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.

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.