Ces derniers jours, la blogosphère francophone s’est enflammée concernant la pertinence de GWT. Florent Garin a ouvert les hostilités jeudi dernier en questionnant cette pertinence, avec une réponse nuancée mais néanmoins plutôt négative. Sami Jaber y a répondu vendredi par un vibrant “oui” (à la limite du fanatisme cependant). Et enfin Ludovic Borie seconde ce dernier avis tout en confirmant les défauts critiqués par le premier.
Je me devais de réagir, n’étant en accord complet avec aucun d’entre eux. Mais tout d’abord, il faut bien avouer que mon avis n’est pas celui d’un utilisateur lambda, étant très impliqué dans le développement même de GWT: outre de nombreux patchs, je suis l’un des rares à pouvoir faire le tri des bugs (les assigner, les fermer), et les bugs concernant RequestFactory me sont quasiment assignés d’office. D’autre part, je n’ai (à mon grand regret) jamais écrit (ou même lu : si vous avez des liens, je suis preneur) de grosse single-page application en JavaScript.
# Alors quelles sont critiques à l’égard de GWT qui pourraient remettre en cause sa pertinence aujourd’hui comparé à des frameworks JavaScript ?
“absence d’une vraie bibliothèque de widgets solide et pérenne” : ce n’est pas faux, mais je peux difficilement accepter cet argument vu l’absence quasi-totale de bibliothèque de widgets côté JavaScript. Closure Library propose quelques widgets supplémentaires (et d’autres nettement mieux conçus que ceux de GWT), mais par exemple aucune datalist ou datagrid liées à des données (à l’instar des CellList, CellTable, DataGrid et autre ValueListBox de GWT), et à part ça on retrouvera ExtJS et SmartClient qui sont tous deux lourdingues et ont leur équivalent GWT (un portage et un wrapping). Avec GWT comme en JavaScript, on fera plutôt ses propres widgets, à base de templates: UiBinder avec GWT (voire plus récemment UiRenderer et SafeHtmlTemplates) ; Mustache.js, Underscore.js, Closure Templates et autres en JavaScript. Et pour le data-binding, l’Editor framework fait des merveilles, avec une approche “Flow Synchronization” forcément plus légère au runtime qu’une approche Observer comme avec Backbone.js par exemple.
“complexité” : sont pointés du doigt ici en particulier les Places et Activities d’une part, et Request Factory d’autre part. Les trois bloggeurs sus-cités s’accordent sur ce point, et ne mettraient pas par exemple les Places et Activities entre les mains d’une équipe de développeurs “de niveaux hétérogènes”. Pour l’avoir fait, avec une équipe allant du stagiaire à l’ingénieur de niveaux hétérogènes quant au développement Web, je ne peux que m’inscrire en faux. De ce que j’en comprends, les Places et Activities proposent une abstraction d’un niveau légèrement plus haut que ce qu’on trouve dans les routes d’un Backbone.js ou avec Sammy de Knockout.js, mais ne sont guère différentes, et surtout pas plus complexe ! Places et Activities sont pour moi incontournables pour toute application GWT.
Concernant Request Factory, la complexité existe, je ne vais pas le nier (surtout si vous commencez à regarder ce qui se passe sous le capot). La plus grosse erreur selon moi est d’appréhender Request Factory comme une API à l’instar de GWT-RPC : Request Factory est avant tout un protocole, on y réfléchit en terme de requêtes HTTP et non en terme d’appels de méthodes. J’admet que Request Factory n’est pas encore utilisable à très grande échelle dans GWT 2.4, mais j’ai une demi-douzaine de patches qui devraient être intégrés dans GWT 2.5. Ceci dit, impossible ici de comparer avec du non-GWT: il n’y a à ma connaissance aucun équivalent (ni même à GWT-RPC). Si on veut comparer avec une approche “sans GWT”, j’imagine qu’il faut plutôt regarder du côté de RequestBuilder et, au choix, les JavaScriptObjects avec JsonUtils, ou les AutoBeans.
Difficulté d’accès aux “dernières fonctionnalités HTML5” : si on utilise GWT pour “faire du Java”, on va droit dans le mur. Quand on utilise GWT, on a beau écrire du Java, on fait quand même du JavaScript, et on se doit de connaître JavaScript, HTML et CSS. L’utilisation de JavaScript dans une application GWT est simplissime avec JSNI. Il n’y a qu’à regarder le code derrière les Media API, Canvas ou encore TypedArrays récemment ajoutés à GWT : n’importe qui peut le faire. À Atol nous avons par exemple utilisé pushState pour la gestion de l’historique et File API pour de l’upload de fichiers, avec les Progress Events de XMLHttpRequest et un <progress> HTML5. Si j’ai implémenté le premier (une centaine de lignes de code), le reste a été implémenté par un développeur, certes senior, mais avec une expérience “moyenne” en développement Web. D’autres développeurs dans l’équipe ont wrappé OpenLayers derrière des JavaScriptObject pour nous permettre de faire de la cartographie relativement avancée, en GWT. Tous ces développeurs avaient une expérience zéro avec GWT au début du projet.
# Que nous apporte GWT alors ?
Qu’on l’aime ou pas, le typage statique de Java (ou dans une certaines mesure Dart) lui permet un certain nombre d’outils de développement qu’un langage dynamiquement typé comme JavaScript peut difficilement proposer (à moins de l’annoter à la sauce Closure Compiler par exemple), ne serait-ce que l’auto-complétion et l’aide au refactoring. Ce même typage statique permet également à GWT des optimisations bien plus importantes qu’un Closure Compiler.
L’utilisation de Java permet également la réutilisation de code côté client et serveur, chose possible désormais en JavaScript avec Node.js également (ou Rhino), mais Node.js est bien moins répandu (et il faut arriver à le “vendre” à nos clients), ainsi que la réutilisation de code client sur différentes plateformes (Request Factory fonctionne très bien dans une application Android par exemple).
Le debug est encore un point fort, même s’il ne le restera pas longtemps, notamment avec l’arrivée des Source Maps dans les navigateurs (pour le moment uniquement Chrome) qui permettent de voir le code “en clair” lorsqu’on debug une application dont le JavaScript a été transformé et/ou optimisé (GWT, Closure Compiler, CoffeeScript, etc.)
Pour le reste, JavaScript a bien évolué et propose désormais tests unitaires avec calcul de la couverture de code, runtime hors navigateur (utile pour les tests automatisés), etc.
# Des points faibles peut-être ?
Bien sûr !
GWT est basé sur le “browser sniffing”, donc fragile quant aux évolutions des navigateurs, et il faudra recompiler son application avec une version plus récente de GWT si on veut être sûr d’être compatible avec les derniers versions des navigateurs (pas en ce qui concerne les nouvelles fonctionnalités, mais pour les contournements de bugs). Il faut bien évidemment mettre à jour son framework JavaScript également (ne serait-ce que pour prendre en compte les nouveaux bugs des navigateurs !), mais la nécessité est moins grande qu’avec GWT. La compilation “spécifiquement optimisée pour le navigateur” (par exemple, ne pas envoyer à Firefox du code ou des CSS qui ne serait utilisés que dans Internet Explorer ou Chrome) n’est pas optionnelle dans GWT, contrairement à Closure Compiler par exemple. Ce n’est pas une limitation de GWT en soit, mais un parti pris dans les premières versions, qui nécessiterait un refactoring important de la _user library_ actuelle : loin d’être impossible, mais tout est une question de priorité.
Le développement et le debug nécessitent un plugin dans le navigateur, ce qui exclut Opera (personne n’a pris le temps d’écrire ce plugin) mais surtout les plateformes mobiles et embarquées (Adobe AIR, Titanium, PhoneGap, et bientôt Metro dans Windows 8), pour lesquelles il sera nécessaire de compiler son application. Pas d’inquiétude cependant, les ingénieurs de Google travaille sur un “super draft mode” sans plugin pour remplacer le “dev mode” actuel ; quelque chose qui ressemblera a priori à ce que peuvent fournir Plovr pour Closure, ou LiveReload, Express Coffee ou Sprockets pour LESS, SASS et/ou CoffeeScript. GWT est également déjà capable de générer les Source Maps, ce qui devrait permettre dès à présent le debug des applications mobiles avec Chrome pour Android.
La documentation “officielle” est loin d’être à la hauteur, c’est pour ça que j’ai écrit une série d’articles l’an dernier sur les Places et Activities, l’Editor framework, et Request Factory (qu’il faudra que je mette à jour), dont une partie est traduite en français sur ce blog.
# TL;DR
GWT a toute sa place dans les développements Web actuels, ni plus ni moins qu’un autre, n’en déplaise à Florent Garin. Ce n’est pas une silver bullet comme pourrait le laisser penser Sami Jaber : comme tout outil, il a ses qualités et ses défauts. Quant à la complexité évoquée par Ludovic Borie et les autres, GWT n’est pas plus complexe qu’un framework JavaScript au regard des fonctionnalités fournies, ou que JavaEE ; comme pour tout, il faut avoir assimilé les concepts et ensuite tout roule.
Je ne peux cependant qu’être d’accord avec Florent Garin lorsqu’il écrit “[qu’]aucun développeur IT ne peut continuer à […] bouder [JavaScript]” : comme je le dis plus haut, utiliser GWT, c’est faire du JavaScript. Il est difficile aujourd’hui de ne pas faire de développement web alors effectivement JavaScript est incontournable (pour moi, JavaScript reste encore majoritairement un langage pour le web).
12 mars 2012 at 17 h 30 min
Merci pour ce billet intéressant et documenté. J’apprécie d’avoir l’avis de quelqu’un qui sait ici de quoi il parle !
16 mars 2012 at 7 h 40 min
Merci pour cet article que j’ai trouvé sur le blog de developpez.com, je sens qu’on va aller de bonnes surprises en bonnes surprises au fur et à mesure des nouvelles versions de GWT !
30 mai 2012 at 20 h 25 min
Salut Thomas,
là on sent bien le niveau … très bon article, merci !
en tant que débutant qui cherche à comprendre gwt en profondeur, je suis heureux de constater qu’il y a quelques francophones la dessous !
quid de cette issue justement (http://code.google.com/p/google-web-toolkit/issues/detail?id=6794) je me disais aussi que j’avais déjà vu ce nom à qqpart 😉
concernant GXT, tu penses quoi de la v3 ? perso, je trouve qu’ils ont fait un bel effort pour coller avec GWT, mais je voudrais avoir l’avis d’un expert ?
++
31 mai 2012 at 9 h 59 min
Je n’ai pas encore regardé GXT 3 en détails, mais il semble qu’enfin on a quelque chose « d’utilisable » (dans le sens où il faut selon moi –et c’est un avis partagé par nombre d’autres développeurs– fuir comme la peste GXT 2)
Concernant l’issue 6794, il faudra attendre GWT 2.6 (pas encore planifiée). On travaille dur (à titre perso, avec l’équipe de Google et Stephen Haberman) pour sortir GWT 2.5 d’ici la fin du mois de juin (grosso-modo pour Google I/O), avec une 2.5.1 qui devrait suivre pour la rentrée. Si jamais je trouve le temps et la motivation, le correctif fera peut-être partie de cette 2.5.1, mais rien n’est moins sûr…
7 août 2012 at 9 h 00 min
Malheureusement, ces articles sont des discussions de concepteurs, qui voient les technologies de haut, sans les utiliser quotidiennement.
Lorsque vous descendez un peu, et que vous développez réellement avec GWT (depuis 2 ans dans mon cas), vous vous frottez à la dure réalité, c’est-à-dire que dès que votre code GWT dépasse la centaine de classes :
– la compilation dure plusieurs minutes
– le mode Dev n’est alors plus utilisable (trop lent), et le cauchemar commence :
– plus de possibilité de débugger
– impossible de comprendre le fonctionnement du module sur lequel vous devez agir
– le CSS est très difficile à écrire puisqu’il faut étudier le HTML généré par le Javascript généré par GWT
– au moment où vous êtes confrontés à une différence de fonctionnement entre deux browsers, ce qui arrive un jour ou l’autre, vous êtes incapables de le corriger
Même en restant à un niveau conceptuel, on voit bien que la tendance est à « déclarer » une interface en XML (HTML) plutôt qu’à tout coder. La plupart des entreprises qui utilisent GWT finissent par développer un outil de génération de code à partir d’un XML (UIBinder).
GWT est une régression par rapport aux avancées faites dans le domaine de l’écriture de l’IHM avec des langages dédiés : HTML, CSS, Javascript. C’est le retour de Swing !
Vous parlez de « typage faible », je parlerais de typage abstrait, qui permet de ne pas avoir à déclarer en dur chaque ligne de donnée de chaque noeud de l’arborescence. C’est comme cela qu’on écrit une application de 2 millions de lignes en Java avec 20 000 lignes en interprété.
Y a-t-il une application Google développée en GWT ?
20 août 2012 at 9 h 47 min
Atol CD est utilisateur de GWT depuis un peu plus de 4 ans, sur des projets de milliers de classes et dizaines de milliers de lignes de code (cf. https://groups.google.com/d/msg/google-web-toolkit/gmjBVWgy2dk/jbSvWLPkqagJ par exemple). Il faut effectivement une machine puissante (et surtout sérieusement équipée en RAM; 4Go minimum, 8Go recommandé) pour avoir un environnement de développement « plaisant à utiliser », mais nous utilisons le DevMode tous les jours, sans même avoir pris la peine de découper le projet en « mini applications » (qui réduirait la taille du classpath et donnerait de meilleures performances en DevMode).
Concernant les CSS, les classes utilisées par défaut par les widgets sont documentées dans leur JavaDoc, et je ne vois pas bien la différence avec un autre système de widget (ExtJS, jQuery UI, etc.)
Concernant les différences entre navigateurs, je ne vois pas une grande différence par rapport à un outillage pûrement JS, et en aucun cas on ne saurai être dans l’impossibilité de le corriger (on emploiera un workaround ou, comme pour une lib JS, on patchera; ou si on a du devant nous, on se contentera de remonter le bug et d’attendre le correctif).
Enfin, Google a plusieurs applications écrites en GWT (en tout ou partie): AdWords et Checkout pour commencer (là d’où Google tire la plupart de ses revenus), ensuite Groups, Blogger et Orkut pour les plus « visibles », ainsi que Flights, Web Fonts, Moderator, Gerrit, etc. La partie IHM des Google Apps Script (le UI Service) repose également sur GWT (compilé à la volée).