JUG Summer Camp 2010 : Présentation et GWT2 1/5

Polo Ippon Technologie (si si en haut à droite)C’est revêtu de mon magnifique polo Ippon Technologies (voir ci-contre, en haut à droite) que j’ai participé à cette première édition du JUG Summer Camp, le 10 septembre 2010, à l’espace ENCAM de La Rochelle.

Cette conférence, organisée grâce au Poitou-Charente JUG et au sponsoring de SERLI, reprend les grands principes d’une réunion de JUG (i.e.. ce que l’on peut trouver à Nantes, Tours, Paris) :

  • gratuité pour les participants
  • sujets plutôt techniques
  • savant mélange de décontraction et de qualité
  • financement par le sponsoring

La particularité de ce JUG Summer Camp, c’est le changement d’échelle : on passe du format “une ou deux sessions, un soir par mois” à “une douzaine de sessions, sur une journée”. Il y avait donc toujours 2 conférences en parallèle : autant dire que le choix était très (très) difficile.

Je vais donc vous faire un résumé des sessions que j’ai suivi (d’ailleurs, par le plus grand des hasards, j’ai suivi un “track” complètement différent du Touilleur Express). Mon objectif est de vous proposer 1 article par jour pour chacune des sessions suivantes :

Commençons dès maintenant, avec la première session :

Après la KeyNote d’Emmanuel Bernard, j’ai suivi la présentation de Nicolas de Loof sur GWT 2. Pour la petite bio, Nicolas de Loof est Architecte chez Orange IT&Labs, committer sur le projet Maven depuis fin 2007 et a publié – il y a quelques mois – un livre sur Apache Maven.

Cette présentation démarre comme un gros troll fort : “le web 2.0, c’est un bidule commercial”. Nicolas souligne – avec raison – qu’il ne faut pas oublier la plateforme sous-jacente : le “Web 2.0” représente une dizaine de modules dans le navigateur (CSS+JS+DOM+SVG…), plusieurs milliers de lignes de code… et donc autant de bugs. Il est donc très difficile de développer une application qui fonctionne sur l’ensemble des navigateurs du marché.

Même en imaginant qu’on dispose d’une équipe très compétente en Javascript, il faut aussi prendre en compte que les outils de développement Javascript sont très hétérogènes et ne sont pas disponibles sur l’ensemble des navigateurs (ex: Firebug).

En fait, Nicolas explique que l’ensemble des intervenants d’un projet sont à la recherche d’une solution :

  • l’architecte pour ne pas traiter les problèmes de bas niveau
  • le chef de projet car il ne dispose pas d’assez de compétences Javascript dans l’équipe pour tenir le planning
  • le développeur car il aime utiliser son IDE favori et son outillage habituel

GWT répond à ces problématiques en utilisant Java comme le langage de programmation puis en faisant une compilation du code Java vers du Javascript. On reprend globalement les principes de développement de Swing (Listener, Actions, etc.…).

Leitmotiv : “Javascript doit être considéré comme le nouveau ‘langage machine’ (= non cross-platform)”

Il évoque ensuite quelques fonctionnalités de GWT :

  • fonctionnement hors-ligne via Google Gear ou HTML5
  • multi-navigateurs automatique (une simple re-compilation suffit)
  • support du bouton “back”
  • localisation (l10n) et internationalisation (i18n) facilitées

Nicolas a étudié le résultat ultra optimisé produit par le “compilateur” GWT. Il en ressort qu’il modifie énormément la structure du code : passage de fragments en inline, extraction du code statique. Le compilateur lance ensuite la génération des permutations (i.e.. autant de fichiers Javascript générés que de navigateurs cibles). D’autres optimisations sont mises en oeuvre : les fichiers JS finalisés sont compressés, seuls les styles CSS utilisés sont inclus et enfin les images sont fusionnées sous la forme de bundles (aussi appelés CSS sprites).

Le speaker nous fait ensuite un rappel sur les nouveautés de la version 2.0 de GWT. Une des fonctions les plus pratique est sans aucun doute, le mode OOPHM : il s’agit de remplacer l’ancien “hosted mode” (un browser limité permettant de tester sans compilation) par l’utilisation d’un vrai navigateur web + plugin pour tester. Ce nouveau mode permet notamment des tests sur des configurations de type Opera sous Windows, ce qui était impossible avant. Il permet également d’utiliser des outils comme Firebug et du réaliser un véritable profiling du code. Il évoque également runAsync pour le découpage en modules ou encore UIBinder pour marier l’EntryPoint GWT (Java) avec la super maquette du designer (HTML).

Un slide est bien sûr dédié aux concurrents :

  • Flex qui nécessite un runtime récent, ne dispose pas de typage fort, est propriétaire et nécessite d’apprendre un nouveau langage (AS3)
  • Silverlight : déploiement limité : support sur les OS mobiles ? sur Linux ?
  • JavaFX : sans commentaires 🙂

Nicolas a ensuite sorti sa boule de cristal pour essayer de nous lister les nouveautés de la prochaine version. Autant le dire tout de suite, avec Google, les boules de cristal fonctionnent assez mal : par exemple, le framework MVP “officiel” attendu depuis longtemps n’est toujours pas disponible sur le SVN ?! Idem pour la solution de databinding “BikeSheed” : ajoutée au trunk, jugée trop complexe puis finalement presque entièrement supprimée… Cependant, tout n’est pas négatif : le rapprochement de GWT avec SpringSource semble porter ses fruits via le projet Spring Roo et une meilleure intégration avec Maven (les milestones sont disponibles dans un repository Maven dédié) est dans les tuyaux !

Resources

A suivre : présentation OpenSocial par Tugdual Grall

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

