Open source et architecture logicielle

En revanche, il est beaucoup plus difficile d'associer un front AngularJS avec un serveur JEE (hors WS Rest). On peut donc affirmer que ces frameworks JavaScript sont peu compatibles avec JEE.

Je bosse en ce moment sur une appli Angular/J2E au boulot et le résultat fonctionne parfaitement. Je m'occupe davantage du côté Angular et le backend n'est pas vraiment RESTFull : nous appelons nos servlets en POST pour effectuer un traitement comme l'insertion ou la modification de données, et en GET pour de la récupération. Et du côté Angular, même si je n'ai pas non plus passé un temps incroyable dessus, je ne vois pas ce qui pourrait le limiter dans la communication avec d'autres webservices.

Je ne cesse d'entendre dire que GWT n'a plus d'avenir et qu'il sera remplacé à très court terme par des frameworks JavaScript comme AngularJS.

Je dirais plutôt qu'on ne cesse d'entendre des gens dire que GWT n'est pas mort. Comme si les développeurs qui travaillaient avec ce framework depuis 2006 ont une peur monstre de voir leurs principal outils de travail mourir, et ne pas réussir à passer la vague du mobile.

Concernant la compatibilité avec J2EE, je ne suis pas du même avis on peut parfaitement réaliser des applications J2EE avec des frameworks Javascript, de façon propre et sans couplage, il suffit d'avoir une couche de présentation adaptée, et il ne s'agit pas forcément de webservices. Tout est question d'architecture applicative correctement étudiée.

Ce qu'il faut retenir c'est qu'il n'y a pas que Java, il existe tout un tas d'autres techno pour faire du back, node.js, PHP, etc... Et je vois mal un developpeur PHP faire du GWT juste pour son front. Donc contrairement aux frameworks Javascript qui s'adressent à tous les développeurs Web & Mobile, GWT sera restreint dans 95% des cas aux projet purement Java. Donc du coup les frameworks javascript touchent une plus grosse communauté, ils évolueront mieux et plus rapidement qu'un framework front qui ne touche que la communauté Java.

Le mobile parlons en, GWT a aussi raté ce virage, ce qui était sa force au début (Le code unique qui fonctionne dans tous navigateur sur le papier) est devenu maintenant son nightmare, avec l'explosion du nombre de permutations (en 2006 on avait quelques navigateurs, maintenant on se retrouve avec tripotée de navigateurs et de fork de navigateurs différents selon les plateformes desktop/tablette/mobile.
Autant dire que j'aimerai pas faire partie des pauvres développeurs qui maintiennent ces permutations, car dans les faits ça ne fonctionne pas du tout sur certains terminaux mobiles.
Il y a un gros lack de composant graphiques, surtout dans le mobile, il existe 4-5 frameworks GWT apportant quelques composants graphiques, et en plus hybride pour certains, mais si on retire les frameworks payant, et ceux qui ne sont plus maintenus, il doit en rester 1 voir 2.

GWT est aussi conçu pour une architecture MVP bien vieillissante, alors que de nos jours on est plus sur du MVVM avec du two way databindings

Pour conclure, mon avis personnel est que GWT n' a aucun avenir en l'état, il a comblé un manque à l'époque, il garde ses inconvénients (Chronophage, pauvre en composants graphiques, compatibilité douteuse sur certains navigateurs, compilation énormément longues, 2 devmodes qui si ils n'en faisait qu'un seraient parfait, mais hélas il faut toujours switcher selon les bugs que l'on rencontre, et j'en passe pour tous les autres petits désagréments) et les seuls avantages qu'il avait ont été largement comblés avec les nouveaux frameworks javascript, maintenant on en garde que les inconvénients. Les nouveaux frameworks javascript (ou ES5, ES6, TS etc...) sont maintenant largement utilisables pour faire de grosses applications et en industrialiser leurs développements.
Si vous êtes déjà en GWT restez-y, si vous lancez un nouveau projet préférez un autre framework.

