Il y a 3 ans, lorsqu’il s’agissait de définir le socle technique d’une nouvelle application web, en l’absence de contraintes exogènes, GWT (Google Web Toolkit) était pour nous un choix naturel pour le développement de la partie « front web ». Les arguments massue de l’époque étaient le manque de portabilité de JavaScript, son faible niveau d’outillage par rapport à Java et aussi la grande difficulté que l’on peut rencontrer à développer une large application avec un langage aussi dynamique et faiblement typé que JavaScript. Face à ces écueils, GWT représentait le rempart absolu, la solution ultime.

Aujourd’hui toutefois, les choses ont de mon point de vue quelque peu évolué.
Tout d’abord, le support de navigateurs obsolètes, comme Internet Explorer 6 par exemple, n’est plus l’obsession des DSI qui par contre tiennent de plus en plus à ce que leurs applications offrent également un bon rendu sur les dispositifs mobiles et tactiles.

Ensuite, l’écosystème JavaScript a progressé. Si les jQuery et autres Prototype existaient déjà il y a 3-4 ans, des frameworks de plus haut niveau tels que Backbone.js, JavaScriptMVC, s’appuyant d’ailleurs sur jQuery, ont fait leur apparition. Ceux-ci aident à fournir un cadre à la structuration des applications de grandes tailles, point délicat lorsque le volume de JavaScript devient important. Des moteurs de templates côté client comme mustache ou des starter kits, à l’instar de bootstrap twitter, sont également venus enrichir l’offre JavaScript.

Côté GWT aussi les lignes ont bougé, passés les premiers instants d’émerveillement, quelques défauts se sont fait sentir. Le premier d’entre eux est l’absence d’une vraie bibliothèque de widgets solide et pérenne. GWT étant avant tout un socle technique, Google laisse à la communauté ou aux éditeurs tiers le soin de bâtir sur son framework. Ainsi Ex GWT, SmartGWT, Vaadin pour ne citer qu’eux disposent de composants de plus haut niveau, prêt à l’emploi. Malheureusement ces bibliothèques n’ont jamais donné pleinement satisfaction : licence peu « business friendly », adhérence importante, problème de qualité. Au final, la sagesse recommande de se contenter de GWT et de tout développer soi-même…
Par ailleurs, GWT, au fil des versions, a gagné en complexité, le pattern « activities/places » pour être correctement employé exige que les développeurs soient bien formés ; RequestFactory, CellWidget sont des nouveautés qu’il conviendra à nouveau d’assimiler et qui contraindront la migration d’un bon nombre d’applications.
En outre, si GWT parvient à éloigner complètement JavaScript du développeur, il ne le préserve pas de CSS qui tend à prendre de plus en plus d’importance et devient une nouvelle source d’incompatibilité entre les navigateurs. On touche finalement au coeur du problème : GWT est une abstraction imparfaite ; cette encapsulation des technologies web ne dispense pas les développeurs d’en comprendre les arcanes.

Conclusion
Pour répondre très concrètement à la question posée par ce billet : oui GWT est toujours pertinent surtout s’il s’agit d’implémenter une grosse application de gestion avec des développeurs de niveau hétérogène. Par contre, pour une application innovante, faisant un usage prononcé des dernières fonctionnalités HTML5 (3D, communication temps réel) il est avantageux d’être en prise directe avec le browser (bare metal).
Quoi qu’il en soit, ce qui était annoncé à la sortie du framework de Google ne s’est pas produit : JavaScript n’est pas devenu l’assembleur du web. Qu’on le déplore ou non, ce langage est aujourd’hui incontournable, son champ d’application dépasse d’ailleurs largement le cadre du navigateur (CommonJS). Aucun développeur IT ne peut continuer à le bouder.