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

Pendant la conférence invitée, +Joonas Lehtinen nous apprend que cette conférence connait un véritable succès (quelque peu inattendu en fait). Deux cent onze personnes étaient présentes à San Francisco (la conférence s'est aussi tenue aux États-Unis deux semaines plus tôt, avec plus ou moins les mêmes intervenants). Pour cet opus européen, ce sont 435 personnes qui se sont retrouvées au Radisson Blu Hotel pendant deux jours.

Puis, toujours pendant la conférence invitée, +Ray Cromwell prend la main. La communauté des utilisateurs de GWT est estimée à 100 000 développeurs. Cette estimation est bien sûr quelque peu grossière, mais donne à penser que GWT connait toujours un franc succès parmi les développeurs d'application Web.

Les sorties de GWT devraient maintenant être régulées au rythme d'une version majeure par an et plusieurs versions intermédiaires pendant la même période.

Depuis la création de GWT en 2006, la réalité des navigateurs a bien changé. Ceux-ci sont maintenant bien plus capables et rapides. On constate moins d'incompatibilités entre ceux-ci. Les applications mobiles sont influencées par leurs équivalentes natives. Avec le WebGL, les Typed Array ont fait leur apparition. De nouveaux paradigmes ont vu le jour (Scoped CSS, Shadow DOM…).

Ces évolutions auront bien sûr un impact fort sur le framework GWT. Celui-ci a été inventé initialement pour fournir au développeur un environnement de programmation homogène et indépendant du navigateur. Aujourd'hui, il va de plus en plus s'agir de fournir un environnement de plus en plus confortable. Bien sûr les performances ont toujours été un objectif très important dans la conception de GWT et vont continuer à l'être.

Puis Ray explique le contenu et la philosophie de la future nouvelle version majeure de GWT, la 3. L'année 2014 sera bien sûr marquée par la sortie de Java 8 et ses très attendues expressions lambda. Le compilateur GWT est d'ores et déjà prêt et attend que le compilateur Java d'Eclipse (JDT) le soit également pour intégrer complètement les lambdas.

Outre cette nouvelle, d'autres évolutions sont prévues pour la version 3. Tout d'abord la couche JSNI sera refondue pour s'appeler JSInterop et faciliter l'interopérabilité entre code Java et JavaScript. Celle-ci se fera avec beaucoup moins de code « glue ». D'autre part, GWT se prépare à accueillir les Web Components comme il se doit. Daniel Kurka nous détaillera tout cela pendant sa session « Le futur de GWT ». Une autre préoccupation de l'équipe est l'amélioration du mécanisme de Code Splitting. L'objectif est de réduire drastiquement la taille des fragments « left-over ».

Une grande attention sera ensuite donnée afin améliorer le code JavaScript généré par GWT. En effet, avec l'évolution des VM des navigateurs, le JavaScript généré n'est parfois pas optimal et parfois même empêche la VM de procéder à certaines optimisations. Un coup de refactoring est donc prévu dans ce sens.

Le modèle de placement CSS Flex Box doit aussi être pris en charge. Le CSS3 sera bien mieux intégré, grâce aux GSSResource (voir la présentation à ce sujet de +Julien Dramaix et +Daniel Kurka).

Et puis la nouveauté qui fait peur à tous les développeurs : le nouveau mode de développement Super Dev Mode. Depuis ses débuts le mode dev avec son plugin à installer dans le navigateur pose des difficultés de maintenance pour l'équipe qui le développe. En effet, le plugin étant écrit en code natif, il faut s'interfacer avec le navigateur. Et ceci se fait avec des API différentes pour Chrome, Firefox et Internet Explorer. Évidemment, maintenir trois codes différents est plus difficile qu'un seul. Mais ce n'est pas la raison de fond qui oblige GWT à passer à un nouveau mode de développement. L'API utilisée pour interfacer le plugin GWT avec Chrome se nomme NPAPI. C'est une vieille API, créée par Netscape à la belle époque. Et Google veut absolument et pour diverses raisons se débarrasser de cette couche logicielle (Chrome propose un équivalent nommé Nacl). Du coup, GWT n'a plus d'autre choix que d'abandonner cette façon d'aborder le mode dev pour la substituer par ledit Super Dev Mode.

En soi Super Dev Mode est une approche tout à fait viable. Mais la plupart des développeurs lui reprochent son manque de maturité quand il s'agit de déboguer une application. En effet, le débogage se passe maintenant dans le navigateur (jusqu'ici tout va bien) en s'appuyant sur Source Maps pour afficher le code Java correspondant au JavaScript en cours de débogage. Le problème est que dans ce mode, on ne peut pas inspecter les valeurs de nos champs Java… Retour au débogage en mode window.alert() ? Non certainement pas, les développeurs de GWT en charge du Super Dev Mode (en fait le développeur : +Brian Slesinsky) travaillent d'arrache-pied pour pallier ce problème. À suivre donc…

