Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par benwit

0PARTAGES

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

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de glebreton
Membre du Club https://www.developpez.com
Le 07/06/2008 à 12:32
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.
0  0 
Avatar de mamelouk
Membre éclairé https://www.developpez.com
Le 07/06/2008 à 16:28
merci

l'historique est géré dans GWT : il suffit de rajouter la balise
Code : Sélectionner tout
<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.
0  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 07/06/2008 à 16:58
Citation Envoyé par glebreton Voir le message

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

Citation 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.
0  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 07/06/2008 à 17:13
Citation Envoyé par mamelouk Voir le message

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.

Citation 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 ...
0  0 
Avatar de djo.mos
Expert éminent https://www.developpez.com
Le 07/06/2008 à 18:36
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.
0  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 07/06/2008 à 18:52
Citation 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.

Citation 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.
0  0 
Avatar de mamelouk
Membre éclairé https://www.developpez.com
Le 07/06/2008 à 20:40
Citation Envoyé par djo.mos Voir le message

- 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 ?
0  0 
Avatar de mamelouk
Membre éclairé https://www.developpez.com
Le 07/06/2008 à 20:43
Citation Envoyé par djo.mos Voir le message

- 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
0  0 
Avatar de djo.mos
Expert éminent https://www.developpez.com
Le 07/06/2008 à 21:57
Citation Envoyé par benwit
Je pense que tu veux dire fourni par GWT ??? Tu fais trop de Wicket !
vi en effet.

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

Citation 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.
0  0 
Avatar de darkxan
Membre averti https://www.developpez.com
Le 07/06/2008 à 22:31
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.
0  0