Les plus grands pièges de GWT ?

Question

Je suis au début/milieu d'un projet que nous avons choisi de mettre en œuvre en utilisant GWT. Quelqu'un a-t-il rencontré des écueils majeurs dans l'utilisation de GWT (et GWT-EXT) qui n'ont pas pu être surmontés ? Et du point de vue des performances ?

Voici quelques exemples de ce que nous avons déjà vu/entendu :

• Google ne parvient pas à indexer le contenu
• Les CSS et le stylisme en général semblent être un peu instables.

Je suis également à la recherche de tout commentaire supplémentaire sur ces articles. Merci.

Answer 1

Je vais commencer par dire que je suis un grand fan de GWT, mais oui il y a beaucoup de pièges, mais la plupart si ce n'est tous nous avons été en mesure de surmonter :

Problème : Temps de compilation longs. Plus votre projet grandit, plus le temps de compilation est long. J'ai entendu parler de compilations de 20 minutes, mais les miennes durent en moyenne 1 minute.

Solution : Divisez votre code en modules séparés, et dites à ant de ne le construire que lorsqu'il est modifié. De plus, pendant le développement, vous pouvez accélérer massivement les temps de compilation en ne construisant que pour un seul navigateur. Vous pouvez le faire en mettant ceci dans votre fichier .gwt.xml :

<set-property name="user.agent" value="gecko1_8" />

Où gecko1_8 est Firefox 2+, ie6 est IE, etc.

---

Problème : Le mode hébergé est très lent (du moins sous OS X) et est loin de correspondre aux modifications "en direct" que vous obtenez lorsque vous modifiez des éléments tels que des pages JSP ou Rails et que vous appuyez sur le bouton de rafraîchissement de votre navigateur.

