Google Web Toolkit est-il utile pour développer des javascripts complexes?

Question

Je suis un grand fan des frameworks javascript, en particulier de jQuery. J'ai toujours voulu concevoir des sites comme "plurk.com". mais je sais qu’il a besoin de lignes énormes de javascript.so qui m’a fait taire.Mais depuis que je connais GWT, je veux vraiment le tester et je veux vous demander si cela rend notre travail plus facile à développer des choses complexes qu’avec le javascript ou ses frameworks. Que préféreriez-vous?

Answer 1

Peu de choses me font peur comme le "Javascript généré". La loi sur les abstractions fuyantes doit être doublement vraie dans ces cas.

Écrire du javascript sur plusieurs navigateurs est un processus délicat d’affinement continu. Essayer de déchiffrer les erreurs de Javascript générées et obscurées est un casse-tête majeur. C’est déjà assez grave de corriger des bugs dans les bibliothèques JS pures.

Pour moi, GWT est une astuce visant à permettre aux développeurs back-end d'écrire du code frontal dans leur navigateur. Malheureusement, les réalités des applications Web modernes impliquent de connaître Javascript et le DOM. Quelque chose va se casser et vous devrez savoir pourquoi.

Je pense que vous feriez mieux de choisir une bonne bibliothèque javascript telle que jquery ou prototype et de bien apprendre. Ces bibliothèques font abstraction du genre de choses qui DEVRAIENT être extraites et qui ne risquent pas de se briser dans les cas extrêmes, comme les opérations sur les tableaux et les demandes AJAX.

Answer 2

Je pense que certaines des réponses à cette question sont plutôt mal informées, et je suppose que les personnes qui ont répondu à cette question n’ont jamais utilisé GWT pour des projets à grande échelle. Oui, GWT est un excellent moyen de créer de grands sites Web AJAX. Pour les sites complexes de grande taille, impliquant également une extrémité arrière, il déclenche des actions telles que JQuery dans les parcs. La façon dont je le vois toujours, c’est que javascript seul est très bien pour faire des petites choses côté client. Lorsque vous devez faire quelque chose de plus complexe (comme des champs dynamiques, des popups, des animations), vous importez quelque chose comme JQuery ou Prototype. Si vous voulez aller plus loin, vous allez avec GWT.

Les gens supposent que, parce que vous l'écrivez en Java, il est conçu pour que les développeurs back-end puissent effectuer du développement front-end. Ce n'est pas. Java est tout simplement le langage qu'ils ont choisi, principalement parce qu'il est largement utilisé, typé de manière statique et qu'il existe de nombreux bons éditeurs pour le faire.

Je n'achète pas non plus la théorie des abstractions qui fuit, elle n'essaie pas de résumer complètement les éléments HTML, car elle vous donne un accès direct au javascript natif et au DOM si vous choisissez de les utiliser.

En bref, nous avons construit des sites très complexes (l'un d'entre eux étant présenté sur le blog de GWT) dans GWT, et utilisant également d'autres bibliothèques telles que JQuery. Je peux vous dire avec une certitude à 100% qu’une fois que vous avez compris votre idée, GWT tue ces autres cadres morts pour des tâches complexes. Il contient également quelques éléments intégrés qui contribuent à améliorer les choses, et même des éléments qu'aucun autre cadre ne prend en charge (comme la magie qu'il peut utiliser avec des images). Voir ce blog pour plus de détails:

http://googlewebtoolkit.blogspot.com/ 2007/10 / epo-builder-built-with-gwt.html

Answer 3

Oui, car vous utiliserez Java et non Javascript.

De superbes IDE, l'analyse de code statique, la recherche et le refactoring - tout cela vous facilitera la vie sur les grands projets.

Answer 4

Non. Ce n'est pas.

Cela ne supprime pas la complexité, il vous permet simplement de la gérer depuis une perspective Java. Puisque cela vous donne tous les outils disponibles en Java, cela en vaut la peine.

Les IDE JavaScript vont de mieux en mieux, et généralement si vous utilisez un Framework tel que jQuery ou Prototype, vous le trouverez probablement plus facile que de traiter avec une couche d'abstraction lourde comme GWT.

Ma préférence personnelle est d'adopter l'approche purement JavaScript, mais c'est parce que j'aime travailler plus étroitement avec le métal et que je suis assez discipliné pour apprivoiser mes chats JavaScript.

Answer 5

Avec GWT, vous n’écrivez pas réellement de JavaScript; Toute sa proposition de valeur est que vous pouvez écrire en Java et le compiler en JavaScript pour vous.

Answer 6

Je travaille sur un projet qui a utilisé GWT à bon escient. C'est un bon choix pour nous puisque nous sommes tous principalement des développeurs Java travaillant sur des outils internes. Je ne peux pas dire à quel point c'est utile pour les grands sites d'utilisateurs finaux.

Un avantage que j’apprécie particulièrement est la sérialisation et la désérialisation d’objets transparents. Non seulement les détails de XML-RPC sont abstraits, mais puisque le même code Java est compilé en code octet pour le serveur et en javascript pour le navigateur, vous pouvez coder presque comme si le serveur et le client étaient exécutés dans des chargeurs de classe séparés dans le répertoire. même JVM. Par exemple, vous pouvez créer un objet Java sur le serveur, l'envoyer au navigateur en tant que valeur de retour d'un appel de service RPC et le code du navigateur peut ensuite utiliser la même classe Java pour manipuler l'objet que vous venez de renvoyer. De même, les paramètres d'appels RPC peuvent être construits en tant qu'objets Java, le serveur recevant un objet Java identique à l'autre extrémité. Tout cela sans rentrer dans les détails de la (dé) sérialisation.