Les plus grands pièges du GWT? [fermé]

Je suis au début / au milieu d'un projet que nous avons choisi de mettre en œuvre avec 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? Qu'en est-il du point de vue de la performance?

Quelques choses que nous avons déjà vues / entendues incluent:

• Google ne peut pas indexer le contenu
• CSS et le style en général semblent être un peu floconneux

Vous recherchez également des commentaires supplémentaires sur ces éléments. Merci!

Je vais commencer par dire que je suis un grand fan de GWT, mais oui, il y a de nombreux pièges, mais la plupart sinon tous nous avons pu surmonter:

Problème: temps de compilation longs, à mesure que votre projet grandit, le temps nécessaire pour le compiler augmente également. J'ai entendu parler de rapports de compilations de 20 minutes, mais les miennes durent en moyenne 1 minute environ.

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 considérablement accélérer les temps de compilation en ne construisant que pour un 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 (sur OS X au moins) et ne correspond pas aux changements `` en direct '' que vous obtenez lorsque vous modifiez des éléments tels que des pages JSP ou Rails et que vous appuyez sur Actualiser dans votre navigateur.

Solution: vous pouvez donner plus de mémoire au mode hébergé (j'en ai généralement pour 512M) mais c'est toujours lent, j'ai trouvé qu'une fois que vous êtes assez bon avec GWT, vous arrêtez de l'utiliser. Vous apportez une grande partie des modifications, puis compilez pour un seul navigateur (généralement 20s de compilation), puis appuyez simplement sur Actualiser dans votre navigateur.

Mise à jour: avec GWT 2.0+, ce n'est plus un problème, car vous utilisez le nouveau «Mode de développement». Cela signifie essentiellement que vous pouvez exécuter du code directement dans le navigateur de votre choix, donc pas de perte de vitesse, plus vous pouvez le firebug / l'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 d'une page HTML, ce qui rend plus difficile la prise d'une conception HTML et sa transformation en GWT

Solution: Encore une fois, vous vous y habituez, mais malheureusement, la conversion d'une conception HTML en une conception GWT sera toujours plus lente que de faire quelque chose comme la conversion d'une conception HTML en une page JSP.

Problème: GWT prend un peu de temps et n'est pas encore courant. 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 qui vous embauchez, vous pouvez toujours choisir des personnes qui connaissent GWT ou veulent l'apprendre.

Problème: GWT est un marteau comparé à quelque chose comme jquery ou tout simplement javascript. Il faut beaucoup plus de configuration pour le faire que d'inclure simplement un fichier JS.

Solution: utilisez des bibliothèques telles que jquery pour des tâches plus petites et simples qui leur conviennent. Utilisez GWT lorsque vous souhaitez créer quelque chose de vraiment complexe dans AJAX, ou lorsque vous devez transmettre vos données dans les deux sens via le mécanisme RPC.

Problème: Parfois, pour remplir votre page GWT, vous devez passer un appel au serveur lors du premier chargement de la page. Il peut être ennuyeux pour l'utilisateur de s'asseoir 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, vous pouvez donc effectuer tous vos appels GWT ensuite, et les précharger sur la page, pour un chargement instantané. Voir ici pour plus de détails:

Accélérez le chargement des pages en pré-sérialisant vos appels GWT

Je n'ai jamais eu de problèmes avec le style CSS de mes widgets, prêts à l'emploi, personnalisés ou autres, donc je ne sais pas ce que vous entendez par là un piège?

En ce qui concerne les performances, j'ai toujours trouvé qu'une fois compilé le code GWT est rapide et que les appels AJAX sont presque toujours plus petits que l'actualisation d'une 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 est assez compact.

Nous travaillons avec gwt depuis près de 2 ans. Nous avons appris beaucoup de leçons. Voici ce que nous pensons:

1. N'utilisez pas de bibliothèques de widgets tierces, en particulier gwt-ext. Cela tuera vos performances 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 ne remplir que les parties dynamiques de vos applications. Donc, si vous avez des interactions utilisateur complexes avec de nombreux champs. Cependant, n'utilisez pas les panneaux qui l'accompagnent. Prenez vos pages fournies par le concepteur de stock existant. Découpez les zones qui contiendront les commandes de votre application. Attachez ces contrôles à la page dans onModuleLoad (). De cette façon, vous pouvez utiliser les pages standard de votre concepteur et également faire tout le style en dehors du gwt.

3. Ne créez pas l'ensemble de l'application comme une page standard qui construit ensuite dynamiquement toutes les pièces. Si vous faites ce que je suggère au point 2, cela n'arrivera pas de toute façon. Si vous construisez tout de manière dynamique, vous allez tuer les performances et consommer d'énormes quantités de mémoire pour les applications de taille moyenne à grande. De plus, si vous faites ce que je suggère, le bouton de retour fonctionnera très bien, tout comme l'indexation des moteurs de recherche, etc.

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

Pièges que nous avons rencontrés:

• Bien que vous puissiez gagner beaucoup de temps en utilisant quelque chose comme GWT EXT, chaque fois que vous utilisez ce type de placage fin au-dessus d'une bibliothèque JavaScript, vous perdez la possibilité de déboguer. Plus d'une fois, je me suis cogné la 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, c'est que c'est un JavaScriptObject. Cela rend assez difficile de comprendre ce qui ne va pas ...

• Ne pas avoir quelqu'un dans votre équipe qui connaisse CSS. D'après mon expérience, peu importe que la personne ne soit pas experte ... il suffit qu'elle ait de bonnes connaissances pratiques et qu'elle connaisse les bons termes pour rechercher sur Google si nécessaire.

• Débogage entre les navigateurs. Gardez un œil sur le mode hébergé hors processus [ 1 ] [ 2 ] [ 3 ], avec un peu de chance dans GWT 1.6 ... Pour l'instant, il vous suffit de faire le bon travail avec le mode hébergé, puis d'utiliser le bouton "Compiler / Parcourir" , où vous pouvez jouer avec d'autres navigateurs. Pour moi, travailler sous Windows, cela signifie que je peux voir mon travail dans FireFox et utiliser FireBug pour aider à peaufiner et améliorer les choses.

• IE6. C'est incroyable à quel point IE 6 rendra les choses différentes. J'ai adopté l'approche consistant à appliquer un style à la "fenêtre" la plus externe en fonction du navigateur afin de pouvoir avoir des règles CSS telles que:

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

Enfin, assurez-vous d'utiliser un éditeur qui vous aide. J'utilise IntelliJ - il a beaucoup d'intelligence GWT. Par exemple, si j'essaie d'utiliser une classe qui n'est pas gérée par l'émulation JRE, cela 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 le petit squiggly rouge ... Ou, en regardant le CSS, il me dira quand j'ai spécifié des attributs conflictuels dans un règle unique. (Je ne l'ai pas encore essayé, mais je comprends que la version 8 offre un meilleur support GWT, comme garder les interfaces et implémentations RPC "locales" et "asynchrones" synchronisées.)

GWT 2.0, qui devrait sortir dans les prochains mois, résout un grand nombre des problèmes discutés.

• Créer des mises en page en utilisant une syntaxe semblable à HTML / xml
• Chargement de script dynamique - seul le JS essentiel sera téléchargé initialement. Le reste sera téléchargé au besoin
• Mode hébergé dans le navigateur - Cela peut résoudre les problèmes de vitesse du mode hébergé discutés, entre autres avantages
• "Optimisations du compilateur" - Compilation plus rapide, espérons-le

Vidéo de prévisualisation GWT 2.0 sur Google I / O

Pas "incapable d'être surmonté" mais un peu de douleur pour quelque chose de basique.

Traitement de la date:

GWT utilise la méthode obsolète, java.util.Datece qui peut entraîner un comportement inattendu lors du traitement des dates côté client. java.util.Calendarn'est pas pris en charge par GWT. Plus d'infos ici .

Exemples de problèmes associés:

• Bogue de sérialisation GWT java.util.Date
• Obtenir les détails de la date (jour, mois, année) dans GWT
• Prise en charge du fuseau horaire côté client dans GWT

J'ajouterai quelques points à ceux déjà mentionnés:

• Liaison / validation de données. GWT n'a pas de support de liaison de données / validation prêt à l'emploi, bien que certains projets dans ce domaine commencent à émerger. Vous vous surprendrez à écrire beaucoup de ceci:

TextField fname, faddress;
...
fname.setText (person.getName ());
faddress.setText (person.getAddress ());
...

• Chargement paresseux. Puisque gwt est côté client, le chargement différé n'est vraiment pas une option. Vous devrez concevoir soigneusement vos RPC et vos objets de domaine afin de
  • envoyer toutes vos données d'objet nécessaires
  • évitez de récupérer toutes vos données avec impatience
  • Vous devrez également vous assurer que vous n'enverrez pas de proxies / objets non sérialisables. hibernate4gwt peut vous aider sur ces points.
• Conception de l'interface utilisateur. Il est plus difficile de visualiser une interface utilisateur en java (panneaux, boutons, etc.) qu'en html.
• Support historique. GWT n'est pas livré avec un sous-système Historique, ni avec aucun sous-système pour de belles URL ou un bookmarking complet. Vous devrez lancer le vôtre (bien qu'il prenne en charge les jetons Historique, ce qui est un début). Cela se produit avec toutes les boîtes à outils AJAX AFAIK.

À mon humble avis, il manque à GWT un cadre qui prend en charge immédiatement tous les problèmes mentionnés sur ce «fil».

Je travaille actuellement sur un projet qui utilise EXT GWT (GXT) à ne pas confondre avec GWT EXT. Il y a une différence, EXT GWT est celui qui est réellement produit par la société qui a écrit ExtJS la bibliothèque javascript. GWT EXT est un wrapper GWT autour de la bibliothèque ExtJS. GXT est un GWT natif.

Quoi qu'il en soit, GXT est encore un peu immature et manque d'une communauté solide que je pense que GWT EXT a. Cependant, l'avenir est avec GXT, car il est GWT natif et développé par la société qui a créé ExtJS. GWT EXT est quelque peu paralysé car la licence a changé sur la bibliothèque ExtJS, ralentissant ainsi le développement de GWT EXT.

Dans l'ensemble, je pense que GWT / GXT est une bonne solution pour développer une application Web. En fait, j'aime assez le mode hébergé pour le développement, cela rend les choses rapides et faciles. Vous bénéficiez également de la possibilité de déboguer votre code. Les tests unitaires avec JUnit sont également assez solides. Je n'ai pas encore vu de cadre de test unitaire JavaScript qui me semblait suffisamment mature pour tester une application d'entreprise.

Pour plus d'informations sur GWT EXT: http://gwt-ext.com/

Pour plus d'informations sur EXT GWT (GXT): http://extjs.com/products/gxt/

Pas de pièges majeurs que je n'ai pas pu surmonter facilement. Utilisez fortement le mode hébergé. Comme vous utilisez GWT-ext, vous n'aurez presque jamais besoin de toucher CSS vous-même à moins que vous ne vouliez modifier l'apparence prête à l'emploi.

Ma recommandation est d'utiliser un widget "natif" de GWT sur une bibliothèque où ils sont proches des fonctionnalités.

Re indexation des moteurs de recherche: oui, le site n'aura normalement pas d'URL navigables (sauf si vous n'ajoutez que des widgets à des éléments d'un site Web régulier). Vous pouvez cependant faire une fonction d'historique en arrière / en avant.

J'ai utilisé GWT et GWT-ext ensemble sur un projet il y a quelque temps. J'ai trouvé l'expérience assez fluide en tant que développement Web, mais mon conseil serait le suivant:

Ne mélangez pas les widgets natifs GWT avec les widgets EXT. C'est déroutant comme l'enfer, car généralement les noms sont les mêmes (GWT.Button ou GWText.Button?)

Une chose qui m'est arrivée qui a vraiment rendu le code plus complexe que je ne le souhaiterais, c'est que je voulais un Panel qui soit a) dynamiquement actualisable b) cascadable