Vous avez dit que, pour faire de l'AJAX dans un projet basé sur JEE, on a que JSF, Spring MVC et GWT. Alors que pour faire de l'AJAX dans une application JSF ou autre on va devoir utiliser du JavaScript, alors je ne suis pas d'accord avec votre point de vue qui dit que les frameworks JS sont peu compatible avec JEE.

Je bosse moi aussi sur un projet pro JEE + Angular JS de grande ampleur (+ de 3000 jours-homme). Donc l'affirmation selon laquelle ces technos sont incompatibles me paraît franchement douteuse

J'irais plus loin en affirmant qu'un couplage fort entre front et back est très pénalisant et restrictif.

Voyons, je peux trouver en quelques minutes 10 raisons de découpler front et back au profit de web services :
1) une meilleure scalabilité grâce à une modularisation facilitée des web services (multiples endpoints, architecture micro-services...)
2) une spécialisation des profils: on embauche des spécialistes front plutôt que des gens polyvalents (qui, avouons-le, n'y connaissent souvent pas grand chose en JS quand ils viennent du monde Java)
3) une parallélisation des développements : les équipes front et back bossent en parallèle, grâce aux contrats d'interfaçage et aux bouchons JSON associés, ce qui accélère les développements
4) une meilleure testabilité en isolant les tests front et les tests back
5) la possibilité d'ajouter des fonctionnalités hors-ligne
6) la possibilité d'implémenter facilement des mécanismes de compensation de latence
7) des outils de dev dédiés front, qui accélèrent le temps de dev au quotidien (comparez un browser-sync avec live reload au temps qu'il faut à Eclipse pour redéployer une grosse application, c'est le jour et la nuit)
8) un versionning séparé entre front et back, qui évite de se mélanger les pinceaux et permet de trouver plus efficacement un commit foireux
9) avec des web-services bien conçus, on encourage et simplifie le développement de multiples front: on peut imaginer des interfaces personnalisées par client, voire des applis natives desktop ou mobiles utilisant ces web services
10) un affinage des choix de libs et frameworks front et back. Des solutions full-stack dignes d'intérêt, il y en a peut-être une dizaine tout au plus. Mais des frameworks client et serveur, il y en a des centaines, dont certains avec des concepts inédits.

Je ne me prononcerai pas sur GWT car je n'ai jamais utilisé la solution, et j'ai lu ici et là qu'ils n'étaient pas en retard question nouvelles technos front. Je tenais juste à réagir sur le postulat initial selon lequel, si rien n'était inclus dans les frameworks pour coupler back et front, cela signifiait qu'elles n'allaient pas bien ensemble. C'est totalement faux, ce sont des domaines bien séparés et la seule chose nécessaire pour les faire travailler ensemble, c'est un contrat d'interfaçage API.

Le seul intérêt que je prête aux solutions full stack comme GWT ou Meteor est lorsqu'on a une toute petite équipe (voire qu'on est tout seul) et qu'on a pas le temps ou l'envie de se former aux différents langages. Avoir un langage unique permet de passer outre cette difficulté, et d'avoir la mainmise sur toute son application. Mais dans un sens ou dans l'autre (les devs JS qui font du NodeJS ou les devs Java qui font du GWT), on sera toujours pénalisé dans le domaine qu'on connaît le moins. Les meilleurs outils ne remplacent pas la connaissance et l'expérience du métier.

Pareil je bosse sur un projet (un programme de plusieurs projets en fait) sur une archi REST JEE + front en Angular. Plusieurs dizaines de millions d'euros de budget donc gros aussi.

Les SPA js sont adaptées aux archi REST et sont agnostiques sur la techno mettant en oeuvre le back. Que ça soit du PHP du .NET du Java, du python, du js serveur, on s'en fout on veut consommer des webservices.

C'est un problème d'archi pas de techno.

Envoyé par ensi_en

