Faiblesses de GWT [Débat]

[benwit]

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

Envoyé par djo.mos

Toutefois, d'après mes lectures, le point noir de GWT est le fait que les DTOs doivent implémenter une interface particulière (de GWT) ... ça, c'est vraiment "chiant" (excusez l'expression) et inadmissible à mon avis car il impose soit de:
- faire que les objets métiers/dtos dépendent du fwk d'affichage ... plutôt mourir
- garder deux hiérachies d'objets (objets métier et DTOs) tout en gérant les conversions ... plutôt mourir !

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 ...

[glebreton]

J'ai pas énormément utilisé cette techno, mais d'après ce que j'ai pu voir, GWT souffre de deux gros défauts :

• L'obligation d'utiliser le JDK 1.4 ou inférieur. Vu les améliorations apportées pas la version 5 de Java (annotations, énumérations, generics), c'est, à mon avis, pas normal qu'une telle techno ne les supporte pas. Ceci dit, j'ai vu qu'il y a une nouvelle version de GWT en préparation qui devrait supporter la version 5.
• Je rejoins la personne que tu as citée, je pense que c'est le principal défaut de GWT.

[mamelouk]

merci

l'historique est géré dans GWT : il suffit de rajouter la balise

Code :

<iframe id="__gwt_historyFrame" style="width:0;height:0;border:0"></iframe>

pour moi le fait que GWT force à coder un site en java est son PLUS GROS avantage. je n'ai jamais touché une ligne de javascript et je suis capable de faire des sites web de dernières génération.

par contre, bien vu pour l'indexation je n'y avais pas pensé (mais vu que mon appli tourne avec google maps il y a des trucs qui sont prevus pour les crawler). je vais me renseigner, je suis sur qu'ils y ont pensé chez google quand meme..

si tu as une page qui as une partie fixe et une partie dynamique, tu marque l'endroit ou tu veut que ta partie dynamique soit avec un ID et dans ton code java tu fait Root.get(ID).add(tes_widgets)

pour ceux qui utilisent hibernate, il existe hibernate4gwt pour les problèmes de proxy. je n'avais pas pensé à ce problème tellement il est léger (un application bien faite utiliser des pattern pour passer ses POJO d'une couche de l'application à une autre). et puis, comment fait-on dans les autres frameworks AJAX?

glebreton, la dernière version de GWT vient de sortir, elle supporte Java 1.5, les annotations etc.

[benwit]

Envoyé par glebreton

L'obligation d'utiliser le JDK 1.4 ou inférieur. Vu les améliorations apportées pas la version 5 de Java (annotations, énumérations, generics), c'est, à mon avis, pas normal qu'une telle techno ne les supporte pas. Ceci dit, j'ai vu qu'il y a une nouvelle version de GWT en préparation qui devrait supporter la version 5.

La version 1.5 est sortie et ce n'est donc plus vraiment un défaut. Cependant, garder à l'esprit que si la syntaxe du 1.5 est prise en compte (annotation, generics, ellipse, boucle simplifiée, ...), l'émulation du JRE par GWT (pour la conversion en JS) bien que transparente et bien qu'augmentant le nombre de classes au fil des versions reste à l'origine d'erreurs chez les débutants.
http://code.google.com/webtoolkit/do...ation/jre.html

Envoyé par mamelouk

l'historique est géré dans GWT : il suffit de rajouter la balise

Effectivement, comme je le disais, les concepteurs ont prévu un mécanisme.
Cependant, de là à dire que ça suffit de rajouter cette balise, je trouve que tu y vas un peu fort ! Elle est certes nécessaire mais pas suffisante.
Il faut en plus implémenter l'interface appropriée HistoryListener et sa méthode onHistoryChanged. Rien de très très compliqué mais je voulais juste souligné qu'il y a quelque chose à faire.

[benwit]

Envoyé par mamelouk

pour moi le fait que GWT force à coder un site en java est son PLUS GROS avantage. je n'ai jamais touché une ligne de javascript et je suis capable de faire des sites web de dernières génération.

Pour les application web, je suis bien d'accord. Vouloir écrire des interfaces graphiques seulement en XML est une gageure dans la mesure où il faudra à un moment ou à un autre du code de script pour faire des trucs un peu élaborés (même si cela ne représente que 5% du total).

Pour l'indexation, il y a des techniques quand même sinon se serait mal venu de la part de google.

Envoyé par mamelouk

si tu as une page qui as une partie fixe et une partie dynamique, tu marque l'endroit ou tu veut que ta partie dynamique soit avec un ID et dans ton code java tu fait Root.get(ID).add(tes_widgets)

Merci mais je sais. Sauf que les widgets Java que tu insères, ils sont bien quelques part codés en Javascript dans un module. S'ils sont dans ton module principal ou dans un autre module lié, ils feront partis du "javascript monobloc" généré à la compilation et cela ne résout pas mon problème. Si c'est au moment de l'action d'insertion des widgets que le module supplémentaire contenant les dits widgets est téléchargé par le client, tu m'apprends un truc mais je doute que ce soit le cas ??? A creuser ...

[djo.mos]

Bonjour,
en fait, je ne parlais pas du cas des proxies, car ça, c'est un problème plus général et n'estpas spécifique à GWT.
Je parlais plutôt du mécansime du RPC de GWT et des limitations qu'il impose:
- Les objets de tansfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)
- Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.

