J'envisage d'utiliser GWT dans le cadre d'un projet de développement d'applications Web interne majeur. À mes yeux, le principal avantage est la compilation croisée sur Javascript qui aiderait (du moins théoriquement) mon équipe à réduire la taille de la pile technologique d'un seul. .
Cependant, après avoir été brûlé auparavant (comme la plupart des développeurs), j'aimerais que les programmeurs l'utilisent réellement pour résoudre tout problème lié à GWT qui gênerait ou limiterait son utilisation dans un domaine de problèmes donné.
Quels sont les arguments contre l'utilisation de GWT et pourquoi?
java
javascript
ajax
gwt
Jas
la source
la source
Réponses:
Je suis à la fois bon et mauvais de répondre à cette question - bon, en ce sens que je l’avais déjà utilisée auparavant, et mauvais en ce sens que j’étais assez expérimenté en HTML / CSS / JavaScript avant de travailler avec GWT. Cela m'a rendu fou d'utiliser GWT d'une manière que d'autres développeurs Java qui ne connaissent pas DHTML n'ont peut-être pas été.
GWT fait ce qu'il dit - il extrait JavaScript de JavaScript et, dans une certaine mesure, de HTML. Pour beaucoup de développeurs, cela semble brillant. Cependant, nous savons, comme le dit Jeff Atwood, que toutes les abstractions sont des abstractions échouées (qui méritent d’être lues si l’on considère GWT). Avec GWT, cela introduit spécifiquement les problèmes suivants:
Utiliser HTML dans GWT est nul.
Comme je l'ai dit, dans une certaine mesure, même le HTML est abstrait. Cela semble bien pour un développeur Java. Mais ce n'est pas. HTML est un format de balisage de document. Si vous souhaitez créer des objets Java pour définir un document, vous n'utiliseriez pas d'éléments de balisage de document. Il est extrêmement prolixe. Ce n'est pas assez contrôlé non plus. En HTML, il y a essentiellement une façon d'écrire
<p>Hello how are <b>you</b>?</p>. Dans GWT, vous avez 3 nœuds enfants (texteB, texte) attachés à unPnœud. Vous pouvez d'abord créer le P ou créer d'abord les nœuds enfants. L'un des nœuds enfants peut être le résultat renvoyé par une fonction. Après quelques mois de développement avec de nombreux développeurs, essayer de déchiffrer l'apparence de votre document HTML en traçant votre code GWT est un processus qui provoque des maux de tête.En fin de compte, l'équipe a décidé que peut-être utiliser HTMLPanel pour tout le code HTML était la bonne solution. Maintenant, vous avez perdu de nombreux avantages de GWT qui consiste à avoir des éléments immédiatement disponibles dans le code Java pour une liaison facile des données.
Utiliser CSS dans GWT est nul.
En attachant à l'abstraction HTML, cela signifie que la façon dont vous devez utiliser CSS est également différente. Cela s'est peut-être amélioré depuis la dernière fois que j'ai utilisé GWT (il y a environ 9 mois), mais à ce moment-là, le support de CSS était désastreux. En raison de la façon dont GWT vous fait créer du HTML, vous avez souvent des niveaux de nœuds que vous ne saviez pas qui ont été injectés (tout développeur CSS sait comment cela peut affecter considérablement le rendu). Il y avait trop de façons d'intégrer ou de lier les CSS, ce qui a créé un désordre confus d'espaces de noms. En plus de cela, vous bénéficiez du support des sprites, ce qui semble encore une fois agréable, mais votre CSS a été muté et nous avons rencontré des problèmes d'écriture. CSS codé et que nous devions simplement le redéfinir de manière à ce que GWT ne le gâche pas.
Union de problèmes, intersection d'avantages
Toutes les langues vont avoir leurs propres problèmes et avantages. Que vous l'utilisiez est une formule pondérée basée sur ceux-ci. Lorsque vous avez une abstraction, vous obtenez une union de tous les problèmes et une intersection des avantages. JavaScript a ses problèmes et est généralement traité en dérision par les ingénieurs côté serveur, mais il possède également de nombreuses fonctionnalités utiles pour le développement Web rapide. Pensez aux fermetures, à la syntaxe abrégée, aux objets ad-hoc, à toutes les tâches effectuées par Jquery (comme les requêtes DOM par sélecteur CSS). Maintenant, oubliez de l'utiliser dans GWT!
Séparation des préoccupations
Nous savons tous que lorsque la taille d'un projet augmente, il est essentiel de bien séparer les problèmes. L'un des plus importants est la séparation entre l'affichage et le traitement. GWT a rendu cela vraiment difficile. Ce n’est probablement pas impossible, mais l’équipe sur laquelle je faisais n’a jamais proposé de bonne solution, et même lorsque nous pensions que c’était le cas, il y en avait toujours une qui se glissait dans l’autre.
Desktop! = Web
Comme @Berin Loritsch l'a signalé dans les commentaires, le modèle ou la mentalité GWT est conçu pour les applications vivantes, où un programme possède un affichage vivant étroitement associé à un moteur de traitement. Cela semble bien parce que c'est ce que beaucoup pensent que le Web manque. Mais il y a deux problèmes: A) Le Web est construit sur HTTP, ce qui est fondamentalement différent. Comme je l'ai mentionné ci-dessus, les technologies basées sur HTTP - HTML, CSS, même le chargement de ressources et la mise en cache (images, etc.) - ont été conçues pour cette plate-forme. B) Les développeurs Java ayant travaillé sur le Web ne basculent pas facilement vers cet état d'esprit des applications de bureau. L'architecture dans ce monde est une discipline totalement différente. Les développeurs Flex seraient probablement plus adaptés à GWT que les développeurs Web Java.
En conclusion...
GWT est capable de produire assez facilement des applications AJAX rapides en utilisant uniquement Java. Si rapide et sale ne vous convient pas, ne l'utilisez pas. La société pour laquelle je travaillais était une société qui se souciait beaucoup du produit final, et son sens de la finition, à la fois visuel et interactif, incombait à l'utilisateur. Pour nous, développeurs frontaux, cela signifiait que nous devions contrôler HTML, CSS et JavaScript de manière similaire à l'utilisation de GWT, comme essayer de jouer du piano avec des gants de boxe.
la source
Nous utilisons GWT pour une grande application Web d'administration en ligne (SOA dans le backend) qui a un usage intensif. L'ancienne interface utilisateur était en DHTML, mais nous avions des problèmes de compatibilité de navigateur, d'optimisation des performances et de processus de développement. Nous avons donc cherché des alternatives.
Nos exigences ont été:
Nous avons choisi GWT et je ne le regrette jamais. La nouvelle équipe n'avait pas ou moins d'expérience en DHMTL et le processus de développement Java de GWT a donc été très utile. Ce que vous obtenez de la boîte est:
Notre application envoie une seule demande au serveur au démarrage. Le côté négatif est que GWT (et aussi Android) a un design médiocre, mais si vous appliquez votre propre apparence, vous devez adapter le CSS. Vous pouvez également utiliser diverses bibliothèques de composants pour GWT, ce qui facilite l'application de styles et de thèmes appropriés.
Pour moi, cela ne sert à rien que le DOM HTML soit peut-être moins performant que celui créé manuellement, cela n'a jamais été un problème. Lorsque je développe en C ++, je ne regarde pas le code assembleur généré. Lorsque je me suis développé dans GWT, je n'avais jamais eu aucune raison de regarder le code JS, mais une seule fois de regarder le DOM et de procéder à une refactorisation.
Pour moi, GWT est le seul choix en ce qui concerne le développement de RIA et j'espère que GWT a un avenir prometteur. Voir l'énoncé de mission à l'adresse:
[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction
Mais il ne faut pas oublier que Google n'utilise pas GWT dans bon nombre de leurs projets internes et qu'il existe actuellement des rumeurs sur son avenir, voir
[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC
la source