Vous avez dit que, pour faire de l'AJAX dans un projet basé sur JEE, on a que JSF, Spring MVC et GWT. Alors que pour faire de l'AJAX dans une application JSF ou autre on va devoir utiliser du JavaScript, alors je ne suis pas d'accord avec votre point de vue qui dit que les frameworks JS sont peu compatible avec JEE.

Non, je dis que pour faire de l'Ajax dans l'écosystème JEE on ne dispose quasiment que de GWT, JSF et SPRING MVC. Et que seul GWT permet à un développeur d'en faire sans connaitre un mot de JavaScript.
Donc j'affirme que GWT permet de travailler avec des développeurs ne connaissant que JAVA.
En revanche, si tu as la chance de bien Maitriser les EJB ou les DTO et d'être très à l'aise avec AJAX alors je t'accorde que GWT n'est peut être pas la solution idoine.

Envoyé par Marco46

Pareil je bosse sur un projet (un programme de plusieurs projets en fait) sur une archi REST JEE + front en Angular. Plusieurs dizaines de millions d'euros de budget donc gros aussi.
Les SPA js sont adaptées aux archi REST et sont agnostiques sur la techno mettant en oeuvre le back. Que ça soit du PHP du .NET du Java, du python, du js serveur, on s'en fout on veut consommer des webservices.
C'est un problème d'archi pas de techno.

Et oui c'est pour cela que j'ai pris la précaution d'exclure les architectures consommant du WS Rest qui sont éligibles à un MVVC AngularJS.
Néanmoins, je reste agnostique quant à la pertinence d'utiliser AngularJS pour consommer du WS SOAP.
Je suis agnostique donc ni croyant ni athée je ne demande qu'à me faire démontrer

ça fait un moment que Google ne pousse pu trop GWT, tout comme dart et on pourrait trouver d'autre produit comme ça.
Il y avait trop peu de composant, soit tu perdait du temps à les faires soit tu optaits pour Sencha, SmartGWT, Vaadin.

Google font des produits pour eux avant tout, c'est pour ça qu'il faut faire un minimum attention quand on opte pour leur produit. On s'est jamais ce qui arrivera avec la techno à court/moyen terme.

Il y a l'air d'y avoir beaucoup de développeurs Javascript (ou framework associés) sur ce fil .