À la fin de la key note, +Daniel Kurka nous présente les différents exposés qui prendront place pendant ces deux jours. Maintenant tout le monde se dirige vers les sessions de leur choix. Il y a en général deux sessions en même temps, plus des workshops sur différents sujets. Il va donc falloir faire un choix !

Cette session était présentée par +Christian Goudreau.

Je suis allé à cette session dans l'objectif de peut-être découvrir des utilisations des générateurs que je ne connaissais pas. Bien sûr j'en ai déjà écrit pas mal, mais à tout hasard je me suis dit que j'apprendrais sûrement quelque chose. Et cette session m'a finalement beaucoup déçu. Tout d'abord l'orateur semblait faire sa présentation pour la première fois (avait-il oublié de répéter ?). Trop d'hésitations, de confusion. Pourtant nous avons devant nous un des membres du steering comitee, président la société Arc Bees.

Le contenu est léger, on nous dit que les générateurs permettent d'augmenter la productivité, de bénéficier d'un code plus propre (la génération du code « boiler-plate » étant laissée aux soins des générateurs), et de résoudre des problèmes récurrents. Puis Christian Goudreau nous fait la pub pour sa technique de templating de code.

Outre la mauvaise qualité du présentateur, dans le fond cette session n'a pas apporté de profondeur non plus. Tant pis !

Cette session était présentée par Ray Cromwell.

Le but de la session de Ray est de donner des connaissances de base sur le compilateur GWT, dans l'idée de motiver le plus de personnes possible à venir y contribuer.

La compilation se fait en trois étapes : la précompilation et les optimisations appliquées au code Java, la compilation en JavaScript et enfin l'édition de liens.

La précompilation se fait à partir de l'arbre de syntaxe abstraite générée par le socle Eclipse JDT. Le compilateur GWT absorbe cette structure qui permet non seulement de parcourir la structure du code Java, mais aussi son contenu (chaque instruction est accessible et modifiable). C'est à partir de cet arbre que le compilateur fonctionne et va exécuter plusieurs passes d'optimisation (Pruner, Type Tightener, Finalizer, Dead code removal, Inlining, etc.).

Puis a lieu une étape de normalisation qui permet - et c'est justement un des points forts de GWT - d'utiliser JavaScript afin de reproduire la sémantique Java (émulation des types Long, dévirtualisation des JSO, traitement des casts, etc.).

À la fin de cette étape, le compilateur ne travaille plus sur l'arbre Java, mais sur le JavaScript, qui a été généré à la phase précédente. Les optimisations y sont toujours présentes bien que moins nombreuses.

Vient ensuite la gestion du Code Splitting.

Et enfin, l'édition de liens a lieu. Au passage, Ray mentionne qu'en interne à Google, les développeurs ont créé un autre linker que celui livré par défaut avec GWT. Ce qui permet aux applications d'éviter un aller-retour réseau pour bootstrapper l'application. Avec le linker normal, le script « nocache » est d'abord chargé. Celui-ci a pour principal rôle de détecter la version du navigateur, de façon a lancer le chargement de la bonne permutation. Et bien le linker de Google gère la détection du navigateur côté serveur (avec le header User-Agent) et envoie directement la bonne permutation.

Cette session fut très bien menée (on connait Ray Cromwell qui est un très bon orateur) et très intéressante. C'est le genre d'informations que vous retrouverez dans les formations de DNG Consulting.

Cette session était présentée par +Colin Alworth de Sencha.

Cette session nous présente le pattern apparence, utilisé sans réserve dans le framework GXT de Sencha. Quiconque a déjà utilisé GXT a probablement dû rentrer à un moment ou un autre dans son code source. Et force est de constater que ce pattern est utilisé partout !