Les panneaux natifs GWT sont dynamiques, les panneaux Ext sont en cascade. Solution? Un GWT.VerticalPanel enveloppant un panneau GWTExt ... Chaos. :)

Mais bon, ça marche. ;)

J'appuie le commentaire de ykagano, le plus gros inconvénient est de perdre le V dans MVC. Bien que vous puissiez séparer la vraie classe d'interface utilisateur du reste de votre code côté client, vous ne pouvez pas facilement utiliser une page HTML générée par un graphiste / concepteur Web. Cela signifie que vous avez besoin d'un développeur pour traduire le HTML en java.

Obtenez un éditeur d'interface utilisateur wysiwyg, cela vous fera gagner beaucoup de temps. J'utilise GWTDesigner.

Le plus gros avantage de GWT est de pouvoir oublier les problèmes entre navigateurs. Ce n'est pas 100% mais enlève presque toute cette douleur. Combiné avec l'avantage du débogage en mode hébergé (par opposition à Firebug qui est excellent mais pas le même qu'un débogueur java), il donne au développeur un énorme avantage dans la génération d'applications ajax complexes.

Oh et c'est rapide à l'exécution, surtout si vous utilisez un filtre gzip.

Légèrement hors sujet, mais le canal #gwt sur irc est très utile, au cas où vous auriez un problème persistant.

GWT est assez simple et intuitif.

Surtout avec la sortie d'UIBinder pour permettre aux widgets GWT d'être mis en page en XML, puis codés en Java.

Donc, si vous avez utilisé d'autres outils de conception Ajax ou Flash, ou Silverlight, etc., GWT est très facile à apprendre.

Le principal obstacle, sinon l'écueil, est le GWT RPC. La raison même pour laquelle vous souhaitez utiliser GWT est à cause de GWT async RPC. Sinon, pourquoi ne pas simplement compter sur le CSS pour formater votre page?

GWT RPC est cet élément qui permet à votre serveur d'actualiser les données sur votre serveur sans avoir à actualiser la page. C'est une exigence absolue pour des pages telles que le suivi de la performance des stocks (ou la dette nationale et publique actuelle des États-Unis ou le nombre de bébés à naître avortés dans le monde à la seconde).

GWT RPC demande un certain effort pour comprendre, mais avec quelques heures, tout devrait être clair.

Au-dessus de cela, après avoir fait des efforts pour apprendre GWT RPC, vous découvrez enfin que vous ne pouvez pas utiliser les JSP comme composant de service pour RPC, à moins que ... j'ai une série en 8 parties (je pense) sur mon blog sur la façon d'utiliser JSP en tant que serveur GWT RPC. Cependant, puisque vous n'aviez pas demandé de réponses mais simplement des problèmes, je vais m'abstenir de faire de la publicité pour mon blog.

Alors. Je crois fermement que les pires obstacles / pièges à l'utilisation de GWT sont de savoir comment déployer correctement GWT async RPC et comment lui permettre d'utiliser les serveurs JSP.

Nous avons eu beaucoup de mal à marier notre base de code GWT avec des modèles Web HTML que nous avons obtenus d'un concepteur Web (pages HTML statiques avec des identifiants div spécifiques que nous voulions que GWT gère). Au moins à l'époque où nous l'avons utilisé, nous ne pouvions pas intégrer GWT à des parties de notre site Web qui n'étaient pas codées dans GWT. Nous l'avons fait fonctionner finalement, mais c'était un gros hack.

• L'interface Async que vous devez écrire pour chaque interface de service ressemble à quelque chose qui aurait pu être généré automatiquement par le compilateur GWT.
• Les temps de compilation deviennent longs pour les grands projets

Mais pour un grand projet Javascript, c'est le meilleur choix

GWT 2.4 a résolu bon nombre des problèmes mentionnés ci-dessus et une excellente bibliothèque de widgets vient de sortir de la version bêta (Ext GWT 3.0.4 alias GXT), qui est entièrement écrite en GWT, pas un wrapper d'une bibliothèque JS.

Douleur restante:

• Manque de support du sélecteur CSS3, vous pouvez utiliser "literal ()" dans certains cas pour le contourner.
• Manque de support pour CSS3 et les événements de navigateur modernes tels que transitionEnd .
• Manque de prise en charge de la classe Java Calendar (plusieurs années plus tard).
• Manque de support JUnit4 (5 ans et plus).
• Manque de feuille de route claire et de calendrier de sortie de la part de l'équipe Google GWT.

En ce qui concerne GWT 2.4, utilisez Firefox lors du débogage de GWT, c'est beaucoup plus rapide que d'utiliser Chrome. Et si vous n'utilisez que Firefox, pensez à mettre cette ligne dans votre fichier project.gwt.xml

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

De plus, si vous utilisez eclipse, ajoutez ce qui suit sous arguments -> arguments VM:

-Xmx512m -XX: MaxPermSize = 1024m -XX: PermSize = 1024m

Vous pouvez diviser votre serveur et votre client et utiliser ce qui suit sous arguments -> Arguments du programme: -codeServerPort 9997 -startupUrl http: // yourserver / project -noserver

De plus, pour éviter d'actualiser votre serveur à chaque modification, utilisez JRebel http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ Et voici une démo en direct http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY

Un écueil majeur est que vous devez parfois attribuer explicitement un identifiant à ce qui devient finalement un élément HTML pour pouvoir utiliser certains styles CSS. Par exemple: un TabPanel GWT fera uniquement: survoler tabBarItems lorsque le tabBar du tabPanel a reçu un identifiant et que vous spécifiez un: hover sur cet elementId.

J'ai écrit sur d'autres inconvénients de GWT ailleurs, mais ils sont déjà couverts par la réponse de rustyshelfs :).

