Le blog de L'ami S'ami

J’en profite pour souhaiter à tous les lecteurs de mon blog une excellente année 2007, pleine de joie et de bonheur. Désolé de ne pouvoir blogguer plus régulièrement mais le travail a tendance en ce moment à prendre le pas dans mon planning sur toute autre activité technologique d’ordre extra-professionnelle.

Malgré tout, je voulais en profiter pour évoquer rapidement un sujet qui a passionné les galeries pendant toute l’année 2006 et qui fait encore parler en ce début d’année 2007 : le Web 2.0 avec plus particulièrement AJAX.

Depuis quelques mois, je me suis penché assidûment (avec d’autres collègues de Valtech d’ailleurs) sur la plupart des Toolkit du marché. J’en profite donc pour faire un bref retour d’expérience. N’hésitez pas à y apporter votre grain de sel.

Le Toolkit AJAX qui m’a le plus séduit est GWT (Google Web Toolkit). Je n’ai jamais été un gourou de Javascript et l’avènement d’AJAX a élevé le niveau requis pour produire ne serait-ce qu’un contrôle simple de type Suggest ou UpdatePanel.

Or, avec GWT, toute la problématique Javascript est reléguée au second plan. Le modèle de développement GWT s’appuie sur la notion de post compilation serveur. En pratique, un générateur de code se charge de parser une sorte d’arbre de contrôles Java pour en faire un arbre DOM dynamique en Html et Javascript. Avec ce modèle, le développeur garde toutes ses habitudes Java sans ce soucier des problématiques de CSS et de DOM. Les fichiers JavaScript sont générés à la volée et optimisés par rapport aux besoins de l’utilisateur.

Dans ce contexte, tout devient plus simple, les pauvres événements clients javascript deviennent de réels listeners typés côté serveur. Développer des fenêtres modales ou des évènement asynchrones relève vite du jeu d'enfant.

GWT excelle dans ce modèle qui fait la part belle à la maintenabilité du code produit. On ne compte plus les nombreux composants graphiques fournis par cette communauté Open Source en pleine essor. Des DataGrid Ajaxé (sorting, filtre, paging) au Suggest en passant par la géolocalisation avec Google Earth ou le glisser/déplacer.

Sur le serveur, GWT tire parti des fonctionnalités offertes par la plupart des serveurs d’applications J2EE : Web Services, RPC, Servlet. En terme d’architecture, on touche l’excellence dès lors qu’on commence à concevoir du n-tiers avec côté client des DTO alimentés via des services faisant appel à JPA ou Hibernate (veiller à régler les pbs de sérialisation et de binding des types java->javacript).

Seul bémol, l’environnement de développement, encore un peu léger même si l’offre du marché commence à s’étoffer avec des Designer commerciaux.

L’autre modèle de développement, plutôt opposé à GWT est basé sur des bibliothèques de composants JavaScript. Les plus réputés sont BackBase, Bindows ou Dojo. J’avoue ne pas être un grand fan de cette approche pour plusieurs raisons. Tout d’abord à cause des problèmes de maintenabilité. Il suffit de comparer le code source d’un DataGrid en Dojo et en GWT pour se rendre compte qu’un langage fortement typé basé sur un modèle de composants hiérarchiques et évènementiels est toujours plus simple à comprendre et à maintenir qu’une liste de blocs « div » associés à une feuille de style CSS, même en passant par une fonction JavaScript sensé masquer toute la tuyauterie.

Autre point, il est toujours plus intéressant pour l'homogénéité d'un projet de disposer du même IDE côté client et côté serveur. Or Eclipse n’est pas forcément le meilleur éditeur JavaScript, et encore moins le meilleur déboggeur JavaScript.

Enfin, un générateur de code a l'avantage de pouvoir optimiser le code Javascript produit côté client pour alléger les pages et améliorer les performances. Une souplesse que n'a pas forcément un require("JavascriptFile") statique.

Nul doute que GWT fera partie des grandes stars de l’année 2007. Si vous n'aimez pas JavaScript, vous aimerez GWT...