Paris JUG – GWT

"Bonsoir à tous ! Alors tout d'abord, il y a eu un petit bug sur l'application d'inscription qui doit normalement limiter les inscrits à 200, ce soir nous en avons 239 !"

Mais qu'est-ce qui peut bien rassembler autant de monde un mardi soir ? Facile, la réponse est dans le titre.

Le 4 novembre se tenait donc à l'initiative du JUG de Paris une présentation du Google Web Toolkit. Ce framework très deux-point-zéro repose donc forcément sur Ajax, et aspire à séduire :

  • l'utilisateur avec une interface dynamique et élégante, proche de celle d'un client lourd ;
  • le développeur par l'utilisation du Java uniquement pour la construction d'interfaces dans un contexte événementiel.

Une interface sexy avec le confort de programmation de bibliothèques comme Swing ou Qt, serait-ce trop beau ?

Petit retour en arrière, et sondage du public : visiblement beaucoup de personnes utilisent le Javascript, mais le nombre de celles qui se considèrent "expertes" tient sur les doigts de la main. Hmmm, donc les autres aussi...

Alors quels sont les problèmes avec le Javascript ? Sont cités :

  • les incompatibilités entre navigateurs ;
  • les fuites mémoire ;
  • l'absence d'un IDE ;
  • l'absence d'un débuggueur multi-navigateur ;
  • la sécurité.

Jusque là, tout va bien. Mais revenons à GWT. L'idée est donc de coder une interface utilisateur en Java, en utilisant des widgets fournis par Google. Ce code, ainsi que les entités métier nécessaires côté client, sera transcrit en Javascript et envoyé au navigateur qui exécutera une partie de l'application en local, en faisant si nécessaire des appels à des services offerts par le serveur.

Les yeux pétillants de curiosité, il nous faut une démonstration ! Quelques exemples d'utilisation de GWT sont projetés, et des noms circulent : ContactOffice, myERP, etc.

"Comme ces exemples le suggèrent, GWT est bien adapté au applications de gestion."

Ah ! 🙂

Sous nos yeux en quelques minutes seulement, une petite calculatrice prend vie. Toujours sans taper le moindre code en Javascript. Mais le meilleur reste à venir : il s'agit de l'intégration à Eclipse. Le "hosted mode" offert par GWT permet d'utiliser le débuggueur Eclipse de façon classique, avec points d'arrêt et évaluation d'expression à la volée... Pas mal !

On pourra donc retenir parmi les arguments convaincants en faveur de GWT :

  • l'utilisation de Java pour le développeur ;
  • la rapidité de développement d'une interface riche et conviviale ;
  • la non remise en cause de l'architecture client/serveur HTTP classique ;
  • la compatibilité avec les feuilles de style CSS ;
  • en comparaison avec Flex, Silverlight, Flash, la non nécessité d'installer un plugin dans le navigateur.

mais sans en oublier les limites :

  • la sapin-de-Noël-isation d'une application liée à l'utilisation abusive d'effets graphiques ;
  • question du public : "et les tests unitaires ?" Selenium ne fait pas tout ;
  • les limitations du code Java transcrit et envoyé au client : pas de JDBC, pas d'introspection, etc ;
  • les inconvénients liés à l'utilisation de Javascript, notamment les performances liées à l'interpréteur (Webkit, etc) ;
  • la relative jeunesse du projet par rapport aux frameworks MVC J2EE "classiques".

Le mot de la fin : "L'avenir sera mobile, GWT fonctionne avec Android et l'iPhone !"

Un commentaire

Laisser un commentaire

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

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.