J'ai fait beaucoup de travail sur GWT récemment, et c'est ce que je dois dire:

1. Le style CSS n'est parfois délicat, utilisez l'outil de développement IE dans IE et Firebug dans Firefox pour comprendre ce qui se passe exactement et vous aurez une idée claire de ce qui doit être changé.
2. Vous pouvez utiliser des astuces pour demander à Google de l'indexer. Un site très célèbre est http://examples.roughian.com/ vérifier ses notes sur google. Un site beaucoup moins connu est www.salvin.in ( je n'ai pas pu résister à le mentionner), je l'ai optimisé en mots: page d'accueil de salvin (recherchez ces trois mots sur google)

Je ne connais pas grand chose à GWT-EXT, mais je suis moi aussi convaincu qu'il n'est pas nécessaire d'inclure des bibliothèques tierces.

Bonne chance pour votre décision :)

GWT effectue le reniflement du navigateur au lieu de la détection des fonctionnalités et votre application ne fonctionnera pas sur certains navigateurs (en particulier les nouveaux)

Voici quelques références du problème:

• google-web-toolkit Problème 2938: RFE: améliorez le fournisseur de propriétés user.agent pour faire face au "masquage" de la chaîne userAgent
• Iceweasel n'est plus pris en charge? - Aide Google Docs
• Implémentations GWT pour chaque navigateur

