jeudi 30 janvier 2014

Compte-rendu de GWT.create, LA conférence dédiée à GWT

Les 17 et 18 décembre 2013 se tenait à Frankfort la conférence GWT.create tant attendue des utilisateurs de GWT. Voici un résumé chronologique des sessions auquelles j'ai pu assister, représentant la société LTE Consulting, experte sur GWT.

Avant toute chose, 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).

La key note


Pendant la keynote, +Joonas Lehtinen nous apprend que cette conférence connait un véritable succès (quelque peu inattendu en fait). 211 personnes étaient présentes à San Francisco (la conférence s'est aussi tenue aux Etats-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és au Radisson Blu Hotel pendant deux jours.

Puis, toujours pendant la keynote, +Ray Cromwell prend la main. La communauté des utilisateurs de GWT est estimée à 100.000 développeurs. Cette estimation est bien sur quelque peu grossière mais donne à penser que GWT connait toujours un franc succès parmis 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 releases 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 capable et rapides. On constate moins d'incompatibiltés entre ceux-ci. Les applications mobiles sont influencées par leur é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 dores 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'intéropé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. Evidemment, 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 vielle 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 le-dit Super Dev Mode.
En soit 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ébugger une application. En effet, le débug 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ébug. Le problème est que dans ce mode, on ne peut pas inspecter les valeurs de nos champs Java... Retour au debug 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 pieds pour palier à ce problème. A suivre donc...

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

Les Générateurs GWT 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 surement quelque chose. Et cette session m'a finalement beaucoup déçu. Tout d'abord le speaker 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 speaker, dans le fond cette session n'a pas apporté de profondeur non plus. Tant pis !

Compiler Deep Dive 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 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 point 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).
A la fin de cette étape, le compilateur ne travaille plus sur l'arbre Java mais 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 lien 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 envoi directement la bonne permutation.
Cette session fut très bien menée (on connait Ray Cromwell qui est un très bon speaker) et très intéressante. Ce sont le genre d'informations que vous retrouverez dans les formations de DNG Consulting...

Appearance Pattern par +Colin Alworth de Sencha


Cette session nous présente le pattern apparence, utilisé sans réserve dans le framework GXT de Sencha. Quiquonque 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 il 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 à qui donner le focus et de l'état de fragment 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 oeuvre 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 speaker élargi ensuite son propos pour nous montrer la technique de génération de thème 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 utilisateur 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 !

Un aperçu du futur de GWT par +Daniel Kurka


Note: cette session devait initialement être présentée par +Goktug Gokdogan qui n'a malheureusement pas pu se rendre à Franfort. 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 vu, 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 simple 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 auront également droit à une nouvelle méthode GWT.jsni(...) pour exécuter du Javascript sans avoir à déclarer de méthode final 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 raprocher 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 ce talk, on peut dire que toutes ces nouveautés ont été très bien accueillies et sont attendues impatiemment (c'est également mon cas ;)).

GQuery, le companion idéal 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 speakers 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 noeuds 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 sont 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.

Keynote du deuxième jour par +Joonas Lehtinen


En comparaison avec le premier jour de la conférence qui était plutôt orienté vers les profondeurs de GWT, le deuxième jour est consacré à l'écosytè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 a également été présenté. 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 au final 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 talk d'hier que je n'ai pas non plus apprécié son intervention...
Ensuite vient le tour d'un des développeur 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 !).

Découvrir Vaadin 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'innombrable 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é).
A venir dans Vaadin : l'apparition d'application hybrides qui justement permettent de reprendre la main sur les widgets quand on souhaite faire du traiement uniquement côté client.
Ce talk a obtenu un franc succès, l'essentiel du public étant très impressionné par le niveau de qualité de ce framework.

JBoss ERRAI par Eric Van de Wit


A base de démonstrations ratées et surement pas répétées, le speaker 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 ce talk sinon je vais continuer à le descendre... A noter que ERRAI est sûrement un bon outil, il a juste été très mal présenté !

GWT, construire un business à un million de dollar par des membres de la société QAFE


Ce talk 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 formulaire Oracle en pages web.

Faciliter le développement d'applications hors-ligne avec GWT par +Arnaud Tournier de LTE Consulting


C'était à mon tour de présenter un talk. Visiblement, beaucoup de gens étaient interressé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, ce talk est positionné en 6ème place dans le classement des présentations issu du vote. Merci à tous ceux qui ont apprécié ! Essentiellement ce talk reprennait 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 !

Le panel GWT 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'occurence). 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 leur clients utilise 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 dette technique 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 à lacher 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 terme de taille des javascripts 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 !


Les workshops


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

Conclusion


Et voilà, c'est fini !
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 absoluement 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 coincidé avec la conférence de 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 officiel 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.
Ca 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'acceuil du public du talk de Daniel Kurka, on comprend bien que GWT a un très bel avenir devant lui !

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.

Amicalement vôtre,
Arnaud Tournier
CEO @LTEConsulting
Formation, Conseil et Développement GWT
www.lteconsulting.fr

PS : voici un lien vers les slides des conférences données à GWT.create. Les vidéos arriveront sous peu !