Je ne sais pas si vous l'avez lu, mais Arnaud Tournier a traduit et résumé la GWT.Create de l'année dernière détaillant la future version de GWT 3.0 ( http://lteconsulting.developpez.com/...-compte-rendu/ ). Integration simplifiée avec les librairies JS, refonte du compilateur, Java 8, GWT Modulaire, Singular, etc... Si GWT vous interesse, jetez y un coup d'oeil, c'est réellement instructif


Je ne vais pas revenir sur les avis trop tranchés, je vais juste compléter l'avis de SylvainPV qui laissait la porte entrouverte au GWT:

1) une meilleure scalabilité grâce à une modularisation facilitée des web services (multiples endpoints, architecture micro-services...) Je n'ai pas de visibilité sur ce point. J'ai travaillé sur de grosses applications, mais aucune architecturée de la sorte.
2) une spécialisation des profils: on embauche des spécialistes front plutôt que des gens polyvalents (qui, avouons-le, n'y connaissent souvent pas grand chose en JS quand ils viennent du monde Java). Les gros projets sur lesquels j'ai travaillé reposaient rarement sur du GWT pur pour la partie serveur. Bien souvent on associe du Spring (GwtPlateform comporte un exemple d'application de ce type). Pour les plus gros projets on peut donc se retrouver avec deux profils : Spring/hibernate et Gwt(IHM).
3) une parallélisation des développements : les équipes front et back bossent en parallèle, grâce aux contrats d'interfaçage et aux bouchons JSON associés, ce qui accélère les développementsLe système RPC consiste a définir un contrat simple (DTO et interface) entre le client et le serveur. Les développeurs peuvent donc travailler en parallèle sans difficultés.
4) une meilleure testabilité en isolant les tests front et les tests back. Nous aimons aussi cette idée en GWT. Nos tests unitaires ne s'attaquent qu'a un aspect (On teste un presenter, un modèle, une vue, un service, etc.)
5) la possibilité d'ajouter des fonctionnalités hors-ligne En GWT pur on a accès a n'importe quel JS ou fonction HTML5 (Interop, ou JSNI), donc aucun problème de ce coté la. Si on ne veut pas s'embeter, certains frameworks (Smart, entre autres), le gère nativement.
6) la possibilité d'implémenter facilement des mécanismes de compensation de latence Je manque d'experience sur le sujet. Peut être que d'autres développeurs GWT passeront.
7) des outils de dev dédiés front, qui accélèrent le temps de dev au quotidien (comparez un browser-sync avec live reload au temps qu'il faut à Eclipse pour redéployer une grosse application, c'est le jour et la nuit) SuperDevMode power ! Moins d'une seconde pour recompiler les changements effectués cotés client. Aucun redeploiement a faire, un petit F5 et c'est bouclé!
8) un versionning séparé entre front et back, qui évite de se mélanger les pinceaux et permet de trouver plus efficacement un commit foireuxUn bon architecte utilisera les projets Maven dans cette optique, avec un découplage plus fin (IHM, Services , Repository, Beans, etc).
9) avec des web-services bien conçus, on encourage et simplifie le développement de multiples front: on peut imaginer des interfaces personnalisées par client, voire des applis natives desktop ou mobiles utilisant ces web servicesLa encore je manque de visibilité sur le sujet. Les applications développées étaient compatibles mobiles et navigateurs, mais pas plus.
10) un affinage des choix de libs et frameworks front et back. Des solutions full-stack dignes d'intérêt, il y en a peut-être une dizaine tout au plus. Mais des frameworks client et serveur, il y en a des centaines, dont certains avec des concepts inédits. On aime l'idée en GWT aussi, et on le fait .

Bien malin qui pourra dire ce qui sera a la mode ou non dans 2 ans....

J'ai envie de dire que rien ne sert de se precipiter sur telle ou telle techno parce qu'elle fait le buzz.

Pour ma part, j'ai choisi GWT car notre serveur est en java et que cela permet de coder les interfaces de maniere unifiee et que c'est bien pratique dans un contexte dans lequel les dev sont orientés java.

Et meme si GWT devait cesser d'evoluer, l'architecture n'en resterait pas moins utilisable pendant quelques années encore.

A mon sens le choix doit avant tout se faire sur :
1) les priorites strategiques du projet : performance ? maintenabilite ? prototype avec une release rapide ? ...
2) les competences disponibles
3) l'existant
4) la perennite de l'outil

Merci Corr pour cet éclairage très pragmatique.
Je trouve ton analyse très réaliste, se sera certainement un gage de réussite dans tes choix d'architecture.

AJAX, GWT, ANGULAR, QT, JEE, etc...

Sinon il faudrait penser à arrêter de créer de nouveaux outils qui ne visent qu'à perdre les développeurs >_< grrrr

Je tombe sur votre sujet tout à fait par hasart:

Dans l'absolu, si on dispose de toutes les ressources et compétences valables pour tout faire dans 5 langages différents, plus l'organisation qui va avec, le couple AngualrJS + Bootstrap + Less + J2ee + SQL + Perl pour faire bonne mesure au niveau des scripts d'administration .... et bien c'est sensaass.

Sinon dans la pratique, si on a pas besoin d'une IHM supportant 3 grands navigateurs + les ipad + les tablettes android, GWT s'avère toujours efficace et productif ... car on n'a pas besoin de changer de langage et que l'on débugue dans le navigateur. Quand au prétendu vieillissement des composants, Vaadin est mis à jour régulièrement.