Solution : Vous pouvez donner au mode hébergé plus de mémoire (j'ai généralement 512M) mais c'est toujours lent, j'ai trouvé qu'une fois que vous êtes assez bon avec GWT vous arrêtez d'utiliser cela. Vous faites un grand nombre de changements, puis compilez pour un seul navigateur (généralement 20s de compilation) et puis appuyez simplement sur rafraîchir dans votre navigateur.

Mise à jour : Avec GWT 2.0+ ce n'est plus un problème, parce que vous utilisez le nouveau 'Development Mode'. Cela signifie essentiellement que vous pouvez exécuter le code directement dans votre navigateur de choix, donc pas de perte de vitesse, plus vous pouvez firebug/inspecter, etc.

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

---

Problème : Le code GWT est java, et a une mentalité différente de la mise en page HTML, ce qui rend plus difficile de prendre un design HTML et de le transformer en GWT.

Solution : Encore une fois, on s'y habitue, mais malheureusement, convertir un design HTML en un design GWT sera toujours plus lent que de faire quelque chose comme convertir un design HTML en une page JSP.

---

Problème : GWT demande un peu de temps pour s'y retrouver, et n'est pas encore très répandu. Cela signifie que la plupart des développeurs qui rejoignent votre équipe ou maintiennent votre code devront l'apprendre à partir de zéro.

Solution : Il reste à voir si GWT va décoller, mais si vous êtes une entreprise qui contrôle les personnes qu'elle embauche, alors vous pouvez toujours choisir des personnes qui connaissent GWT ou qui veulent l'apprendre.

---

Problème : GWT est un marteau de forgeron comparé à quelque chose comme jquery ou simplement javascript. Il faut beaucoup plus de configuration pour que ça fonctionne que de simplement inclure un fichier JS.

Solution : Utilisez des bibliothèques comme jquery pour les tâches simples et plus petites qui leur sont adaptées. Utilisez GWT lorsque vous voulez construire quelque chose de vraiment complexe en AJAX, ou lorsque vous avez besoin de faire passer vos données dans les deux sens via le mécanisme RPC.

---

Problème : Parfois, afin de remplir votre page GWT, vous devez faire un appel au serveur lors du premier chargement de la page. Il peut être ennuyeux pour l'utilisateur de rester assis là et de regarder un symbole de chargement pendant que vous récupérez les données dont vous avez besoin.

Solution : Dans le cas d'une page JSP, votre page a déjà été rendue par le serveur avant de devenir HTML, donc vous pouvez faire tous vos appels GWT à ce moment-là, et les précharger sur la page, pour un chargement instantané. Voir ici pour plus de détails :

Accélérer le chargement de la page en pré-sérialisant vos appels GWT

---

Je n'ai jamais eu de problèmes avec le stylisme CSS de mes widgets, qu'ils soient prêts à l'emploi, personnalisés ou non, donc je ne vois pas ce que vous entendez par là ?

En ce qui concerne les performances, j'ai toujours trouvé qu'une fois compilé le code GWT est rapide, et les appels AJAX sont presque toujours plus petits que de faire un rafraîchissement de la page entière, mais ce n'est pas vraiment unique à GWT, bien que les paquets RPC natifs que vous obtenez si vous utilisez un back-end JAVA sont assez compacts.

Answer 2

Nous travaillons avec gwt depuis presque 2 ans. Nous avons appris beaucoup de choses. Voici ce que nous pensons :

1. N'utilisez pas de bibliothèques de widgets tiers, en particulier gwt-ext. Cela nuira à vos performances en matière de débogage, de développement et d'exécution. Si vous avez des questions sur la façon dont cela se produit, contactez-moi directement.

2. Utilisez gwt pour remplir uniquement les parties dynamiques de vos applications. Ainsi, si vous avez des interactions complexes avec l'utilisateur, avec beaucoup de champs. Cependant, n'utilisez pas les panneaux qui l'accompagnent. Prenez vos pages existantes fournies par un designer de stock. Découpez les zones qui contiendront les contrôles de votre application. Attachez ces contrôles à la page dans la fonction onModuleLoad(). De cette façon, vous pouvez utiliser les pages standard de votre concepteur et aussi faire tout le style en dehors de la gwt.

3. Ne construisez pas l'ensemble de l'application sous la forme d'une page standard dont tous les éléments seraient ensuite construits de manière dynamique. Si vous faites ce que je suggère au point 2, cela n'arrivera pas de toute façon. Si vous construisez tout dynamiquement, vous allez réduire les performances et consommer d'énormes quantités de mémoire pour les applications de taille moyenne à grande. En outre, si vous faites ce que je suggère, le bouton retour fonctionnera parfaitement, tout comme l'indexation par les moteurs de recherche, etc.

Les autres commentateurs ont également fait de bonnes suggestions. La règle de base que j'utilise est de créer des pages comme si vous faisiez une page Web standard. Découpez ensuite les éléments qui doivent être dynamiques. Remplacez-les par des éléments qui ont des identifiants et utilisez ensuite RootPanel.get( id ).add( widget ) pour remplir ces zones.

Answer 3

Les pièges que nous avons rencontrés :

• Alors que vous pouvez obtenir beaucoup de kilométrage en utilisant quelque chose comme GWT EXT, chaque fois que vous utilisez ce genre de placage mince sur une bibliothèque JavaScript, vous perdez la capacité de déboguer. Plus d'une fois j'ai frappé ma tête sur le bureau parce que je ne peux pas inspecter (dans mon débogueur IntelliJ) ce qui se passe dans la classe de table GWT EXT... Tout ce que vous pouvez voir est que c'est un JavaScriptObject. Cela rend assez difficile de comprendre ce qui a mal tourné...

• Ne pas avoir quelqu'un dans votre équipe qui connaisse le CSS. D'après mon expérience, le fait que cette personne ne soit pas un expert n'a pas d'importance... il suffit qu'elle ait une bonne connaissance pratique et qu'elle connaisse les bons termes à chercher sur Google si nécessaire.

• Débogage sur plusieurs navigateurs. Gardez un œil sur le mode hébergé Out of Process[ 1 ][ 2 ][ 3 ], en espérant qu'elle arrive dans GWT 1.6... Pour l'instant, vous devez juste obtenir des choses bien avec le mode hébergé, puis utiliser le bouton "Compile/Browse", où vous pouvez jouer avec d'autres navigateurs. Pour moi, qui travaille sur Windows, cela signifie que je peux voir mon travail dans FireFox, et utiliser FireBug pour aider à peaufiner et améliorer les choses.

• IE6. Il est étonnant de constater à quel point IE 6 rend les choses différemment. J'ai adopté l'approche consistant à appliquer un style au "viewport" le plus extérieur en fonction du navigateur, de sorte que je peux avoir des règles CSS du type :

  .my-style { /* stuff that works most everywhere */ }
  
  .msie6 .my-style { /* "override" so that styles work on IE 6 */ }

Enfin, veillez à utiliser un éditeur qui vous aide. J'utilise IntelliJ - il a beaucoup d'intelligence GWT. Par exemple, si j'essaye d'utiliser une classe qui n'est pas gérée par l'émulation JRE, il me le fait savoir ; si je spécifie un style pour un widget, et que je n'ai pas encore défini ce style, le code obtient les petites taches rouges... Ou, en regardant le CSS, il me dira quand j'ai spécifié des attributs conflictuels dans une seule règle. (Je ne l'ai pas encore essayé, mais je comprends que la version 8 a un support GWT encore meilleur, comme garder les interfaces et implémentations RPC "locales" et "async" synchronisées).

Answer 4

GWT 2.0, qui est censé sortir au cours des prochains mois, résout un grand nombre des problèmes discutés.

• Créer des mises en page à l'aide d'une syntaxe de type html/xml
• Chargement dynamique des script - seul le JS essentiel sera téléchargé initialement. Le reste sera téléchargé au fur et à mesure des besoins
• Mode hébergé dans le navigateur - Cela pourrait résoudre les problèmes de vitesse du mode hébergé, entre autres avantages.
• "Optimisations du compilateur" - Compilation plus rapide, espérons-le.

Vidéo de l'aperçu de GWT 2.0 à la Google I/O

Answer 5

Pas "impossible à surmonter" mais un peu pénible pour quelque chose de basique.

Traitement des dates :

GWT utilise la version obsolète java.util.Date ce qui peut entraîner un comportement inattendu lors du traitement des dates du côté client. java.util.Calendar n'est pas pris en charge par GWT. Plus d'informations ici .

Exemples de problèmes connexes :

• GWT java.util.Date bug de sérialisation
• Obtenir les détails de la date (jour, mois, année) dans GWT
• Support des fuseaux horaires côté client dans GWT