Pour le premier point, ça m'oblige soit à polluer mes pojos métier avec une interface GWT pas question, ou encore créer une autre hiérachie d'objets de transferts dépendant de GWT ainsi que le code de conversion de et vers mes POJOs casse gueule dans une application suffisamment conséquente.

Je pense notamment à un autre moyen pour faire du RPC (remoting) qui est hessian: lles objets transférables sont des pojos ordinaires, de même pour les services, à aucun momeent je ne lie mon code à la lib de remoting.

[benwit]

Envoyé par djo.mos

- Les objets de transfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)

Je pense que tu veux dire fourni par GWT ??? Tu fais trop de Wicket !
Ce n'est plus obligé depuis la dernière version, Serializable peut suffire.
Dans le groupe GWT, ils expliquent leur choix initial par un problème de sémantique : leur IsSerializable signifiait serialisable en javascript, ce qui est différent de l'interface Serializable de sun. Mais suite aux critiques des utilisateurs qui savent ce qu'ils font , ce n'est plus requis.

Envoyé par djo.mos

- Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.

Cela, je suis bien d'accord, c'est mal foutu. Il auraient pu faire mieux.
Personnellement, j'ai détourner leur système en faisant à GWT ce que le MVC2 a fait au MVC .
J'ai fait "un super service" qui envoit/reçoit les objets que je veux.
Pour chaque service SS, cela m'évite d'écrire :

• l'interface SSServiceAsync,
• l'interface SSService qui étend leur RemoteService,
• et la classe d'implémentation SSServiceImpl qui étend leur RemoteServiceServlet.

[mamelouk]

Envoyé par djo.mos

- Les objets de tansfert qui doivent implémenter IsSerialisable (interface fourni par Wicket)

je savais pas que c'était impossible de travailler sans implémenter IsSerializable alors je l'ai fait...

moi mes POJO implément rien de spécial et le transfert se passe très bien ?

[mamelouk]

Envoyé par djo.mos

- Dans une moindre mesure, les interfaces de services qui doivent implémenter RemoteService.

est ce que vous m'éclairer en m'expliquant pourquoi c'est pas bien? moi ca m'a donné l'occasion d'aborder les Servlet en douceur (je connaissais rien à ce concept)

A part le fait d'avoir une classe qui a pour suffixe ASync (ce qui devrait disparaitre à l'avenir), je vois vraiment pas le problème

[djo.mos]

Envoyé par benwit

Je pense que tu veux dire fourni par GWT ??? Tu fais trop de Wicket !

vi en effet.

Envoyé par benwit

Ce n'est plus obligé depuis la dernière version, Serializable peut suffire.
Dans le groupe GWT, ils expliquent leur choix initial par un problème de sémantique : leur IsSerializable signifiait serialisable en javascript, ce qui est différent de l'interface Serializable de sun. Mais suite aux critiques des utilisateurs qui savent ce qu'ils font , ce n'est plus requis.

Oki, mon point ne tient plus la route dans ce cas, et tant mieux ! La première approche etait pour le moins pénible.

Ca répond aussi à mamelouk

je savais pas que c'était impossible de travailler sans implémenter IsSerializable alors je l'ai fait...

moi mes POJO implément rien de spécial et le transfert se passe très bien ?

Je savais pas que les versions courantes n'imposent plus cette limite.

