java support - Pourquoi GWT? Avantages et inconvénients de l'utilisation de ce cadre RIA





opinion compilateur (4)


Nous avons une application GWT avec un tas de tests d'acceptation de sélénium. Je pensais (comme vous) qu'il serait certainement sûr de mettre à jour GWT de 1.7 à 2.0. Et c'était - la plupart du temps. L'application fonctionnait toujours de la même manière pour les utilisateurs «humains», mais les tests au sélénium ont tous échoué. Il y a une version plus récente de Selenium en préparation (à la version alpha, avec beaucoup de UnsupportedOperations), mais si nous voulons rester avec GWT 2, il semble que nous devions abandonner la testabilité. Alors faites attention aux hypothèses "à l'épreuve du futur".

Notre décision d'utiliser GWT a été prise il y a des mois, après avoir comparé YUI et ZK. Je suis toujours content d'avoir choisi GWT. Le niveau de soutien sur le site Web de GWT et la qualité générale de la documentation semblent très élevés.

GWT divise les modules et fournit un profil de performance qui aide à contrer les arguments selon lesquels il n'est pas assez léger.

J'ai lu un tas de questions "les mieux votées" pour GWT. Plusieurs de ces questions parlent des pièges ou des problèmes avec GWT.

Dans les articles: Quel framework Javascript (jQuery vs Dojo vs ...)? et les plus grands pièges GWT? , certaines affiches semblent suggérer que GWT n'est pas assez léger ou qu'il existe de meilleures alternatives qui peuvent être utilisées.

Est-ce que la plupart d'entre vous pensent qu'il y a des problèmes avec GWT qui n'ont pas été résolus avec GWT 2.0 - ce qui vous inciterait à suggérer d'utiliser un cadre plus simple pour un nouveau projet?

Dans une certaine mesure, GWT ne devrait-il pas être un peu à l'épreuve du temps (puisque vous n'avez pas à vous soucier de changer radicalement d'une version à l'autre et puisque cela est soutenu par Google)?

Je me rends compte que la réponse à cette question dépend grandement de ce que vous voulez faire ou de ce que vous voulez faire. Je regarde cela du point de vue du démarrage d'une nouvelle application web qui sera éventuellement utilisée par des millions d'utilisateurs.




Nous construisons régulièrement de petites classes (~ 2K Java classes) à moyennes (~ 6K) en utilisant GWT depuis la sortie de la version 1.3. Je comprends qu'il y a un ensemble différent de problèmes à résoudre sur un site public ayant mille clics par seconde, mais je vais essayer de parler de nos plus gros problèmes dans GWT 1.x et comment GWT 2.0 aborde cela.

Fuites de mémoire du navigateur IE6 fuites avec GWT sont énormes, IE7 fuites peuvent être compensées par des actualisations de page périodiques, IE8 promet une certaine stabilité dans ce domaine, mais pas encore largement acceptée dans l'entreprise. Et oui, même un code GWT valide sans appels JS natifs perd de la mémoire dans certains cas. Surtout quand l'interface utilisateur est complexe et que vous faites beaucoup d'appels Panel.clear (). Il n'y a pas d'outils utiles pour identifier la cause réelle de la fuite pour le moment. Sauf si vous savez comment pirater le navigateur lui-même.

Rendering Performance vous devez écrire votre code d'interface utilisateur très soigneusement, en particulier lors de la construction de widgets personnalisés couramment utilisés. Une connaissance approfondie de JavaScript, CSS et DOM est toujours requise. Il y a beaucoup de matériaux sur internet sur ce sujet. Vous devez savoir comment et quand descendre du niveau du widget GWT pour diriger les manipulations DOM.

Taille du contenu téléchargeable il était impossible avant 2.0 de diviser le module en différentes parties téléchargeables sans avoir intégré la navigation «dure» dans l'application. Mais cela effacera le contexte JavaScript et nécessitera un rechargement de la fenêtre.

Développeurs d'interface utilisateur Mind Shift Les développeurs d'interface utilisateur expérimentés ne connaissent tout simplement pas Java et OOP. Les développeurs Java expérimentés ne connaissent pas CSS, JS, HTML et n'aiment pas construire l'interface utilisateur. UI Binder va dans la bonne direction.

Nous avons effectué la migration 1.3 -> 1.5 -> 1.7 et c'était toujours juste une recompilation et quelques corrections CSS. GWT 2.0 supprime beaucoup de code obsolète et d'approches initiales (structure de projet, GWTShell) et peut être difficile à migrer rapidement. Mais toutes les fonctionnalités semblent prometteuses et c'est bien que Google ait abandonné le code existant à un moment donné. Cependant, je ne suis pas sûr de la stabilité de la version 2.0, car nous ne l'avons pas encore utilisée dans de vrais projets.