Voici quelques références à la détection des fonctionnalités:

• Détection du navigateur (et que faire à la place)
• Détection des fonctionnalités: Scripting de l'état du navigateur d'art
• Détection des fonctionnalités du navigateur

Extrait de Comparaison des frameworks JavaScript - Wikipedia

L'équipe GWT a apporté de nombreuses améliorations importantes par rapport à la sortie de GWT 2.7 l'an dernier. Une faiblesse majeure de GWT était que la compilation prend trop de temps dans GWT 2.6 et versions antérieures. C'est maintenant parti GWT n'a pas de compilation incrémentielle qui est super rapide et ne compile que les modifications.

GWT 2.7 a maintenant ( Source ):

• Des builds incrémentiels maintenant en quelques secondes
• Des SourceMaps plus compactes et plus précises
• Prise en charge GSS
• JSInterop
• Excellentes performances JavaScript
• Taille de code plus petite

L' enquête gwt est la meilleure façon d'obtenir des faits fiables . L'un des plus gros problèmes avec GWT a toujours été une longue période de compilation. Heureusement, cela s'améliore très rapidement, donc ce ne sera pas un problème important dans un proche avenir. Un autre écueil est que GWT est considérablement plus compliqué car Java est un langage plus compliqué qui résiste aux mauvais codeurs à chaque étape du processus. De plus, la compilation ajoute une couche. Par exemple, js interop nécessite un petit passe-partout. Le problème fondamental est que GWT n'a pas été conçu pour être simple. Il a été conçu dès le départ pour des applications Web extrêmement complexes et l'ensemble de la communauté priorise systématiquement, les performances, la qualité du code, l'architecture, etc. par rapport à un codage facile.
N'oubliez pas que vous pouvez utiliser js dans GWT à tout moment, donc si vous avez des problèmes avec GWT, envisagez d'utiliser js. À la fin de la journée, GWT est js, vous pouvez donc faire tout ce que vous pouvez dans GWT dans js. En fait, la plupart des projets GWT utilisent js. Le problème est que GWT est radicalement plus compliqué. Néanmoins, cela vaut parfois la complexité supplémentaire.

