GWT est-il toujours pertinent pour les nouveaux projets de 2014?

Question

La question Pourquoi devrais-je utiliser jQuery au lieu de GWT? peut-être obsolète (comme ses réponses). Et la plupart de l' autre AINSI que de questions connexes peuvent également être obsolètes de nos jours. Donc, nous allons mettre à jour l' état de l'art sur GWT pertinence pour les nouveaux projets.

GWT est plus mature de nos jours

Depuis 2009, questions/réponses, GWT a évolué et certains frameworks JS sont disponibles en Java:

• GwtQuery pour jQuery (gQuery)
• GXT pour ExtJS (ancien ExtGWT)
• Smart GWT a remplacé GWT-ext
• ... et sûrement plus ... (n'hésitez pas à ajouter)

Et même plus, le code Java peut être converti autonome bibliothèques JS: gwt-exportateur

Mais le faible niveau des frameworks JS peut être assez

Mais plus je lis, plus je vois les développeurs web conseiller de tourner le dos à GWT et utiliser directement les frameworks JS (Firebug, IDE plugins pour les frameworks JS...).

La productivité

Cependant j'aime bien l'idée de développement et de débogage en utilisant le même IDE (Eclipse, Netbeans, IntelliJ IDEA...). Je pense que je vais être plus productif... je devrais aussi penser à de la Documentation et de la Communauté (forum réactivité pour cela DONC, la question)...

Questions

1. Pour ce genre de nouvelle 2014 projet GWT doit être (ou pas) pris en compte?
2. Existe-il pertinent de solutions de rechange à GWT pour faciliter l'AJAX développement d'applications web & de déploiement?
3. Quels sont le mode et tendance?

Mon cas précis

Je viens de terminer un POC (d'un intranet web app) basé sur Python3 (http.server.HTTPServer) en composant le (POST) bash scripts (le traitement en C++) et de récupérer les données JSON. Certains JS (pas de cadre) dans la page web pour le rendu. Donc, je me demande la meilleure option pour la prochaine itération.

Mais s'il vous plaît répondre à cette question sur d'autres cas également. Je préfère un général de question/réponse, pour être utile à beaucoup plus de gens.

Answer 1

Pour le point 1, je peux vous donner quelques critères que je voudrais utiliser:

Lors de l'utilisation de JavaScript cadres vous sont généralement très rapide dans la création initiale du code. Dans mon expérience, vous êtes beaucoup plus lent quand il s'agit de l'entretien (corrections de bugs, nouvelles fonctionnalités, refactorings) en tant que support de l'outil n'est pas très bonne, comme elle l'est pour les langages statiquement typés. Donc, pour le plus grand ou le long des projets en cours, je serais toujours choisir GWT à cause de Java et du compilateur vérifie/écosystème/de l'outillage. Je pense que vous allez bénéficier d'une meilleure efficacité et évolutivité dans le développement au cours du temps car vous n'aurez pas de problèmes étranges en raison de typage dynamique. Pour les petits projets qui ne vivent pas trop longtemps ou ne pas besoin de beaucoup de refactorings, Frameworks JavaScript peut être un coup de pouce dans la vitesse de développement.

Débogage des besoins dans le contexte de votre plate-forme cible sont également un critère pour moi. Le débogage de Code GWT est très agréable, aussi longtemps que vous avez un navigateur pris en charge par la structure DevMode ou, au moins, peut être utilisé avec la nouvelle source de cartes basées SuperDevMode. E. g. Safari sur mac os X n'est pas pris en charge. Pour les appareils mobiles, vous pouvez à distance de débogage JavaScript sur Android Chrome, mais pour autant que je sais que ce n'est pas possible pour GWT.

Un autre critère de sélection pour moi, c'est la taille de l'équipe et de taux de rotation. Basé sur Java outils (IDE, la qualité du code de dames, ...) d'aider les développeurs, surtout les nouveaux pour naviguer à travers d'autres développeurs de code. Cela est également vrai pour d'autres statique des types de langues, mais vous l'avez demandé GWT/Java.

La prochaine est la pile question ... GWT résout facilement le client et la communication à distance de la partie, si l'utilisation d'un conteneur de servlet sur le serveur. Il est également facile à combiner avec maturité les technologies Java entreprise (JPA, EJB, Spring, ...). C'est une grande force si vous avez besoin/envie d'avoir la pile. Si vous allez polyglotte sans JVM sur votre côté serveur(comme mentionné ci-dessus), celui-ci n'est pas pour vous.

Bien sûr, il y a plus de critères pour les deux, GWT et frameworks JavaScript.

Et la grande question est à propos de préférences. JavaScript a vraiment de beaux concepts (par exemple, des Fermetures) mais est aussi un risque en raison de la dynamique de la frappe. Lequel préférez-vous?

Concernant le point 2:

Je ne sais pas si il y a une réelle alternative pour les GWT qui fournit des fonctionnalités similaires et de l'outillage. La plupart des autres cadres de se concentrer sur un seul aspect (Widgets, l'optimisation, la liaison de données, la communication à distance, prise en charge du navigateur, I18n, ...). Cela ne signifie pas que d'autres cadres sont mauvais, mais vous n'avez généralement besoin d'une combinaison de différents cadres pour obtenir les fonctionnalités que GWT fournit.

Concernant le point 3:

• Je voudrais vraiment avoir un coup d'oeil à la Machine grâce à l'amélioration de la dactylographie et l'interopérabilité avec JavaScript
• Aussi loin que je me souvienne, Dart a un but similaire
• L'evergreen est JQuery, mais dépend de vos besoins, il existe de bonnes alternatives. Mais c'est très subjectif
• Pour les widgets, Twitter Bootstrap (http://getbootstrap.com/) est bien si c'est la façon de faire les choses est ok pour vous. Il y a même une GWT version (http://gwtbootstrap.github.io/)

Answer 2

Grande réponse par Steffen. J'ai commencé à taper comme commentaire à son, mais a constaté que j'ai tapé plus que ce que j'attendais, ce qui en fait l'une réponse distincte. Pas de chasse pour les points...

Je voulais juste ajouter 1 subjective point de la mine. La réalité est que la majorité des développeurs sont dits développeurs back avec aucune connaissance, expérience et, surtout, le désir de développer l'interface web. La réalité de marché est que la majorité préfère Java dans leur cv sur JS, PHP, Python et d'autres langues exotiques. La raison en est la rémunération. Développeurs Java, en moyenne, d'être payé plus. Pas sûr d'autres pays.

Donc, la majorité des développeurs en compagnie des développeurs Java (ou .NET, ce qui est en dehors de cette conversation). Afin de les faire travailler sur l'INTERFACE utilisateur, vous devez utiliser une technologie compatible Java, qui serait JSP ou GWT. JSP aurait besoin pour apprendre les librairies JS pour rendre l'interface plus ou moins présentable.

Évidemment, si vous voulez impressionner public unique de l'INTERFACE utilisateur, vous devez utiliser les librairies JS qui permettent une plus grande personnalisation. Les deux JSP, GWT pourrait fonctionner, comme la majorité de travail va être fait en JS. Comme je l'ai mentionné ci-dessus, peu d'entreprises auraient connu JS développeurs sur le personnel.

La majorité des applications sont écrites pour un usage interne, et non pas face public. À partir de ce que vous avez décrit, votre cas d'utilisation peuvent entrer dans cette catégorie.

Interne non publiquement face à outils sont souvent plus complexes de fonctionnalités que les sites web publics, mais leurs exigences de conception sont de plus en plus détendue, tant que la fonctionnalité est là et pratique pour une utilisation interne.

Dans ce cas, vous pouvez vous en sortir avec GWT, qui est de moins en moins étrangère aux développeurs Java de jQuery et un niveau élevé de la bibliothèque comme GXT avec le thème standard.

GWT avec GXT a été pour nous un moyen facile et rapide de créer un ensemble d'applications internes. Avec l'équipe des développeurs Java, notre société a, nous n'aurions jamais près à la qualité ou même l'intégralité de projets au sein de la même période de temps.

Answer 3

Juste la tête hors de: GWTs page d'exemple, présenter des exemples du monde réel des applications GWT

Viens de lire sur le super poids lourd de la nature de ces exemples.

GWT lui-même n'est pas qu'un poids léger, et je doute qu'il a été conçu pour créer un datepicker. GWT est quelque chose de complètement autre chose que jQuery ainsi. C'est peut-être plus comparable à JSF2 que de jQuery. La question "dois-je utiliser GWT ou jQuery" pourrait être répondu comme:

si vous souhaitez ajouter datepickers, quelques effets, un tableau triable, une saisie semi-automatique ici et là. Vous devriez sans doute aller avec jQuery.

Si vous voulez savoir si vous souhaitez utiliser GWT comme le frontend modèle / moteur de mécanisme, vous devriez envisager d'autres qui sont réellement comparables. Lors de la discussion de java, probablement JSF2 est votre seul choix. Et JSF courbe d'apprentissage est raide.

Je suis à creuser plus profond et j'ai trouvé un triste post:

http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html

Je suis arrivé à cette page parce que j'ai lu sur les projets à venir comme AngularJS, Backbone, single page applications (SPA): En bref, google a chuté de GWT. GWT est maintenant open source, simplement parce qu'ils l'ont abandonnée. Maintenant, AngularJS se prend une grosse poussée par google.

Answer 4

Je suppose que pour répondre au point 1, vous auriez à regarder ce que votre situation actuelle est et ce que vos objectifs sont.

Si vous avez une équipe de développeurs qui ont été à l'aide de Java l'essentiel de leur carrière, vous pouvez probablement s'attendre à un bon 6 mois pour eux d'apprendre les paradigmes de JavaScript. Si l'avoir de l'expérience dans les langues, comme Groovy ou Clojure, vous pourriez probablement couper que le temps de quelques. Donc, si vous ne s'attendent pas le projet dure plus d'un an, puis GWT serait probablement la voie à suivre.

A l'inverse, si vous avez une équipe de la JS développeurs, ils peuvent trouver le typage statique du système plutôt frustrant et apprendre à l'utiliser efficacement pourrait prendre la moitié d'une année pour eux. Donc, si c'est le cas, vous probablement ne voulez pas utiliser GWT pour tout nouveau projet où la courbe d'apprentissage l'emporte sur la productivité.

Je ne suis pas vraiment sûr de ce que le point 2 est de demander. Si vous vous posez des questions à propos d'une pile entière de cadres, je devine que vous pourriez trouver quelque chose à l'aide de nodejs, bien que je ne pense pas que j'ai assez d'expérience pour vous conseiller sur que.

Sur le point 3, où je travaille, nous semblent aller vers l'utilisation de frameworks JS (AngularJS en particulier) avec le (nouveau) serveurs/services écrits en Python et Groovy, et les systèmes existants encore en Java. Nous avons aussi un couple de services étant écrit en Clojure.

Answer 5

Si vous connaissez et l'amour de Java et vous êtes en train de créer un extrêmement compliqué web app, vous devez envisager l'utilisation de JSF, Vaadin, ou GWT. Tous ces vous permettent d'utiliser Java au lieu de GWT. Vous pourriez éliminer JSF et Vaadin si vous ne voulez pas de l'application pour utiliser beaucoup d'AJAX. Cela laisse GWT. Si vous voulez facile AJAX développement, vous ne devriez pas utiliser GWT. JavaScript est beaucoup plus facile à apprendre et il est beaucoup plus facile à utiliser si l'application web n'est pas très compliqué. Vaadin qu'il est Vaadin est beaucoup plus facile à utiliser que GWT. Il est construit sur GWT et il est possible d'utiliser GWT dans Vaadin. GWT est perdent en popularité maintenant. GWT est de mieux en mieux mais il y a beaucoup plus de concurrence maintenant. Beaucoup seraient GWT aux développeurs d'utiliser Vaadin ou JSF à la place. En outre, le JavaScript est en train de devenir plus capable. Par conséquent, beaucoup de gens se sentent satisfaits avec le javaScript. Ce n'est pas trop sujet mais parce qu'il y a encore de 100 000 GWT développeurs. Il y a 1000 développeurs de chez google. De nombreuses et importantes applications web utilisent GWT par exemple, Evernote, des feuilles de calcul Google, google adsense, google play, google wallet et cætera. Aussi, GWT est effectivement développe beaucoup plus vite que le javaScript.