Envoyé par mamelouk

est ce que vous m'éclairer en m'expliquant pourquoi c'est pas bien? moi ca m'a donné l'occasion d'aborder les Servlet en douceur (je connaissais rien à ce concept)

A part le fait d'avoir une classe qui a pour suffixe ASync (ce qui devrait disparaitre à l'avenir), je vois vraiment pas le problème

Bah le simple fait que je suis obligé de faire un adapter GWT-ready pour chacun de mes services est un problème: ça ajoute beaucoup de code inutile à mon application. Je dis inutile car comme j'en ai déjà parlé, il existe plusieurs solutions de remoting qui n'imposent pas une pareille limitations et qui exposent directement mes services, sans que je sois obligé de les adapter.

[darkxan]

Pour répondre aux histoires de POJO :

Serializable User-defined Classes
A user-defined class is serializable if

1. it is assignable to IsSerializable or Serializable, either because it directly implements one of these interfaces or because it derives from a superclass that does
2. all non-final, non-transient instance fields are themselves serializable, and
3. it has a public default (zero argument) constructor

The transient keyword is honored, so values in transient fields are not exchanged during RPCs. Fields that are declared final are also not exchanged during RPCs, so they should generally be marked transient as well.

Source: documentation version 1.4

J’avais déjà posté mes critiques sur GWT dans l’autre sujet, je les remets en forme ici :

- L'intégration n'est pas parfaite avec l'existant. Je trouve qu’une nouvelle technologie devrait toujours s’intégrer parfaitement avec ce qui est déjà existant pour éviter de perdre tout ce qui était intéressant dans les autres technologies.
Pour ma part, je voulais utiliser Spring et Hibernate. Dans le cas de Spring, ça se passe plutôt bien avec GWT-SL. On peut concentrer tous ces contrôleurs. Dans le cas d’Hibernate, c’est un peu plus la merde dans le sens où Hibernate utilise des proxys pour les collections. Avec Gwt4Hibernate, on ne s’en sort pas trop mal, mais il y a du progrès à faire.

- Il y a relativement peu de Widgets de base. On peut pallier ça avec GWT-Ext et ExtJs. Par contre, ce dernier vient de changer de licence pour passer en GPL...

- Il n'impose rien dans le domaine de l’architecture et cela peut vite devenir inmaintenable si quelque chose n'est pas fait de ce côté. Alors que dans les frameworks classiques, on suit le traditionnel MVC qui nous permet d’avoir quelque chose de bien rodé.

- On utilise du Javascript donc ça pose un souci vis-à-vis de l'évolution des navigateurs. Firefox 3.0, Internet Explorer 8.0 ? Vu que l’on ne contrôle pas le processus de génération du Javascript cela pourrait être un problème.

- La vision tournée « monopage » (enfin, c'est comme ça que je le vois) ne s'adapte pas toujours à ce que l'on recherche. Cela rejoint la remarque nº 5.

[benwit]

Envoyé par darkxan

- Il y a relativement peu de Widgets de base. On peut pallier ça avec GWT-Ext et ExtJs. Par contre, ce dernier vient de changer de licence pour passer en GPL...

C'est vrai que ça manque encore de widgets mais cela ne pourra que s'améliorer avec le temps ...

GWT-Ext, ça m'a beaucoup plus initialement mais depuis les histoires de licences, ça m'a un peu refroidit ...
D'un coté, on a GWT-Ext (développé initialement par Sanjiv) qui est un wrapper des librairies de Ext-JS (les libs d'ext sont requises).
De l'autre, on a Ext-GWT (ex MyGWT développé initialement par Darell) qui définit en pur GWT des composants au même look and feel que Ext-JS)

Puisque le premier projet est plus dépendant de l'évolution d'Ext-JS, j'aurai préféré que ce soit celui-ci qui rejoigne l'équipe de Jack Slocum. Malheureusement, c'est l'inverse qui s'est produit, ajoutant la confusion des noms et provoquant la création de fork ...

Envoyé par darkxan

- Il n'impose rien dans le domaine de l’architecture et cela peut vite devenir inmaintenable si quelque chose n'est pas fait de ce côté. Alors que dans les frameworks classiques, on suit le traditionnel MVC qui nous permet d’avoir quelque chose de bien rodé.

C'est un avantage si on veut se faire sa propre architecture (c'est possible de faire du MVC) mais sinon, ta remarque est pertinente.