Il convient de noter que GWT 3.0 apportera des améliorations massives.

Réutilisation des objets de service RPC.
Cela provoque des conditions de concurrence avec des symptômes qui ressemblent à une suspension de l'application.

Pièges que j'ai rencontrés 1. Comportement différent en mode superdev. Par exemple, Someclass.class.getName () fonctionne parfaitement en mode Superdev et renvoie le nom complet de la classe. En mode productif, cela ne fonctionne pas.

2. addWidget (widget) appellera le widget removefromparent ()

GWT est un chef-d'œuvre technologique. Il unit la programmation client et serveur, ce qui en fait une application cohérente - la façon dont le logiciel était écrit avant la «superposition», et la façon dont il devrait être écrit. Il élimine les différents ensembles de compétences, les problèmes de communication entre les membres de l'équipe et généralement toute la phase de conception Web: à la fois artistique et de programmation. Et c'est le plus proche du développement mobile, par exemple Android. En fait, GWT a été conçu pour générer différentes interfaces utilisateur natives, pas seulement du HTML. Bien que cela nécessite une énorme discipline pour assurer un tel découplage - pour garder vos couches internes indépendantes de la présentation.

La première erreur à éviter, qui m'a pris quatre ans à réaliser, consiste à utiliser des extensions tierces comme EXT-GWT alias GXT et SmartGWT. Il est très tentant de commencer à utiliser leurs jolis widgets de bureau au lieu d'investir dans votre propre style, mais je ne peux pas dire combien de problèmes j'ai eu avec SmartGWT jusqu'à ce que j'en ai finalement marre. En bref, il gèle l'ensemble des fonctionnalités de base de GWT à un certain niveau (assez obsolète), puis s'appuie sur celui-ci. Gardez également à l'esprit que l'apparence et la sensation de bureau ciselées semblent ridicules de nos jours, sans parler des performances lentes, des tonnes de bogues et des fonctionnalités de compatibilité, en particulier sur les appareils mobiles. Vous voulez rester aussi proche que possible des contrôles natifs du navigateur, c'est-à-dire des listes déroulantes rendues sous forme d'éléments <select> natifs, et non de contrôles personnalisés.

