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

Tags
Réseaux sociaux


 Discussion forum

Le , par benwit, Rédacteur
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 ...


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de inconnu652000 inconnu652000
http://www.developpez.com
Membre habitué
le 03/08/2009 16:50
Il est maintenant depuis qque temps d'ailleurs de controler GWT via spring et de faire de l'injection de dépendance dedans je crois qu'il est également possible d'utiliser GWT comme IHM pour les portlets 2.0 (jsr 268 je crois).

GWT a de moins en moins de limitations.
Avatar de djmalo djmalo
http://www.developpez.com
Membre à l'essai
le 23/02/2011 18:20
Pour moi la plus grosse faiblesse de GWT c'est le layouting.
Imbriquer par exemple un CaptionPanel dans un TabLayoutPanel avec scrollbar ca parait tout bête.
Dans GWT c'est un cauchemard.
Bug à gogo: Scrollbars qui n'apparaissent pas, CaptionPanel qui déborde sur le TabLayoutPanel, TabLayoutPanel qui déborde la taille de l'écran sans raison.
Des exemple comme ça il y'en a à la pelle.
Parfois on insère au milieu un autre type de Panel et miracle ça marche, parfois non.
A chaque écran j'ai eu envie de me tirer une belle dans la tête à un moment ou un autre.
Avatar de pvoncken pvoncken
http://www.developpez.com
Membre éclairé
le 24/02/2011 9:45
Je pense que c'est important de bien maitriser les Css pour pouvoir gérer ses écrans convenablement.

Sur mes appli j'utilise beaucoup le FlowPanel, qui ne sont que des dv html, et je leur fix des classes css que je controle avec mon Css. Ca me permet de faire des écrans qui fonctionnent correctement avec tout les navigateurs, mais j'avoue que si certaines notions de css ne sont pas comprises ca peut rendre fou.
Avatar de valkeke valkeke
http://www.developpez.com
Membre régulier
le 15/09/2011 12:15
j'arrive un peu tard mais c'est mon actualité : Dev en GWT, donc j'essaie de poursuivre le débat aujourd'hui !

pvoncken dit
Sur mes appli j'utilise beaucoup le FlowPanel, qui ne sont que des dv html, et je leur fix des classes css que je controle avec mon Css. Ca me permet de faire des écrans qui fonctionnent correctement avec tout les navigateurs, mais j'avoue que si certaines notions de css ne sont pas comprises ca peut rendre fou.

si je comprends bien tu utilises abondament ce panel et tu modifies son comportement grâce à la classe de CSS que tu lui appliques.
c'est cela que je trouve bizarre, moi j'essaie d'utiliser( je fais peut-être mauvaise route !) tous les différents panels mis à ma disposition(FlowPanel, VerticalPanel, DockLayoutPanel..etc...j'utilise souvent moi FlexTable.......en essayant de préférence d'employer les panel qui se transforme en div ensuite à la place de table!) afin d'agencer mon IHM comme voulu et je me sers de la CSS seulement pour modifier seulement sa présentation(background, border, font,....voir margin, padding si nécessaire : comme ils disent "à la SWING" : agencement de panel/layout. J'ai codé bcp de client lourd dans ma jeunesse!)mais je n'essaie pas de modifier son comportement ou son positionnement comme on ferait avec une JSP pour structurer ma page (position, overload ..)

j'ai peut-être mal compris ton propos ?

Ma conclusion aujourd'hui: GWT permet de coder l'IHM tout en java; oui mais on a besoin de sérieuse compétence en CSS si on veut réaliser des IHM un peu sexy.... en plus de temps en temps ça facilite le rendu final d'injecter de l'HTML, non ??
cela me choque pas trop car la cible c'est le web->navigateur web.
votre avis m'intéresse sur ces remarques.......pour savoir par exemple s'il faut que j'achète un livre sur CSS afin de monter en compétence....
Avatar de pvoncken pvoncken
http://www.developpez.com
Membre éclairé
le 15/09/2011 17:03
Monter en compétence sur Css est une très bonne idée qui te servira pour Gwt et pour tous tes autres projets Web, aujourd'hui et dans le futur.

C'est une stratégie cohérente d'utiliser tous les panel que google met à disposition avec Gwt. Surtout si tu ne maitrise pas completement les Css. Ils sont fait pour ca, donc il n'y a pas de souci sur ce point.

Après, pour ceux qui maîtrisent Css, c'est beaucoup plus puissant de n'utiliser que des FlowPanel auxquels on fixe des nom de class Css afin de manipuler leur présentation (et pas leur comportement). Le positionnement fait parti de la présentation et pas du comportement.

En réalisant ton appli avec des FlowPanel, tu peux changer entirement la présentation juste en changeant la feuille de style. Mieux encore, tu peux définir une feuille de style par média, afin que ton appli soient compatible avec des smartphones, des tablettes ou des desktop ou même des téléviseurs... (voir mediaquery)

Il ne s'agit en fait que d'utiliser les Css dans le but pour lequels ils ont été créé.

Un conseil, au lieu d'acheter un livre, tu peux commencer par consulter des sites et des ressources disponibles sur la toile et qui font le tour des bases et qui sont vraiment bien fait.

-edit- une précision pour les flowpanel, personnellement j'étands les flowpanels et je fixe la class Css dans le constructeur de ma nouvelle classe que je peux ainsi réutiliser de manière factorisée.
Avatar de valkeke valkeke
http://www.developpez.com
Membre régulier
le 24/09/2011 18:03
l'idée a fait son chemin...
tu dis
C'est une stratégie cohérente d'utiliser tous les panel que google met à disposition avec Gwt. Surtout si tu ne maitrise pas completement les Css. Ils sont fait pour ca, donc il n'y a pas de souci sur ce point.

j'en étais persuadé au moment ou tu l'as dit mais ......+ je code des DockLayoutPanel, enchainé avec des ScrollPanel et des VerticalPanel, FlexTable.....un bon mélange ... à la manière swing du à mon historique de developpeur....GWT a pu en + avoir ce style d'argument !
Je me dis Maintenant que c'est pas si bête ....j'étais loin LOIN d'être convaincu par ce que tu disais
beaucoup plus puissant de n'utiliser que des FlowPanel auxquels on fixe des nom de class Css afin de manipuler leur présentation (et pas leur comportement)

Tout ça pour dire : est-ce qu'il y a bcp de gens
qui font comme pvoncken (FlowPanel et ensuite CSS) car de l’expertise forte en CSS : tout se passe bien!
ou
composition des différents layouts mis à disposition (au départ RootLayoutPanel ..puis...DockLayoutPanel avec des HorizontalPanel, SimplePanel, FlexTable..etc..etc....)
là MOI du bidouillage de code ! car comportement bizarre; voir difficulté à savoir qu'est-ce qui cloche?
je pense m'y prendre pas trop mal avec les layout (à la mode swing : c'est peut-être mon tort?) et vous ?
difficile de donnée des exemples précis!
Avatar de lnplnp lnplnp
http://www.developpez.com
Nouveau Membre du Club
le 20/09/2012 10:07
Salut,

