GWT vs. Cappuccino

Question

Je suis dans la phase de planification d'une application web et j'essaie de choisir entre GWT et Cappuccino. J'ai une idée de laquelle je pense est mieux, mais mon partenaire est vendu sur l'autre choix. J'espérais obtenir des commentaires sur les avantages et les inconvénients de chacun de ceux qui ont utilisé l'un ou l'autre ou les deux. Merci d'avance pour toute idée que vous pourriez avoir.

Answer 1

Toolkit v/Framework

GWT est un toolkit. Sa force réside dans les outils qu'il fournit pour créer une application. Cela ne fournit cependant pas de cadre. Les développeurs construisent généralement un petit cadre sur GWT pour répondre à leurs besoins. Il y a eu beaucoup d'emphase sur le modèle MVP pour créer des applications, mais ce n'est pas la seule façon d'utiliser GWT.

Cappuccino est un Framework. Il a une manière prescrite de construire des applications. De plus, il fournit des bibliothèques pour effectuer des tâches de haut niveau telles que l'animation, le glisser-déposer, annuler/rétablir, etc. GWT ne fournit aucune bibliothèque pour de telles tâches, bien que des bibliothèques tierces soient disponibles. Cela signifie que les applications Cappuccino ont tendance à être plus riches que les applications GWT correspondantes.

Hors ligne Compilation v/Runtime Traduction

GWT croit à prendre des décisions au moment de la compilation. La détection du navigateur, I18N, l'incrustation d'image, la génération de sprites, l'évaluation du modèle uibinder sont toutes effectuées au moment de la compilation. Deferred Binding permet aux développeurs de tirer parti de ce concept dans leurs propres applications.

EDIT

Cappuccino, par défaut, n'a pas besoin de compilation. Le navigateur télécharge les fichiers objectif-j, puis le framework les traduit/interprète directement au moment de l'exécution. Cependant, il est possible de compile using jake. Vous pouvez choisir parmi plusieurs minifieurs/compresseurs, y compris google's closure compiler.

En conséquence de cette décision architecturale, des applications GWT ont tendance à être plus rapide à l'exécution que l'équivalent des applications de cappuccino.Cependant, en raison du coût du temps de compilation, le développement a tendance à être plus lent que le Cappuccino. Le plugin de développement de GWT soulage quelque peu cette douleur, mais le coût ne disparaît pas entièrement. Comme GWT est un compilateur closed-world, il peut supprimer le code inutilisé, les appels de méthode en ligne, les chaînes internes et optimiser le code de telle façon que Cappuccino ne le puisse pas. Si Cappuccino devait introduire une étape de compilation, il pourrait effectuer les mêmes optimisations; mais au meilleur de ma connaissance, il n'y a aucun moyen de faire la traduction au moment de la compilation.

Avec l'étape de compilation facultative, ce point devient discutable. Cependant, les applications cappuccino qui n'effectuent pas une telle compilation auront une performance médiocre par rapport à une application GWT.

Type de sécurité

GWT est java - et est donc type safe. Objective J est javascript, et donc dynamiquement typé. Cela a son propre advantages and disadvantages, et comme c'est une discussion religieuse, je m'abstiendrai de porter un jugement.

Débogage

GWT fournit un plug-in de navigateur qui permet aux développeurs de déboguer directement le code Java. En mode développement, les développeurs voient les traces de la pile Java. Au moment de l'exécution, cependant, le code JS généré est obscurci et très difficile à déboguer (bien qu'il existe un moyen de dire à GWT de ne pas obscurcir mon code).

En utilisant le super-dev-mode, il est maintenant possible de déboguer le code Java directement à partir du navigateur Web.

Cappuccino n'a pas de mode de développement, ce qui signifie que vous devez utiliser des outils existants tels que firebug pour déboguer. Les erreurs sont signalées par le navigateur, et pour déboguer le code, vous devez utiliser des débogueurs JS.