Grâce aux tendances mobiles, l'UX dans son ensemble devient plus simple et plus plat, vous n'avez donc pas besoin de faire grand-chose pour styliser une application nette. Cependant, si vous voulez un look "3D", il existe également des dégradés. CSS3 a tout simplifié et GWT l'enveloppe d'une manière élégante orientée objet, contrairement au CSS brut. Alors ne vous découragez pas en regardant des commandes barebones plutôt laides dans la vitrine GWT. L'équipe GWT n'a intentionnellement offert aucun style, car c'est le travail du développeur.

Le reste est une programmation de navigateur à peu près conventionnelle en Java fortement typé avec de belles API concises. Mais bien sûr, ne jamais oublier que votre code s'exécute dans le navigateur, donc tous les appels sont asynchrones, par exemple, vous ne pouvez pas appeler les méthodes GWT-RPC dans une boucle (pour remplir une liste), mais vous devez les enchaîner de manière récursive si vous en venez à cela situation.

Il existe des "anti-modèles" auto-proclamés comme ne pas utiliser GWT-RPC. Cela m'a fait du bien jusqu'à présent: pendant 10 ans. La simplicité est la clé. Je ne penserais même pas une seconde à sacrifier des performances marginales pour l'élégance du code et la maintenabilité. de plus, ce n'est pas là que seraient vos goulots d'étranglement - dans la base de données. Bien sûr, faites attention à la quantité de données que vous envoyez au client.

Et si vous ne parvenez pas à trouver ou à styliser le gadget existant - lisez l'ensemble d'éléments HTML5 riches, vous pouvez toujours en envelopper un tiers. Je l'ai fait avec un jQuery FullCalendar populaire. Pas du tout sorcier. Tout le reste, comme Google Maps et Google Charts, a des wrappers GWT semi-officiels.

GWT est parfait. La seule raison pour laquelle il ne reçoit pas assez d'amour est que les premiers utilisateurs d'Internet qui influencent encore l'industrie ne sont pas venus de l'informatique et des langages orientés objet pour les apprécier. Ils ont une expérience artistique (Photoshop / WordPress) ou réseau (Perl / Python).