8 réflexions au sujet de « JUG Summer Camp 2010 : Présentation et GWT2 1/5 »

  1. Merci pour le résumé. Je suis quand même toujours surpris que des technologies composants comme JSF ou Wicket ne soient jamais citées comme concurrentes de GWT.
    Ces technologies ne sont certes pas compilées comme Flex ou Silverlight mais le résultat final est bien de produire des interfaces “Web 2.0” (désolé pour le bidule commercial) sans faire de Javascript et sont en ça beaucoup plus proches de GWT. Je ne connais pas super bien Wicket mais côté JSF, des bibliothèques comme Richfaces, Primefaces ou Icefaces constituent des solutions alternatives sérieuses à GWT supportant de la programmation événementielle à la Swing. L’arrivée de JSF 2 renforcent encore plus ces solutions en les rendant encore plus interopérables.

  2. Je pense qu’il ne faut pas opposer GWT et les JSF/Wicket, car ils ne sont pas destinés à la même cible.
    GWT propose une approche fondamentalement indépendante du logiciel serveur : il génère uniquement du code “client-side” et permet d’accéder à du .NET ou du PHP via du RPC. C’est un outil de développement d’IHM web, pas plus…
    Pour faire cette comparaison, il faudrait plus prendre Vaddin (http://vaadin.com/comparison – qui reprend GWT mais en mode server-side) vs JSF vs Wicket.
    A titre purement “historique”, il faut savoir qu’il existait même un projet pour intégrer des composants graphiques GWT dans des pages JSF : https://ajax4jsf.dev.java.net/nonav/ajax/gwt/gwt-cdk.html et http://www.theserverside.com/news/1365076/Integrating-the-Google-Web-Toolkit-with-JSF-using-G4jsf

    1. Merci d’éclairer ma lanterne. J’ignorai que GWT avait fricoté avec JSF dans sa jeunesse.
      Je serais curieux de savoir combien de projet .Net ou Php utilisent GWT sachant qu’il faut tout de même utiliser Java pour générer les écrans 😉

  3. Bon résumé.
    Je n’ai pas exactement dit que le web 2.0 était un concept commercial, plutôt qu’on voulait y voir un concept technique alors que c’est une notion comportementale et organisationnelle de l’information. Mais c’est clair qu’on trouve des truc “2.0” un peu partout de nos jours.

    JSF ou Wicket (que j’ai pratiqué) ne sont pas des concurrents de GWT. On produit avec des applis web avec un gros coup d’Ajax mais ça reste du client web avec mise en page sur le serveur et bcp d’échanges client/serveur juste pour le visuel.

  4. > Nicolas a ensuite sorti sa boule de cristal pour essayer de nous lister les nouveautés de la prochaine version.> Autant le dire tout de suite, avec Google, les boules de cristal fonctionnent assez mal : par exemple, le framework> MVP “officiel” attendu depuis longtemps n’est toujours pas disponible sur le SVN ?!Il n’y a pas véritablement de _framework_ MVP “officiel” prévu pour la GWT 2.1. Il s’agirait plutôt de quelques classes et surtout d’une approche pour mettre en place le MVP. Le code est bien disponible depuis le repository SVN sur le Google Code du projet. Des versions milestone de la 2.1 (la version en phase “General Availability” serait prévue pour la mi décembre) sont d’ailleurs disponibles sur le site :http://code.google.com/p/google-web-toolkit/downloads/listL’interface que les classes jouant le rôle de Presenter doivent implémenter est com.google.gwt.app.place.Activity :http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/app/place/Activity.javaJe recommande la lecture d’un post de Thomas Broyer pour plus d’info sur le sujet ou pour aller plus loin d’essayer Spring Roo (pas indispensable mais offre l’un des rares exemples d’utilisation)http://tbroyer.posterous.com/gwt-21-activities> Idem pour la solution de databinding “BikeSheed” : ajoutée au trunk, jugée trop complexe puis finalement presque entièrement suppriméeLe “jugée trop complexe” est, il me semble, l’opinion de Nicolas (cf http://blog.loof.fr/2010/09/bye-bye-bikshed.html) pas forcément celle de la communauté ou de l’équipe GWT.”bikeshed” n’était qu’un répertoire du repository SVN destiné à être un “bac à sable” pour le développement de GWT. La plupart du code présent dans bikeshed a été intégré au trunk (répertoire user et samples) et n’a pas été supprimé ou du moins perdu.Sinon il me semble qu’il n’a jamais été question d’offrir une solution de databinding générique comparable à celle de Flex ou celle de Windows Presentation Foundation. Il s’agit plus exactement de permettre depuis GWT la manipulation d’entité style JPA situé côté serveur avec le minimum d’effort et en étant le plus DRY possible.Pour celà, une solution de databinding spécifique à cette problèmatique a été développé, désigné sous le terme de ValueStore. Dans la 2.1, elle est intégrée comme un “détail d’implémentation” pour permettre la manipulation susmentionnée, via le RequestFactory.> Cependant, tout n’est pas négatifSurtout si on considére que les éléments négatifs cités n’existent pas.> le rapprochement de GWT avec SpringSource semble porter ses fruits via le projet Spring RooJe pense même que ce rapprochement est bénéfique aux utilisateurs de GWT qui n’utiliseront pas Spring Roo. En effet, les nouveautés de la version 2.1 de GWT sont très probablement le résultat de la collaboration entre VMware (Spring Roo) et Google (GWT). La synchronisation des calendriers de Spring Roo 1.1 et de GWT 2.1 est témoin de celà :https://jira.springsource.org/browse/ROO?selectedTab=com.atlassian.jira.plugin.system.project:versions-panelhttp://code.google.com/p/google-web-toolkit/downloads/list

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*