Tests unitaires

Avec GWT, vous pouvez écrire des cas de test pure unité java qui ne nécessitent pas un navigateur pour exécuter. Cela présente des avantages évidents - la rapidité et la capacité à réutiliser l'infrastructure existante en sont certaines. Lorsque vous avez besoin d'un navigateur pour tester, vous pouvez choisir parmi GWTTestCase ou HTMLUnit. Il est également possible de tester en utilisant du sélénium.

Les applications Cappuccino peuvent être testées en utilisant OJTest. Malheureusement, je n'ai pas trouvé beaucoup de documentation sur le sujet, donc je ne peux pas commenter beaucoup. Bien sûr, vous pouvez toujours utiliser Selenium pour tester votre webapp.

interopérabilité avec Javascript

GWT fournit un moyen de parler aux bibliothèques JS existantes - elle est appelée Javascript Native Interface. Il est mature et fonctionne bien, mais n'est pas vraiment intuitif. L'objectif J est javascript, donc vous n'avez rien de spécial à faire pour interopérer avec Javascript.

Vision

Je ne peux pas soutenir cet argument, mais GWT a tendance à se concentrer sur la création d'applications web de haute performance sans se soucier beaucoup sur apparence. Ils ne font jamais de compromis sur la performance.D'un autre côté, le cappuccino a tendance à se concentrer sur des fonctionnalités et des frameworks de haut niveau, et à compromettre les performances d'exécution. En conséquence, les applications Cappuccino semblent plus riches, mais prennent un certain temps à charger. Les applications GWT se chargent et répondent plus rapidement, mais elles semblent ennuyeuses. Vous pouvez contourner les deux problèmes, j'en suis sûr, mais c'est comme ça que c'est fait.

soutien communautaire et le soutien

GWT est soutenu par Google. Leur engagement envers GWT est assez fort. Les nouvelles applications (Wave, Adwords, Orkut) de Google sont construites sur GWT. Google IO a eu plusieurs sessions sur GWT. Le user forum est assez actif et réactif, et la boîte à outils elle-même est activement développée et maintenue par Google et la communauté open source. Le Cappuccino user group n'est pas aussi actif et compte beaucoup moins de membres.

Answer 2

Je suis beaucoup plus expérimenté avec Cappuccino qu'avec GWT, mais GWT a l'air très rapide et assez robuste. Il est après tout soutenu par un acteur assez important dans le domaine de l'internet. La démonstration à Google IO était impressionnante. Bien que cela puisse changer, les applications GWT laissent totalement le Cappuccino dans la poussière quand il s'agit de temps de chargement et de taille de déploiement aujourd'hui. Cela dit, je suis allé avec Cappuccino pour deux raisons: d'abord, alors que GWT est une solution d'ingénierie classique «assez bonne», Cappuccino vise carrément à la foule «seulement le meilleur est assez bon». Je crois qu'avec Cappuccino vous pouvez atteindre un standard rarement vu sur le web avant. Pas seulement dans les jolis pixels, mais dans les fonctionnalités brutes et la puissance où tout fonctionne simplement à un niveau de «qualité de bureau». Faites glisser et déposez, annulez la pile, faites défiler et redimensionner les fluides, divisez les volets, et encore et encore. GWT est en train de rattraper son retard, comme on peut le voir sur Google Wave, mais il reste encore beaucoup à faire et Google ne s'est jamais beaucoup soucié du polonais. Ceci est visible, par exemple, dans Gmail, qui n'est pas seulement terne mais encore maladroit dans l'interaction de l'utilisateur après tant d'années.

La deuxième raison pour laquelle je suis allé avec Cappuccino est que Java me rend fou avec son style inflexible, ridiculement verbeux et illisible. Mais cela pourrait être seulement moi.

Answer 3

Vous pourriez être intéressé par mon nouveau cadre UI GWT, CappuccinoGWT