J'espère que cela t'aides.




Compromis

Commençons par tous les compromis que je peux trouver:

  • vous utilisez Java - cela signifie que la compétence de vos webdevs en javascript ne vous sera pas très utile (cela vous sera utile si vous utilisez JSNI)
  • problèmes avec l'indexation par les moteurs de recherche - à mon humble avis, cela devrait être le plus grand inconvénient de l'utilisation de GWT, ou des applications web JS pure en général. Puisque le contenu, la mise en page, tout est créé "à la volée" avec JS, le moteur de recherche ne verra qu'une page HTML très courte et c'est ça - vous devez en prendre soin vous-même (par exemple, utiliser le cloaking ) . Google a finalement commencé à travailler sur une solution pour cela , mais cela ne me semble pas attrayant.
    Mise à jour: Google a enfin résolu ce problème. Cependant, je vais laisser cela comme un compromis, car rendre l'application explorable nécessite encore plus d'efforts que dans d'autres frameworks. Au moins maintenant, nous avons une "norme" à suivre et ne pas avoir à utiliser des techniques douteuses (comme le cloaking ).
  • c'est facile (surtout pour un débutant dans GWT, surtout quand cette personne vient d'un arrière-plan HTML / JS - sans trop d'expérience orientée objet) pour aller "wow, ces choses" objet "sont si cool, laissez-moi faire tout mon <div> s dans des objets séparés, cela rendra le code tout beau et soigné ". Bien sûr, je l'exagère, mais vous comprenez bien qu'un programmeur inexpérimenté peut mettre un Widget complet avec beaucoup de Handlers dans chaque cellule d'un FlexTable ... Et puis (s) il perdra beaucoup de temps à se demander pourquoi l'application est léthargique;) tl; dr: il est facile pour les débutants dans GWT de rendre leurs applications "bloaty" en écrivant du code qui semble conforme à ce que la documentation / samples / sens commun; ) suggérer

C'est tout pour les compromis que je peux penser - si quelqu'un veut ajouter quelque chose, s'il vous plaît ajouter des commentaires.

Avantages

Maintenant pour les avantages. Je vais sauter un peu comme l' internationalization , la compatibilité multi-navigateur pour l'intégration gratuite et facile, avec d'autres bibliothèques de Google, etc, car ils sont un peu évidentes et faciles à comprendre. Je vais essayer de me concentrer sur les fonctionnalités les moins accentuées mais néanmoins très importantes:

  • le compilateur - maintenant, la plupart des gens avec qui j'ai parlé de GWT ne réalisent pas à quel point cette partie de GWT est incroyable - pour les débutants, essayez cette présentation de Google IO de l'an dernier . Le compilateur a la vue de l'ensemble de l'application.

Donc, il peut optimiser une telle chose:

public class ShapeExample implements EntryPoint {
  private static final double SIDE_LEN_SMALL = 2;
  private final Shape shape = new SmallSquare();
  public static abstract class Shape {
    public abstract double getArea();
  }
  public static abstract class Square extends Shape {
    public double getArea() { return getSideLength() * getSideLength(); }
    public abstract double getSideLength();
  }
  public static class SmallSquare extends Square {
    public double getSideLength() { return SIDE_LEN_SMALL; }
  }
  public void onModuleLoad() {
    Shape shape = getShape();
    Window.alert("Area is " + shape.getArea());
  }
  private Shape getShape() { return shape; }
}

..pour ça:

public class ShapeExample implements EntryPoint {
  public void onModuleLoad() {
    Window.alert("Area is 4.0");
  }
}

