.
I. Compatibilité multinavigateur▲
Les clients soulèvent souvent le problème suivant : lors de la sortie d'une nouvelle version d'un navigateur, est-il nécessaire de recompiler leur application ? Deux cas peuvent se présenter :
- en premier lieu, examinons la pire des situations : les API JavaScript sont « cassées » par la nouvelle mouture. Dans ce cas-là, il est évident qu'une recompilation de l'application est nécessaire. Qui plus est, il faudra attendre qu'une version du SDK de GWT prenne en compte les nouvelles API du navigateur ;
- les développeurs de navigateurs ayant généralement comme première priorité de conserver une compatibilité descendante entre leurs différentes versions, ce cas est extrêmement rare (personnellement, je n'y ai jamais été confronté). À titre d'exemple, dans le cadre du développement de notre application (programme de gestion de subventions pour agriculteurs) et qui utilise des fonctionnalités avancées de GXT, le navigateur IE 10 est sorti, sans prise en charge spécifique de la part de GWT. Notre application fonctionne parfaitement sur ce nouveau navigateur : nous n'avons pas eu à la recompiler spécifiquement pour cette plateforme d'exécution.
II. Pertinence de l'utilisation de GWT sur des applications orientées formulaire▲
Notre client avait pour objectif de refactoriser des applications essentiellement orientées formulaire. Il pensait qu'utiliser GWT dans ce cas serait comme utiliser un marteau pour écraser une mouche. Voici ma réponse : GWT offre la possibilité de vous approprier à 100 % toutes les innovations techniques disponibles dans les navigateurs modernes, ainsi il peut sembler superflu au premier abord d'utiliser cette technologie pour créer de simples formulaires. Cependant, si on approfondit cette analyse, il n'y a plus de doute : GWT utilise le langage Java. Vous aurez donc la possibilité de partager du code entre l'application cliente et votre back-end Java. Ainsi, dans le cadre d'un simple formulaire, le code de contrôle des champs peut être partagé entre le serveur et le client.
Par exemple, en cas de contrôles croisés spécifiques sur plusieurs champs, GWT vous permettra de n'écrire qu'un seul code (contrairement à l'usage de JSF qui vous obligera soit à coder vos contrôles côté serveur en Java et JavaScript pour le client, soit à utiliser des composants JSF spécifiques), d'où un gain de productivité substantiel pour les développeurs. Et d'ajouter que la programmation des écrans peut se faire en XML avec UiBinder, ce qui sera, pour un développeur habitué à coder pour JSF ou Struts, un moyen de passer à une technologie beaucoup plus puissante tout en conservant des paradigmes de programmation similaires.
Enfin, posons-nous également la question de savoir si une application ne se compose que de simples formulaires du fait du besoin client, ou bien parce que la technologie utilisée pour développer cette application limite les possibilités offertes aux utilisateurs.
III. Pérennité de la technologie GWT▲
Troisième point et non des moindres, nos clients hésitent généralement à utiliser GWT, car ils ont des doutes sur son futur. Bien que la technologie soit conçue et maintenue par le géant Google, la communication à ce sujet est assez déplorable. Certaines rumeurs argumentent notamment que le langage Dart supplantera à terme GWT. Il s'agit là d'une confusion immense : en effet, mis à part la nature plus « typée » du langage Dart qui le fait percevoir comme un concurrent de Java, il n'y a aucune intersection entre Dart et GWT. GWT ne se résume pas à un langage, c'est une technologie à part entière : optimisation des ressources réseau, compilation ultra performante, prise en charge multinavigateur, internationalisation, etc. Tout ceci n'a pas trait au langage utilisé, mais est un ensemble d'outils permettant au développeur d'avoir une productivité à développer des applications Web semblable au développement d'application lourdes.
D'autres rumeurs prétendent que GWT sera supplanté par des frameworks JavaScript comme Angular.js (qui fait le buzz depuis plusieurs semaines), Backbone.js et j'en passe. Je m'en remets au jugement du Chef de Projet afin de déterminer s'il est préférable pour son équipe de connaître/d'être expert en JavaScript et de savoir maintenir une base de code JavaScript en plus du code Java côté serveur. GWT est une technologie de qualité, mature, utilisée sur des produits industriels depuis presque 10 ans, maintenue à la fois par un comité de pilotage orchestré par Google et par la communauté Open Source. La récente réorganisation du comité de pilotage ne s'est pas faite par Google dans l'objectif d'abandonner la technologie, mais au contraire dans l'idée d'inviter les contributeurs majeurs « third-party » à venir participer à l'amélioration du framework et à garantir sa pérennité. Ce comité se compose entre autres de membres issus de Google, de RedHat, de GXT de Sencha (anciennement Ext-GWT), de Vaadin, ArcBees, ainsi que de JetBrains. Sans parler de l'immense écosystème Open Source gravitant autour de la technologie.
Je trouve dommage que Google laisse courir ces rumeurs, sans offrir de communication officielle. J'espère que vous serez malgré tout conquis par cette technologie très innovante, au futur plus que certain, vous permettant d'exploiter les technologies Web dans toutes les possibilités qu'elles vous offrent. De nombreux clients grands comptes ont déjà fait le pas, et n'ont jamais été déçus !
Pour en savoir plus sur GWT, voici quelques liens que j'ai sélectionnés :
IV. Conclusion▲
À l'heure où j'écris ces pages, les résultats du sondage organisé par le comité de pilotage de GWT viennent d'être publiés. Très complets, ils donnent à penser que le futur de GWT est toujours très prometteur : https://vaadin.com/blog/-/blogs/the-future-of-gwt-report-2012
V. Remerciements▲
Cet article a été publié avec l'aimable autorisation de la société PaloITPaloIT.
Nous tenons à remercier ClaudeLELOUP pour sa relecture orthographique attentive de cet article et Mickaël Baron pour la mise au gabarit.