Citation Envoyé par benwit  Voir le message
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.

Je serai curieux de voir comment tu garanties une taille fixe pour un module JS même si l'application évolue et augmente en terme de fonctionnalité... à moins d'avoir mal compris ce que tu voulais dire...

++
Avatar de benwit benwit
http://www.developpez.com
Rédacteur
le 20/09/2012 16:11
Tu as bien compris.

Je te rassure, en théorie tu as raison, si mon application GWT augmente en fonctionnalités, le code javascript généré augmente bien.

Sauf qu'en pratique :

mon application GWT n'est pas une application métier mais une méta-application qui est un "viewer GWT" côté client. Elle consiste à afficher des composants graphiques (le modèle de cette méta-application) et à réagir à des évènements. Bien entendu, si j'ajoute de nouveaux composant graphiques élémentaires, le code JS croit. Sauf qu'au bout d'un moment, avec un nombre de widgets assez large qui couvre la plupart des besoins, le code JS tend à ne plus évoluer.

mon application métier, elle, est une application pur serveur. Lorsque l'application métier croit en fonctionnalités, j'ai bien entendu plus de vues (code Java côté serveur) mais ces vues sont constitués de composants élémentaires envoyés par RPC sous forme de données au viewer GWT qui les affiche.

Tu comprend le principe ?
Avatar de lnplnp lnplnp
http://www.developpez.com
Nouveau Membre du Club
le 21/09/2012 16:15
Citation Envoyé par benwit  Voir le message
Bien entendu, si j'ajoute de nouveaux composant graphiques élémentaires, le code JS croit. Sauf qu'au bout d'un moment, avec un nombre de widgets assez large qui couvre la plupart des besoins, le code JS tend à ne plus évoluer.

Tu comprend le principe ?

oui, je comprend le principe.

Je comprend que le code JS ne croît pas proportionnellement au nombre de widgets utilisés mais bien au nombre de widgets développés... quoiqu'on peut réutiliser dans de nombreux cas, une base de code commune.
La phrase citée dans mon précédent post, laisser croire, à mon sens, que tu avais trouvé la formule magique pour tout coder en une seule fois... ce que je ne conçois pas.
Le nombre de ligne de code croît plutôt de manière logarithmique et non exponentielle, heureusement !
Avatar de karbos karbos
http://www.developpez.com
Membre confirmé
le 20/11/2012 10:10
Pour rebondir sur ce que tu dis lnp, je préciserais que GWT propose une technique de code-splitting, qui consiste à fragmenter le code javascript sur plusieurs fichiers et à l'injecter dans le DOM à la demande du client. C'est une des principales amélioration de la version 2.5 (novembre 2012).
Cette dernière version commence à fournir un Framework vraiment productif, à l'heure où on cherche de plus en plus à avoir des interfaces riches et réutilisables sur plusieurs périphériques (Serveur, bureautique, domestique, smartphone, tablette, etc.). Personnellement je crois que GWT ouvre une petite passerelle timide entre JAVA et HTML5... A suivre
Avatar de sub_zero sub_zero
http://www.developpez.com
Nouveau Membre du Club
le 22/11/2012 1:25
C'est peut être un détail, mais par exemple sous GWT je trouve absurde de ne pas pouvoir utiliser plusieurs fois un Widget que l'on a instancié. Mais je crois que cette limitation se trouve également dans Swing.

Sinon je suis d'accord avec djmalo pour les problèmes de LayoutPanel et les scrollbar qui ne sont pas là alors qu'elle devraient l'être ..
Offres d'emploi IT
Ingénieur de production informatique (H/F)
CDI
INTERNATIONAL RFID SOLUTIONS IRIS-RFID - Bretagne - Brest (29200)
Parue le 18/10/2014
Spécialiste infrastructure si h/f
CDI
Société Générale France - Ile de France - Paris (75000)
Parue le 06/10/2014
Analyste développeur c# .net
CDI
Apside - Ile de France - Boulogne-Billancourt (92100)
Parue le 01/10/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula