Quand ne pas utiliser Google Web Toolkit? [fermé]

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?

— Jas
source

Je pensais que GWT était mort.

— Aaron McIver

@ Aaron, vraiment?

— Jas

Je ne recommande pas personnellement GWT. Cet état d'esprit vous oblige à utiliser des applications de bureau, mais vous posera des problèmes lorsque vous essayez de penser de la sorte avec les fonctions HTML. Je suis fan de l'adaptation du paradigme de codage au problème actuel, et l'abstraction me gêne. C'est pourquoi chaque fois que j'ai commencé à l'évaluer, j'ai décidé de ne pas l'utiliser.

— Berin Loritsch le

@Jas Experience était quelques années en arrière; dans sa petite enfance et il se sentait très brut à l'époque. Cela a-t-il changé? Peut-être… mais j'essaie lentement d'apprendre les fondements des cadres au lieu de me fier à ceux-ci. À la fin de la journée, c'est un hachoir à viande pour le barattage JS; non pas que ce soit une mauvaise chose, mais pas quelque part où je veux mettre mes efforts. Beaucoup de ces cadres sont choisis en raison d'un manque de connaissances en technologie X ou de quelque chose de ce genre ... mais vous devrez éventuellement maîtriser la technologie X à un moment donné ... autant en faire un premier pas.

— Aaron McIver

Je connais très bien JS, j’ai écrit des textes assez sérieux, mais j’exécute à présent un projet extrêmement critique et je ne peux pas me permettre de faire perdre du temps à un personnel subalterne à cause d’erreurs induites par le basculement de Java à JS. Alors, s'il vous plaît, si vous avez un exemple concret de la raison pour laquelle GWT n'a pas fonctionné pour vous, alors décrivez-le, sinon, ne perdons pas de temps les uns avec les autres avec des discussions hypothétiques et très subjectives.

— Jas

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 (texte B, texte) attachés à un Pnœ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.

— Nicole
source

J'ai reconnu certaines des raisons pour lesquelles nous avons choisi Wicket plutôt que GWT, chapeau à la présentation.

— biziclop

-1 pour FUD, mon expérience avec GWT utilisé pour des applications à petite et grande échelle a été bien plus positive que négative. Et je n'ai pas rencontré un seul de ces "problèmes" donc le commentaire FUD. Nous avons réussi à intégrer des widgets générés par GWT dans des pages HTML très complexes avec très peu d'effort. Si vous savez ce que vous faites, c’est merveilleux, si vous ne voulez pas considérer qu’il pourrait y avoir une nouvelle meilleure façon de faire les choses, alors suivez cette "réponse" et ignorez ce commentaire.

@Jarrod Ce ne sont pas des "problèmes" à rencontrer, mais des descriptions claires de la nature de GWT. Le cas échéant, je les ai également qualifiés de négatifs, dans la perspective des objectifs de notre projet. Si vous avez une autre expérience, n'hésitez pas à la rédiger. Jusque-là, la seule information non prouvée est votre affirmation selon laquelle GWT est "nouvelle et meilleure". En passant - depuis que j'ai écrit cette réponse, la société (pour laquelle je ne travaille plus) a jeté sur un an le travail de plusieurs ingénieurs et a récrit le projet sans GWT. En moins de temps.

— Nicole

@JarrodRoberson Je suis d'accord avec NickC, ce serait bien de lire un compte-rendu aussi détaillé de vos expériences.

— Funkybro

@ NickC "En moins de temps" pour la réécriture d'un projet ne représente pas un coup dur pour GWT IMO; tout projet dans lequel vous répétez fondamentalement ce qui a été fait auparavant, même dans un cadre ou une langue différents, devrait prendre "moins de temps".

— Funkybro

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é:

couche UI côté client pour minimiser la charge du serveur
compatibilité du navigateur
AIR basé sur le Web
Optimisations faciles des performances
Aucune installation de plugins client nécessaire, ne devrait fonctionner avec une installation simple de Windows

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:

compatibilité du navigateur
Processus de développement basé sur Java et réutilisation du code
minimisation facile des demandes (lot d'images, ...)
mise en cache agressive facile (les nouvelles applications sont entièrement mises en cache côté client)
compression facile de toutes les ressources (même avec js sur d'anciens IE buggy)
et beaucoup plus, beaucoup à mentionner ici

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

— ChrLipp
source