Envoyé par darkxan

- On utilise du Javascript donc ça pose un souci vis-à-vis de l'évolution des navigateurs. Firefox 3.0, Internet Explorer 8.0 ? Vu que l’on ne contrôle pas le processus de génération du Javascript cela pourrait être un problème.

Cela pourrait être un problème mais je ne m'inquiète pas trop là dessus.
Premièrement, parce que c'est Google, il s'entend bien avec la fondation Mozilla et/ou est capable de nous pondre un navigateur s'il le souhaite .
Deuxièmement, parce que GWT c'est principalement un compilo et je pense qu'on pourrait l'adapter à d'autres langages de scripts.

[darkxan]

GWT-Ext, ça m'a beaucoup plus initialement mais depuis les histoires de licences, ça m'a un peu refroidit ...

Pour ma part, j'utilise GWT-Ext 2.0.3 et Ext-Js 2.0.2 (version proposant du LGPL). Normalement, il n'y a pas de problème de licence. Par contre, je vais être bloqué avec l'utilisation de la version 2.0.2 et donc de tous les bugs qui vont avec...
Note : Il y a plein de Widgets vraiment sympathique par contre, on perd parfois la force de l'Ajax : c'est-à-dire son dynamisme. En effet, avec certains Layouts il n'y a plus la possibilité de faire des modifications, un comble pour du Javascript !

C'est un avantage si on veut se faire sa propre architecture (c'est possible de faire du MVC) mais sinon, ta remarque est pertinente.

Je suis d'accord que c'est un avantage, mais nous ne sommes pas tous architecte. Et je suis forcé de constater que ce n'est pas mon cas. D'ailleurs, je n'ai pas trop vu d'articles là-dessus. J'en ai vu quelques-uns et les solutions me faisaient froid dans le dos.

Pour ma part, je pense utiliser le design pattern « Command » pour découpler tout ce qui est RPC et les modifications de l'interface de mes composants. Dans mon cas, cela s'adapte bien mais je ne suis pas sûr que cela soit bien pour tous les cas.

Dans un premier temps, j'avais essayé d'utiliser un ensemble d'actions. Le composant graphique récupère une action (qui hérite une classe abstraite) via une fabrique et invoque la méthode « execute ». L'utilisation de la classe abstraite permet de gérer les logs, les exceptions, possiblement la gestion des droits. Par contre, je ne trouvais pas ça terrible au niveau de la modification de la vue. C'est pour ça que la notion de « Receiver » du pattern « Command » est intéressant dans mon cas.

Cela pourrait être un problème mais je ne m'inquiète pas trop là dessus.

J'ai remarqué que mon code ne marche déjà plus sous FF 1.5 donc j'ai eu un coup de stress avec FF 3.0 et IE 8.0.

[Caroline76]

Nous utilisons GWT pour des applications et pas pour des sites web (ou alors, seulement des petits modules), donc l'historique ou le mono-page n'est pas vraiment un probleme.

Pour les objets metiers, je genere des classes utilisables par mon client (maven le fait), mais des methodes de conversion doivent etre ecrites. C'est un peu lourd, ca fait du travail en plus, et c'est source de bug, mais nous n'avons pas trouve d'autre solution.

Programmer AJAX en Java, c'est super, mais j'ai eu des bugs lorsque mes objets n'etaient pas "supprimer" par un garbage collector non present, ou different de celui de java, dans JS (que je connais tres peu), donc perte de temps une fois de plus.

Sinon, nous sommes globalement satisfaits de cette technologie.

[dolfendo]

Salut benwit,Je pense que ce débat est très instructif pour toute la communauté qui aime gwt.J'ai pas compris ton entendement sur cette partie

Code :

1
2
 
Les concepteurs ayant imaginé un mécanisme de gestion de l'historique, il tend à disparaître

peux tu m'éclairer stp.
Merçi

[fluff]

Si j'ai bien compris l'internationalisation de Gwt, le fichier properties se met dans le package client et tout se fait en local notamment le changement de langue....
Ça simplifie le programme (pas d'accès serveur, pas de recompilation....) mais donne les inconvénients cités.

[tatemilio2]

Concernant le manque de composant graphiques, et les soucis de licence GWT-Ext, aujourd'hui vers quel wrapper vous allez vous tourner ? (si on souhaite avoir de l'open source total).
Que pensez-vous de SmartClient ? j'ai fais un tour sur la démo, perso je trouve que cela rame.

