Est-ce que GET est toujours pertinent pour de nouveaux projets?
La question Pourquoi devrais-je utiliser jQuery au lieu de GWT? peut être obsolète (comme ses réponses). Et la plupartsurles autres SO questions connexes peuvent également être dépassées de nos jours. Donc, mettons à jour le - état de l'art sur la pertinence du GWT 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 (anciennement ExtGWT)
- Smart GWT a remplacé GWT-ext
- ... et sûrement plus ... (n'hésitez pas à ajouter)
Et encore plus, Java peut être converti en bibliothèques JS autonomes: gwt-exporter
Mais les frameworks JS de bas niveau peuvent suffire
Mais plus je lis, plus je vois de développeurs web conseiller de tourner le dos à GWT et d'utiliser directement les frameworks JS ( Firebug , IDE plugins pour les frameworks JS ...) .
Productivité
Cependant j'aime l'idée de développer et de déboguer en utilisant les mêmes IDE (Eclipse, Netbeans, IntelliJ IDEA ...). I pensez Je serai plus productif ... Je devrais aussi penser à la Documentation et à la Communauté (réactivité du forum quant à cette SO question) ...
Questions
- Pour quel type de nouveau projet 2014 GWT devrait être (ou non) envisagé?
- Existe-t-il pertinent des alternatives à GWT pour faciliter AJAX développement et déploiement d'applications Web?
- Quels sont le mode et la tendance actuels?
Mon cas spécifique
Je viens de terminer un POC (d'une application Web intranet) basé sur Python3 (http.server.HTTPServer) appel (POST) bash scripts (certains traitements en C++) et récupération des données JSON. Certains JS (pas de framework) dans la page Web pour le rendu. Je me demande donc la meilleure option pour la prochaine itération.
Mais veuillez également répondre à cette question concernant d'autres cas. Je préférerais qu'une question/réponse générale soit utile à beaucoup plus de gens.
MISE À JOUR octobre 2015
GWT semble moins actif car aucune nouvelle version depuis 11 mois. Mais dans le passé jusqu'à 13 mois entre les versions 2.4 et 2.5 . Le Git repo mirror est toujours très actif. De plus, GWT est extensible et de nouvelles fonctionnalités peuvent provenir des bibliothèques GWT sans nécessiter de nouvelle version du framework GWT. Voir par exemple les bibliothèques GWT mobiles les plus courantes et les cycles de publication correspondants. En attendant, la tendance est d'utiliser Node.js partout! L'adoption de GWT pour de nouveaux projets dépend vraiment des compétences/motivation des développeurs et de la durée de vie du projet (chiffre d'affaires/formation/maintenance). D'autres critères tels que la réutilisation du code source disponible et le délai de mise sur le marché peuvent également être pris en compte ... Voir les excellentes réponses ci-dessous.
Pour le point 1, je peux vous donner quelques critères que j'utiliserais:
Lorsque vous utilisez des frameworks basés sur JavaScript, vous êtes généralement très rapide dans la création initiale du code. D'après mon expérience, vous êtes beaucoup plus lent en ce qui concerne la maintenance (corrections de bugs, nouvelles fonctionnalités, refactorings), car la prise en charge des outils n'est pas aussi bonne que pour les langages typés statiquement. Donc, pour les projets de plus grande envergure ou de longue durée, je choisirais toujours GWT en raison de Java et ses vérifications de compilateur/écosystème/outillage. Je pense que vous bénéficierez d'une meilleure efficacité et d'une mise à l'échelle du développement au fil du temps au fur et à mesure que vous gagnerez n'ont pas d'étranges problèmes en raison de la frappe dynamique. Pour les petits projets qui ne dureront pas trop longtemps ou ne nécessiteront pas de gros remaniements, les cadres JavaScript peuvent être une grande vitesse de développement.
Les besoins de débogage dans le contexte de votre plateforme cible sont également un critère pour moi. Le débogage du code GWT est très agréable tant que vous avez un navigateur pris en charge par DevMode ou au moins peut être utilisé avec les nouvelles cartes sources basées sur SuperDevMode. Par exemple. Safari sur MacOS X n'est pas pris en charge. Pour les appareils mobiles, vous pouvez déboguer à distance JavaScript sur Android Chrome mais pour autant que je sache, ce n'est pas possible pour GWT.
Un autre critère pour moi est la taille de l'équipe et le taux de roulement. Java (IDE, vérificateurs de qualité de code, ...) aident les développeurs, en particulier les nouveaux, à naviguer dans le code d'autres développeurs. Cela est également vrai pour d'autres langages de types statiques, mais vous avez demandé pour GWT/Java.
La suivante est la question de la pile ... GWT résout facilement la partie client et la communication à distance si vous utilisez un conteneur de servlet côté serveur. Il est également facile de le combiner avec des technologies d'entreprise Java Java (JPA, EJB, Spring framework, ...). C'est une grande force si vous avez besoin/voulez avoir la pile. Si vous vont polyglotte sans JVM 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 frameworks GWT et JavaScript.
Et la grande question concerne les préférences. JavaScript a vraiment des concepts sympas (par exemple des fermetures) mais est également un risque en raison de sa frappe dynamique. lequel préfères-tu?
Concernant le point 2:
Je ne sais pas s'il existe une véritable alternative à GWT qui offre des fonctionnalités et des outils similaires. La plupart des autres frameworks se concentrent sur un seul aspect (Widgets, optimisation, liaison de données, communication à distance, prise en charge du navigateur, I18n, ...). Cela ne signifie pas que les autres cadres sont mauvais, mais vous avez généralement besoin d'une combinaison de différents cadres pour obtenir les fonctionnalités fournies par GWT.
Concernant le point 3:
- J'aurais certainement un coup d'œil à TypeScript en raison de sa frappe améliorée et de son interopérabilité avec JavaScript
- Autant que je me souvienne, Dart a un objectif similaire
- Le Evergreen est JQuery mais en fonction 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 sa façon de faire les choses vous convient. Il existe même une version GWT de il ( http://gwtbootstrap.github.io/ )
Excellente réponse de Steffen. J'ai commencé à le taper comme commentaire pour le sien, mais j'ai constaté que j'avais tapé plus que ce à quoi je m'attendais, ce qui en faisait une réponse distincte. Ne pas chercher de points ...
Je voulais juste ajouter un de mes points subjectifs. La réalité est que la majorité des développeurs sont des soi-disant développeurs back-end sans connaissances, expérience et surtout désireux de développer une interface web. La réalité du marché informatique américain est que la majorité préférerait Java dans leur CV plutôt que JS, PHP, Python et d'autres langages exotiques. La raison en est la compensation. Java les développeurs sont en moyenne mieux payés. Je ne suis pas sûr des autres pays.
Ainsi, la majorité des développeurs d'une entreprise seraient Java développeurs (ou .NET, qui est en dehors de cette conversation). Pour les faire fonctionner sur l'interface utilisateur, vous devez utiliser une technologie compatible Java, qui serait JSP ou GWT. JSP aurait besoin d'apprendre les bibliothèques JS pour rendre le frontend plus ou moins présentable.
Évidemment, si vous voulez impressionner le public avec une interface utilisateur unique, vous devez utiliser des bibliothèques JS qui permettent une plus grande personnalisation. JSP et GWT fonctionneraient tous les deux, car la majorité du travail sera effectuée dans JS. Comme je l'ai mentionné ci-dessus, peu d'entreprises auraient expérimenté des développeurs JS au sein de leur personnel.
La majorité des applications sont écrites pour un usage interne et ne sont pas destinées au public. D'après ce que vous avez décrit, votre cas d'utilisation peut tomber dans cette catégorie.
Les outils internes non accessibles au public ont souvent une fonctionnalité plus complexe que les sites Web publics, mais leurs exigences de conception sont plus détendues tant que la fonctionnalité est là et pratique pour une utilisation interne.
Dans ce cas, vous pouvez vous en sortir avec GWT, qui est moins étranger pour les développeurs Java que jQuery et une bibliothèque de haut niveau telle que GXT avec un thème standard.
GWT avec GXT était pour nous un moyen simple et rapide de créer un ensemble d'applications internes. Avec l'équipe de Java développeurs de notre entreprise, nous ne serions jamais proches de la qualité, voire de l'exhaustivité des projets dans le même laps de temps.
Dirigez-vous simplement vers: la page d'exemple de GWT, présentant des exemples réels d'applications GWT
Lisez simplement la nature super lourde de ces exemples.
GWT lui-même n'est pas si léger, et je doute qu'il ait été conçu pour créer un datepicker. GWT est tout autre chose que jQuery également. Il est peut-être plus comparable à JSF2 qu'à jQuery. La question "dois-je utiliser GWT ou jQuery" pourrait être répondu comme:
si vous voulez ajouter des sélecteurs de dates, des effets, un tableau triable, une saisie semi-automatique ici et là. Vous devriez probablement aller avec jQuery.
Si vous voulez savoir si vous voulez utiliser GWT comme mécanisme de modèle/moteur frontal, vous devriez considérer d'autres qui sont réellement comparables. Lorsque vous discutez de Java, JSF2 est probablement votre seul choix. Et la courbe d'apprentissage JSF est abrupte.
Je creuse plus profondément et j'ai trouvé un triste post:
http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html
Je suis venu sur cette page parce que je lisais sur les projets à venir comme AngularJS, Backbone, les applications à page unique (SPA): En bref, Google a abandonné GWT. GWT est maintenant open source, car ils l'ont juste abandonné. Maintenant, AngularJS reçoit une grosse poussée de Google.
[~ # ~] modifier [~ # ~] notre cher andrew m'a dit de "prouver mon point"
voici l'algorithme à utiliser pour évaluer si une technique est compétitive.
1) Accédez à votre site d'emploi préféré
2) Recherchez les {technologies qui vous intéressent}
3) Vérifiez le nombre d'ouvertures, les exigences technologiques connexes, etc.
4) Répétez # 2 # 3 pour les technologies compétitives
5) Évaluer
aujourd'hui 19. mai 2016, sur upwork j'ai recherché GWT emplois.
Emplois: 23.
J'ai recherché angularjs emplois.
Emplois: 1338. C'est vrai. mille trois cent trente-huit.
point prouvé?
Je suppose que pour répondre au point 1, il faudrait regarder quelle est votre situation actuelle et quels sont vos objectifs.
Si vous avez une équipe de développeurs qui utilisent Java la plupart de leurs carrières, vous pouvez probablement vous attendre 6 mois pour apprendre les paradigmes de JavaScript. Si vous avez de l'expérience dans des langages comme Groovy ou Clojure, vous pourriez probablement réduire ce temps. Donc, si vous ne vous attendez pas à ce que le projet dure plus d'un an, alors GWT serait probablement la voie à suivre.
À l'inverse, si vous avez une équipe de développeurs JS, ils peuvent trouver le système de frappe statique plutôt frustrant et apprendre à l'utiliser efficacement pourrait leur prendre une demi-année. Donc, si c'est le cas, vous ne voudrez probablement pas utiliser GWT pour tout nouveau projet où la courbe d'apprentissage l'emporte sur la productivité.
Je ne sais pas vraiment quel point 2 demande. Si vous posez des questions sur les cadres de pile entiers, je suppose que vous pourriez trouver quelque chose en utilisant nodejs, bien que je ne pense pas avoir suffisamment d'expérience pour vous conseiller à ce sujet.
Au point 3, où je travaille, nous semblons nous diriger vers l'utilisation de frameworks JS (AngularJS en particulier) avec certains (nouveaux) serveurs/services écrits en Python et Groovy, et les systèmes hérités sont toujours en Java. Nous avons également quelques services en cours d'écriture en Clojure.