Et puis obscurcissez cela et minimisez. De plus, cela se fait de telle sorte que les fichiers résultants deviennent plus compressibles via gzip.

  • vous utilisez Java - que vous aimiez ou non Java, on ne peut nier que c'est un très bon langage orienté objet, qui permet d'écrire du code facile à maintenir et testable (quelque chose que je ne pense pas possible avec JavaScript) ). Si vous suivez de bonnes directives , vous arriverez à un code compréhensible non seulement pour vous, mais aussi pour d'autres développeurs. Une autre chose qui mérite d'être mentionnée est que tous ces beaux modèles de design, etc, qui fonctionnent en Java "pur", fonctionnent ici aussi.
  • Une chose intéressante à propos de GWT est que vous obtenez des gains de performance et de nouvelles fonctionnalités gratuitement avec presque chaque nouvelle version du framework. Comme Java est compilé en JavaScript, il suffit d'une recompilation pour bénéficier des optimisations faites dans le nouveau compilateur ou obtenir de nouvelles fonctionnalités (comme la prise en charge de l' accessibilité introduite dans GWT 1.5).
  • débogage - il est utile de mentionner que vous pouvez (et devriez :) :) déboguer vos applications GWT comme n'importe quelle autre application Java, en utilisant le débogueur de votre IDE. Et, en général, les débogueurs Java que j'ai vus sont plus avancés que leurs homologues JavaScript.
  • UiBinder - bien que ce ne soit pas encore "parfait", UiBinder vous permet de concevoir vos Widgets de manière simple et intuitive en utilisant XML (par opposition à la méthode pré-2.0 qui vous a obligé à le faire en Java). Mélanger les Widgets HTML et GWT n'a jamais été aussi facile et amusant;)
  • travailler avec CSS - GWT a toujours, bien sûr, embrassé CSS, mais avec l'introduction de GWT 2.0 (et UiBinder), ils l'ont pris à un autre niveau. Regardons un fichier CSS à partir d'une application web "normale" - des centaines, voire des milliers de lignes, difficiles à naviguer, certains styles sont redondants mais il est difficile de le remarquer, certains ne sont pas utilisés du tout, ajouter à ce mélange besoin de s'il vous plaît IE6 / 7 et vous obtenez un cauchemar. Avec GWT, vous pouvez lui demander d'effectuer les mêmes tâches que pour le code JS pour CSS: il élagera tous les styles CSS inutilisés, fusionnera le cas échéant, minimisera et masquera les noms de classe, et bien d'autres (y compris les conditions, les constantes , etc. dans vos fichiers CSS). Nous vous encourageons à conserver vos styles dans les fichiers XML de leur UiBinder respectifs - cela facilite grandement l'organisation et la recherche. Last but not least, vous obtenez une erreur lorsque vous avez mal orthographié un nom de style CSS - moins de tracas, puis essayer de faire la même chose via Firebug ou un outil similaire
  • OOPHM - Out of Process mode hébergé, avec cela, ils ont fixé l'un des plus grands inconvénients de GWT - maintenant, vous arrivez à utiliser le mode hébergé dans le navigateur de votre choix (si ce choix est Firefox, Safari, IE ou Chrome, mais à au moins, vous pouvez utiliser n'importe quelle version que vous voulez). La conception d'OOPHM vous permet également de faire des choses sympas comme exécuter Windows dans une machine virtuelle, et vous connecter de l'IE au mode hébergé fonctionnant sur le système d'exploitation hôte (Linux / MacOS) - pas besoin de hacks, copier des fichiers après chaque compilation, etc
  • vous avez à dire / ɡwɪt / un lot;) (ceci est une citation de l'une des présentations sur Google IO 2009 , IIRC)
  • beaucoup plus .. Jetez un oeil aux vidéos de Google IO 2009 et parcourez le wiki GWT pour voir plus de choses qui rendent la création de RIA plus facile et moins sujet aux erreurs avec GWT :)

Entre

Selon votre expérience et / ou vos préférences, ce qui suit pourrait être un avantage (pour moi, mais parfois c'est un PITA;)) ou pas:

  • la collection de Widgets prête à l'emploi est toujours petite et simple . Maintenant, si vous venez d'une infrastructure GUI complète (que ce soit sur le Web ou sur le bureau), vous pourriez être surpris de voir à quel point le nombre de Widgets GWT est relativement petit. Mais selon les devs de GWT, c'est comme ça que ça est fait - les Widgets de base sont tous les outils / "blocs" dont vous avez besoin pour construire vos propres Widgets personnalisés. L'alternative est de fournir une variété de Widgets polyvalents qui doivent supporter de nombreux cas d'utilisation ... Le résultat est une interface utilisateur un peu lent (au moins à SmartGWT - vérifiez par vous-même des projets comme SmartGWT ou Ext GWT ). C'est-à-dire, les Widgets GWT sont assez bien écrits - par exemple le SuggestBox a beaucoup d'endroits où vous pouvez remplacer le comportement par défaut avec le vôtre - vous pouvez spécifier une manière différente d'afficher les suggestions ( SuggestBox.SuggestionDisplay ), action personnalisée lorsque l'utilisateur sélectionne une suggestion ( SuggestBox.SuggestionCallback ) ou fournit simplement un SuggestOracle personnalisé pour alimenter le SuggestBox avec Suggestion s ...

Bottom line est - essayez GWT, les chances sont que vous l'aimerez et ne voudra plus jamais écrire en JavaScript pur;)




MooTools (My Object Oriented Tools) est centré sur l'idée des classes . Vous pouvez même étendre et implémenter avec l'héritage.

Une fois maîtrisé, il rend ridiculement réutilisable, javascript puissant.





java javascript ajax gwt