[benwit]

Envoyé par dolfendo

Salut benwit,Je pense que ce débat est très instructif pour toute la communauté qui aime gwt.J'ai pas compris ton entendement sur cette partie

Code :

peux tu m'éclairer stp.
Merçi

Avec les applications et sites web classiques, on passe d'une page à une autre.
Le navigateur garde l'historique de navigation de manière à pouvoir revenir en arrière ...

Avec les applications et sites utilisant AJAX, on modifie uniquement une partie de la page.
Certaines personnes disent que c'est un problème car pour l'utilisateur lambda, ça n'a plus le comportement habituel :
L'interface graphique change mais il ne peut plus revenir en arrière ...
Ce qui est normal puisque l'adresse de la page n'a pas changé pour le navigateur qui n'a pas renseigné son historique.

Ce problème tend à disparaître avec GWT car les concepteurs ont prévu un mécanisme (avec l'iframe) qui permet dans son application GWT de gérer l'historique du navigateur. On peut donc développer en AJAX, modifier une page partiellement et modifier l'historique de manière à avoir un comportement classique (L'utilisateur peut revenir à l'état précédent avec le bouton de retour).

Puisque le mécanisme est prévu, je pense que ce n'est plus un véritable problème.
Si on veut éviter d'avoir un historique, c'est plutôt un avantage !
Mais si on veut l'historique similaire à ce qu'on aurait en mode classique (page à page), c'est une petite faiblesse. "Petite" car on peut le faire, "faiblesse" car quoi qu'on en dise, cela fait un truc de plus à gérer.

J'espère avoir été plus clair.

[Tommy31]

Envoyé par tatemilio2

Concernant le manque de composant graphiques, et les soucis de licence GWT-Ext, aujourd'hui vers quel wrapper vous allez vous tourner ? (si on souhaite avoir de l'open source total).
Que pensez-vous de SmartClient ? j'ai fais un tour sur la démo, perso je trouve que cela rame.

J'en reste à Ext-js et le binding gwt associé. C'est pas du 100% gwt, mais l'avantage est que la lib ext-js est bien développé, relativement compacte et performante.

J'ai pas mené de benchmark mais j'ai l'impression que le compilateur produit un code js assez peu performant en regard de ce que l'on peu faire à la main. Faudrait que je mène des tests avec le 1.5.

[benwit]

Envoyé par fluff

Si j'ai bien compris l'internationalisation de Gwt, le fichier properties se met dans le package client et tout se fait en local notamment le changement de langue....
Ça simplifie le programme (pas d'accès serveur, pas de recompilation....) mais donne les inconvénients cités.

Si j'ai bien compris (corriger moi si je me trompe), l'internationalisation de GWT peut se faire de deux manières différentes :

La méthode statique
Elle consiste à avoir des fichiers de propriétés par langue (ensemble de clé/valeur) dans son package client. Le compilateur GWT remplace les clés du code source java par les valeurs lors de la fabrication du code javascript. C'est pour cela qu'il génère autant de versions compilées que de langues.
Comme le remplacement se fait à la compilation, il peut indiquer des erreurs comme le manquement d'une clé.
L'intéret, c'est qu'une fois les fichiers js envoyé sur le poste client, ce dernier dispose d'une version intégrale dans une langue sans avoir besoin de rappeler le serveur. La contrepartie, c'est que pour changer de langue, il faut rajouter un paramètre de locale dans l'url et re-télécharger la version pour la nouvelle langue.
Un autre inconvénient, c'est que pour modifier une chaine de caractère, si vous pouvez modifier uniquement le fichier de propriété sans toucher au code, il faudra quand même recompiler.

La méthode dynamique
Cette méthode utilise des dictionnaires embarqué dans le code js généré. Le remplacement peut se faire dynamiquement dans la partie cliente. L'intérêt est de pouvoir modifier les chaines directement dans le fichier js généré car elles sont regroupés dans un même tableau javascript (le dictionnaire) contrairement au cas précédent où elles sont un peu partout.

Dans les deux cas il n'y a plus d'accès serveur une fois le code client sur le client. Dans le cas du statique, une recompilation est obligatoire (à moins que vous ne faisiez un recherche remplace dans le code js généré à vos risques et périls)