La très attendue version 1.5 de GWT vient d’arriver. Il s’agit d’un important pas en avant pour le framework de google et pour les développeurs java.
Pour rappel, GWT est une bibliothèque qui permet de créer des applications avec des IHM complexes, qui tournent sur client léger, et tout cela sans connaître javascript, car écrites complètement en java. Il est livré avec des outils de développement et de debug, et il est soutenu par une toute petite boîte américaine qui s’appelle Google.
Au menu:
Support de java 5. On pourra enfin utiliser les listes typées et les generics de Java 5, ils seront traduits en javascript. On pourra utiliser des classes du type StringBuilder, TreeMap qui seront émulés en javascript côté client. Grand pas en avant car il va permettre d’utiliser ce framework avec du code bien plus propre.
Amélioration des performances. A chaque version, Google améliore encore les performances de son framework. Selon les dires de Bruce Johnson, leader du projet, les développeurs qui ont utilisé GWT 1.5 ont senti une amélioration de x2. Quand on sait que le moteur Javascript de Firefox est lui aussi en grande amélioration de performance (voir http://xulfr.org/news/2008/08/28/259-tracemonkey-dans-firefox-31-le-javascript-qui-boost) et que HTML 5 pourrait bien être un bon cru, on voit que l’approche « classique » (html/javascript) se remobilise face à la concurrence des approches RIA (Flex, Silverlight…).
Amélioration des widgets : plus beaux, plus faciles à customiser accès à la CSS par défaut), plus accessibles (qui supportent la norme ARIA), plus fonctionnels, voire qui supportent les langues écrites de droite à gauche. DOM : Accès par une nouvelle classe qui mappe entièrement les recommandations du W3C.
Une meilleure doc (c’était pas bien difficile), mise à jour. Avec notamment une belle page bien parlante qui montre l’ensemble des widgets : http://gwt.google.com/samples/Showcase/Showcase.html
En parallèle, Microsoft crée son GWT pour la plateforme .Net. avec Volta. Mais ils se basent sur le bytecode plutôt que sur le code source pour générer le javascript.
(http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/9af068124dae8e04)
On peut distinguer quatre tendances dans la percée de GWT:
- Percée des frameworks webs à composants – au détriment des frameworks webs sur le mode request/réponse. Ils correspondent mieux aux mécaniques ajax, et à une réutilisation intelligentes des composants.
- Les frameworks webs peuvent se distinguer entre ceux qui permettent de créer des sites internet, avec de belles URL, une grande proximité avec le HTML (Struts, Tapestry, Wicket), et les frameworks qui permettent surtout de créer des applications web complexes, avec un moins grand respect pour les questions de présentation, mais une plus grande possibilité de faire des IHM très dynamiques (GWT et d’une certaine manière JSF). Wicket peut se placer dans les deux catégories: manipulation aisée du HTML dans le code java ; en revanche la capacité à créer des widgets n’est pas son plus grand atout.
- Il y a deux approches : L’une embarque la mécanique, les aspects dynamiques des pages, dans du (X)HTML. C’est l’approche traditionnelle (JSP, php, Struts, Tapestry, JSF…) qui correspond à l’architecture du HTML et qui embarque les données dans des tags. Et l’approche qui consiste à être le moins intrusif possible dans les pages HTML et décorer ces pages (Wicket, GWT) avec du code dynamique. (Tapestry est un peu entre les deux approches, avec à la fois la présence d’une taglib, et une décoration systématique et un grand respect pour les maquettes HTML).
Les frameworks HTML/Ajax ne sont pas démunis face aux solutions RIA.
Il faudra cependant que les normes (html, javascript), continuent à évoluer pour permettre la création d’interfaces graphiques nativement plus fonctionnelles, gérant par exemple : le Drag’n’Drop, la mise à jour dynamique de données (Comet), l’intégration des données et de la présentation (JSon).
Auteur : Gabriel Kastenbaum