Débat : Les inconvénients et faiblesses de GWT (Google Web Toolkit)

Bonjour,

Cette discussion fait suite à la réaction de Mamelouk sur un article de mon blog (http://blog.developpez.com/benwit?ti...blesses_de_gwt)

Je n'y faisais qu'exprimer mon opinion mais vu qu'il semble vouloir en débattre, je vous propose d'en discuter ici.

Pour commencer, je tiens à préciser que j'aime beaucoup cette techno. Et même s'il m'arrive de parler d'inconvénients, le terme de faiblesses est plus en adéquation avec le fond de ma pensée.
Je crois que c'est aux gens qui aiment une techno, qui veulent la défendre d'essayer d'être le plus objectif en pointant sur ces "faiblesses" qu'un évangéliste passerait sous silence.
C'est en soulignant ses limites qu'on peut l'utiliser à bon escient, faire de ces faiblesses des forces, voire trouver des "parades" pour les contourner.

#1 - Le fait de coder en JAVA son IHM
Je conçois que c'est une "faiblesse" pour ceux qui veulent faire un site web (au sens original du terme : un graphe de documents) que de le coder en Java (Swing like). Et ne me dites pas que personne ne le dit car j'ai pu le lire sur ce forum.
Je leur répond que GWT n'est pas fait pour cela. GWT est fait pour écrire des applications web riches (Ajaxifiés) et pour éviter ce que l'on nomme le "XML Hell". Si on garde à l'esprit ceci, ce n'est pas une faiblesse si on reste dans son champ d'application. En revanche, si on le compare à d'autres frameworks qui permettent de faire indifféremment "application" ou "site", c'en est une.

#2 - La gestion de l'historique
Ce problème inhérent aux applications AJAX qui ne rechargent qu'une partie de leur page pourrait être un problème de GWT. Les concepteurs ayant imaginé un mécanisme de gestion de l'historique, il tend à disparaître. Cependant, je pense que ça reste une petite "faiblesse" dans la mesure où il faut le gérer soit même si on fait un site classique.
Dans le domaine de prédilection de GWT (le développement d'application), c'est une force ! En ne faisant rien, ça évite que l'utilisateur passe l'application dans un état non souhaité. Et au besoin, on peut le gérer comme on veux.

#3 - L'indexation par les moteurs de recherche
Là encore, l'approche GWT (tout en javascript) est une faiblesse pour la réalisation de "sites classiques". En revanche, pour les applications, je ne crois pas que ça ait un sens qu'un moteur indexe une vue de l'application.

#4 - L'internationalisation
GWT offre plusieurs mécanismes pour "internationaliser" son application. L'approche statique qui consiste à embarquer les chaînes de caractères dans le code généré et à générer une version par locale se défend. Les faiblesses que j'y trouve : écrire une méthode d'interface pour chaque libellé à traduire, recompiler le code aux changements de texte.
Quand à leur approche dynamique, si j'ai bien compris, je la trouve assez pauvre : un "dictionnaire" embarqué dans la page que l'on peut modifier en éditant le fichier html (http://google-web-toolkit.googlecode...1.4/index.html).
Si cela évite la recompilation des modifications et l'écriture de méthode par libellé à traduire, cela apporte les autres inconvénients qu'ils citent.
Ces faiblesses là sont plus personnelles car je préfère un vrai service d'internationalisation, gérer par le serveur, qui permet de modifier à chaud les libellés, qui permet d'avoir plusieurs implémentations possibles (ficher de config, base de données, ...). C'est possible mais il faut le faire soi même.

#5 - Les modules
Avec GWT, la philosophie est de ne plus penser en terme de pages. L'idée de regrouper tout le code Javascript dans un unique fichier se défend également pour les avantages évoqués par les concepteurs. Personnellement, je ne suis pas séduit par cette approche dans le cas d'une application très riches en "écrans".
Si on choisit de tout mettre dans un module, celui-ci tend à devenir obèse. Si c'est une légère faiblesse de taille de transfert sur le réseau (téléchargé la 1° fois, débits augmentant avec le temps ...) ou à l'éxecution (on peut différer le chargement de certaines parties), à la compilation, ça devient de plus en plus long.
Si on choisit de faire plusieurs modules et de la navigation par hyperliens, cela se défend pour des "sous ensembles fonctionnels".
On navigue de l'un à l'autre en retombant dans un mode page à page alors ? Entre cette gestion d'historique entre modules et à l'intérieur d'un module, même si ça semble possible, ça doit être pas si simple à mettre en œuvre.
Et comment faire si vous avez une partie fixe ? réaliser les parties variables avec des modules et les charger dans des iframes ??? J'ai essayé et je n'ai pas été convaincu. Je veux bien reconnaître cependant qu'en dehors de mon application particulière, ce n'est pas vraiment une faiblesse.
J'ai trouvé une façon de contourner cette faiblesse en ayant un module javascript de taille fixe quelque soit la "grandeur" de mon application.

#6 - L'intégration des données des POJO

La solution que j'utilise pour résoudre les faiblesses du point 5 m'ont masqué ce point. Mais je n'ai pas suffisamment essayé cette partie pour savoir s'il s'agit vraiment d'une faiblesse ou non ? Avant gwt 1.5, les annotations des POJO étaient bloquantes. Mais je ne suis pas sûr que le problème des "proxy" des ORM soit résolu avec l'arrivée de gwt 1.5 ?
En revanche, je crois que les objets "métiers" ne pourront pas être traduit en javascript dans tous les cas et ça peut être une difficulté pour certains.

A vous ...