En gros, le pattern apparence permet de déléguer à une implémentation la gestion du rendu, de la mise à jour de contenu, de la recherche de l'élément auquel il faut donner le focus et de l'état des fragments HTML sur lesquels travaillent les CellWidgets de GXT. Outre la délégation de ces aspects, ce pattern est censé permettre de facilement mettre en œuvre la personnalisation des thèmes graphiques (bizarre alors, quand on sait qu'il est infiniment difficile de changer la moindre couleur aux thèmes GXT).

Notre orateur élargit ensuite son propos pour nous montrer la technique de génération de thèmes de GXT. C'est assez usinesque, mais efficace. L'équipe prépare pour les futures releases de GXT un générateur automatique de thème (comme quoi l'équipe a bien compris que c'est un besoin récurrent chez les utilisateurs de GXT). L'utilisateur décrit ses couleurs et formes préférées dans un fichier au format particulier, puis exécute l'outil. Celui-ci génère les feuilles de style pour tous les navigateurs. La difficulté vient du support des navigateurs ne prenant pas en charge par exemple les coins arrondis. L'outil pilote un navigateur moderne et fait tout seul des captures d'écran pour ensuite les découper et les injecter dans les vieux navigateurs afin d'obtenir un rendu homogène sur toutes les plateformes. Pas mal non ?

Cette session nous a fait la démonstration d'un pattern intéressant à mettre en place, car il permet de séparer le contenu d'un widget de son comportement, tout en rendant ce contenu personnalisable à souhait. Ceci en gardant les performances au cœur des préoccupations. D'autant plus qu'en mettant en place ce pattern, le code n'est pas trop complexifié non plus… Vous souhaitez plus de détails ? Je vous invite à vous plonger dans les sources de GXT !

Cette session était présentée par +Daniel Kurka.

Note : cette session devait initialement être présentée par +Goktug Gokdogan qui n'a malheureusement pas pu se rendre à Francfort. Daniel Kurka prend la relève et nous donne ici plus de détails sur la future version 3 de GWT.

Tout d'abord vient le support des Web Components. Et sur ce thème, on commence par les Custom Elements. Il sera possible avec ces Web Components de définir des nouveaux tags HTML réutilisables. Comment alors intégrer ce paradigme dans GWT quand la classe DOM est définie à la compilation, et donc non extensible au runtime ? Et bien GWT 3 aura sa réponse (voir les slides pour plus de détails).

Daniel nous conseille de voir la présentation d'Eric Bidelman au Google I/O 2013. Après l'avoir vue, je ne peux que vous conseiller la même chose !

On nous fait ensuite la démonstration du prochain JSInterop, future implémentation de la couche d'interopérabilité avec JavaScript. En gros cela nous permettra d'économiser de nombreuses lignes de code pour wrapper de simples fonctions JavaScript. Ceci sera fait par l'intermédiaire de l'annotation @JsExport. Il est conseillé à ce stade d'aller consulter la spécification en cours de cette nouvelle couche. Entre autres, nous aurons également droit à une nouvelle méthode GWT.jsni(…) pour exécuter du JavaScript sans avoir à déclarer de méthode finale native.

La partie suivante de la présentation est consacrée à la refonte du système de widgets, baptisée naturellement Widget 2.0. Une démonstration impressionnante est disponible à cette adresse. Pour résumer simplement, on peut dire que la façon de programmer les widgets va s'éloigner du modèle à la Swing pour se rapprocher du paradigme des Web Components. Ceci va sans doute poser des difficultés aux développeurs, mais apportera la puissance des Web Components dans GWT, ce qui selon Daniel Kurka est indispensable pour que ce projet continue à vivre et à être utilisé. Les applications Web seront de plus en plus hybrides (de GWT, du JavaScript, du emscripten, utilisation de multiples frameworks, etc.), une osmose entre Java et JavaScript sera donc indispensable pour développer avec la plus grande productivité possible. En tout cas, à l'écoute des nombreux applaudissements qui ont suivi cette présentation, on peut dire que toutes ces nouveautés ont été très bien accueillies et sont attendues impatiemment (c'est également mon cas ;)).

Cette session était présentée par Manuel Moñino et +Julien Dramaix.

J'utilise de temps en temps GQuery dans mes projets, car il permet rapidement de transformer l'arbre du DOM. C'est un portage de JQuery pour GWT (donc le typage est toujours bien présent, les optimisations aussi, résultat il est souvent plus rapide et léger que son homologue JavaScript). L'argument principal des présentateurs est que la programmation des widgets est parfois lourde bien qu'ils ne soient effectivement utilisés que pour l'abonnement aux événements. GQuery permet donc de s'abonner aux événements sur des nœuds DOM sans pour autant avoir à créer d'innombrables widgets.

Les nouveautés de GQuery sont présentées : la délégation d'événements, les promises (il faut rester à la mode…), les animations CSS3 et quelques classes utilitaires. Côté JSNI, GQuery ajoute aussi son lot d'outils pour appeler facilement du code JavaScript, comme avec les JSNIBundle.

Pour ceux qui ne connaissaient pas GQuery, cette session a été très bien perçue.

Cette conférence invitée était proposée par +Joonas Lehtinen.

En comparaison avec le premier jour de la conférence qui était plutôt orientée vers les profondeurs de GWT, le deuxième jour est consacré à l'écosystème GWT. L'occasion pour les acteurs de la technologie de présenter leurs produits (Vaadin, Sencha GXT, JBoss ERRAI…).

Les résultats du sondage sur GWT nous ont également été présentés. Ils sont consultables à partir de cette page.

Eric Jan de Wit de chez JBoss nous présente une démonstration ratée d'une application créée avec ERRAI censée capturer une photo depuis son téléphone mobile pour la récupérer sur le navigateur de son ordinateur. La chose a vraiment du mal à fonctionner, et finalement ce n'est vraiment pas impressionnant ! Oui avec le Web on peut envoyer des fichiers sur un serveur et les récupérer ensuite.

Collin Alworth de Sencha nous présente la roadmap de GXT : au Q1 de 2014, on devrait enfin pouvoir modifier les thèmes de GXT, puis à l'été 2014 la sortie de GXT 4 est prévue.

Christian Goudreau d'Arc Bees nous fait ensuite publicité de son framework GWTP (une implémentation du pattern Model View Presenter Activity Places), du plugin IntelliJ qui va de pair ainsi que du nouvel outil GAE Studio censé faciliter le développement avec Google App Engine. C'est peut-être parce que j'ai été terriblement déçu par son exposé d'hier que je n'ai pas non plus apprécié son intervention.

Ensuite vient le tour d'un des développeurs de Vaadin de nous présenter cet outil. Quelques démonstrations montrent qu'il est réellement facile avec Vaddin de créer des applications orientées données très bien présentées côté client (le look-and-feel de cet outil est vraiment beau, agréable et fonctionnel, bravo.

Cette session était présentée par +Joonas Lehtinen de Vaadin

Johnas nous montre ici la puissance Vaadin, avec du live coding à l'appui (qui fonctionne cette fois-ci, comme quoi cela sert de répéter ;)). L'intérêt de Vaadin, qui repose sur GWT pour la génération du code côté client, tient dans le fait que la couche RPC est totalement abstraite. Les widgets sont déclarés dans le code serveur et sont automatiquement envoyés au client. Bref plus besoin d'écrire d'innombrables méthodes RPC pour alimenter ses widgets. C'est un bel avantage qui vient, comme tout compromis, avec ses effets négatifs : les événements côté client sont envoyés au serveur pour traitement, les widgets sont donc moins efficaces (dans une certaine mesure, car l'ensemble est quand même réellement bien optimisé).

À venir dans Vaadin : l'apparition d'applications hybrides qui justement permettent de reprendre la main sur les widgets quand on souhaite faire du traitement uniquement côté client.

Cet exposé a obtenu un franc succès, l'essentiel du public étant très impressionné par le niveau de qualité de ce framework.

Cette session était présentée par Eric Van de Wit.

À base de démonstrations ratées et sûrement pas répétées, l'orateur nous fait l'apologie du framework ERRAI. Si j'ai bien compris, la plus-value de cet outil est de ne plus avoir à écrire « new » mais de faire plutôt « @Composant », bref l'injection de dépendance.

Je dois arrêter là le résumé de cette présentation sinon je vais continuer à la descendre… À noter que ERRAI est sûrement un bon outil, il a juste été très mal présenté !

Cette session était présentée par des membres de la société QAFE.

Cet exposé présente l'usine logicielle de QAFE, intégrant GWT en son cœur. Cette usine permet de décrire une application graphiquement, en écrivant le moins de code possible. Elle permet notamment de transformer automatiquement des formulaires Oracle en pages Web.

Cette session était présentée par +Arnaud Tournier de LTE Consulting.

C'était à mon tour de présenter un sujet. Visiblement, beaucoup de gens étaient intéressés par ce sujet, car je voyais de nombreuses personnes debout au fond de la salle. D'ailleurs d'après les votes du public, cette présentation est positionnée en 6e place dans le classement des présentations issu du vote. Merci à tous ceux qui ont apprécié ! Essentiellement cet exposé reprenait le contenu de cet article et de la conférence que j'avais donnée l'année dernière à Devoxx FR. Nul besoin donc de s'étendre encore sur ce sujet !

Cette session était présentée par le comité de pilotage de GWT.

Cette dernière session conjointement tenue par tous les membres du steering commitee avait pour objectif d'ouvrir la discussion entre ceux-ci et la communauté des utilisateurs (le public en l'occurrence). Elle s'est donc déroulée dans le mode question/réponse.

Le sujet principal a été l'abandon du support d'IE 8 et 9 et le meilleur moment pour le faire. Le public insiste sur le fait que nombre de leurs clients utilisent encore ces navigateurs et que donc leur support reste nécessaire. En gros, on nous propose de maintenir ce support dans GWT 2.6 mais de l'abandonner dans GWT 3. Les raisons de ceci sont techniques. Le support de ces vieux navigateurs crée trop de dettes techniques dans le code de GWT et ne permet pas de suivre ni facilement ni efficacement les évolutions des navigateurs modernes.

De toute façon, nous apprend Daniel Kurka, nous n'avons pas le choix. Car aujourd'hui, malgré la création du steering commitee, le principal contributeur de GWT reste Google. Et si GWT ne reste pas à la hauteur de ses attentes, et bien Google n'hésitera pas à lâcher GWT !

D'autres questions ont porté sur les thèmes suivants :

• un peu de dynamisme dans UiBinder (gestion des boucles, des traitements conditionnels) ? La réponse du comité a, si ma mémoire est bonne, consisté à dire que ceci ne sera pas pris en charge ;
• les permutations vont-elles disparaitre ? La réponse est mitigée, mais n'en reste pas moins qu'il est envisageable de faire les choses dynamiquement au runtime quand le gain en termes de taille des JavaScript téléchargés est faible ;
• beaucoup de questions sur Source Maps et le Super Dev Mode, qui pour l'instant ne satisfait pas du tout les développeurs. La réponse : et bien Google abandonne de force NPAPI dans Chrome en 2014, ce qui signifie que le plugin du mode dev ne fonctionnera plus. Donc encore une fois, notre cher moteur de recherche force la main !

À noter que je n'ai assisté à aucun workshop, mais que j'en ai entendu beaucoup de bien. Surveillez donc la sortie des vidéos pour rattraper tout cela.

Cette conférence sur deux jours a été un grand succès. Le public était au rendez-vous (plus de 650 personnes au total), ce qui montre bien que contrairement à certaines rumeurs qui ont couru en 2012, GWT n'est absolument pas abandonné du public. Et côté acteur de la technologie, Google fait reposer nombre de ses produits sur cette technologie (on le savait pour sa régie publicitaire, mais on le constate encore avec l'annonce qui a coïncidé avec la conférence sur la sortie de la nouvelle version de Google Spreadsheets entièrement réalisée avec GWT, plus rapide et surtout qui fonctionne en mode hors-ligne). Spreadsheet étant un logiciel d'importance majeure pour Google (c'est l'application officielle de tableur dans les ChromeBooks), on imagine mal celui-ci se retirer du projet. Les autres acteurs comme Sencha, JBoss et Vaadin font également reposer leur business sur GWT.

Ça a été aussi une très belle occasion de rencontrer de nombreux utilisateurs européens du projet, d'échanger des avis, des problématiques, etc.

Pour le futur, vu l'accueil du public à la présentation de Daniel Kurka, on comprend bien que GWT a un très bel avenir devant lui !

Je tiens à vous conseiller d'aller lire cette page dans laquelle +Sami Jaber et +Romain HOCHEDEZ de DNG Consulting présentent aussi leur compte-rendu (sur des sessions différentes).

J'en profite pour remercier chaleureusement les organisateurs. Et évidemment, j'attends avec impatience la prochaine occurrence de GWT.create, prévue début 2015, si je ne m'abuse.

Nous tenons à remercier ClaudeLELOUP pour sa relecture orthographique attentive de cet article puis Mickael Baron pour la mise au gabarit.