Discussion :

[Robin56]

En 2012, l'équipe Java avait réalisé un sondage concernant l'utilisation des frameworks Web Java par nos membres.

Vous pouvez y trouver les résultats ci-dessous :

Sondage d'utilisation des frameworks Java Web réalisé en 2012

On y trouvait alors les tendances suivantes :

• une forte utilisation de frameworks matures : Java Server Faces, Struts et Spring MVC ;
• la montée en puissance de GWT ;
• l'utilisation de frameworks plus à la marge : Play! et Wicket.

Nous avons donc décidé de renouveler ce sondage en ce début d'année 2016. Depuis quatre ans, le paysage a évolué. On peut donc citer les évolutions suivantes : (Vaadin, Play 2, Grails, etc.). Profitez-en pour donner les raisons de votre choix en insistant par exemple sur :

• la prise en main ;
• la documentation ;
• la communauté ;
• la pérennité.

Merci à tous pour votre participation.

Nicolas pour l'équipe Java.

[OButterlin]

JSF / Primefaces
Le framework est une chose mais la bibliothèque de composants est au moins aussi importante.
JSF est la suite logique de struts, il y a quelques points discutables mais ça fonctionne et c'est très facile à prendre en main (je trouve).
Il faut bien comprendre le cycle, ensuite, les choses coulent de source.

Ce n'est pas le framework à conseiller pour des applications à très fortes utilisations, mais pour des RIA, c'est cool.

[robertledoux]

Nous utilisons Play Framework 2.4.x en déclinaison Java pour l'intégralité de nos projets web.

[nefelpitto]

Nous utilisons Play Framework 2.4.x en déclinaison Java pour l'intégralité de nos projets web.

Pareil dans ma boite, a l'exception de mon equipe qui utilise Play avec scala. Excellent framework pour construire des micro-services.

[jeffray03]

Nous utilisons chez nous:
-- Struts pour les anciens projets
-- JSF / PRIMEFACES pour les nouveaux projets

eric

[nchal]

JSF / Primefaces, ça tourne gentiment

[Cincinnatus]

Nous utilisons chez nous:
-- Struts pour les anciens projets
-- JSF / PRIMEFACES pour les nouveaux projets

eric

Pareil, pour les développements Java :
- Struts 2 pour les anciens développements (en évolution pour certains), avec DWR pour l'Ajax,
- JSF avec Primefaces depuis fin 2014.

Un ensemble de composants tels que Primefaces était la condition sine qua non pour utiliser JSF 2, JSF ayant été retoqué il y a quelques années.

Une des principales différences que je vois entre les 2 :
- JSF est plus orienté composants, on peut avoir plusieurs beans indépendants en backend des pages,
- Struts 2 est plus orienté page, on utilise un contrôleur par page Web.

[Alvaten]

Chez nous nos principaux projets sont en Grails

On a aussi un projet en GWT mais la techno n'est pas très populaire parmi les dev

[Invité]

Hibernate n'est pas là ?

[Mickael Baron]

J'ai répondu GWT. Quand j'ai de grosses applications web à coder, je passe par du GWT. Sinon je fais du JavaScript pour le front et Java pour le backend.

Hibernate n'est pas là ?

Ce n'est pas un framework web

On a aussi un projet en GWT mais la techno n'est pas très populaire parmi les dev

Quel dommage. Et dire qu'à l'époque tout le monde jurait pour cette technologie.

Mickael

[Invité]

Ce n'est pas un framework web



Quel dommage. Et dire qu'à l'époque tout le monde jurait pour cette technologie.

Mickael

J'avais mal lu l'article pardon...

[tchize_]

Quel dommage. Et dire qu'à l'époque tout le monde jurait pour cette technologie.

Mickael

Ben GWT est bien pratique sur certains aspect, mais il n'y a rien à faire, les 2 à 3 minute de compilation par variation, ça fous mal au cul. à un moment donnée en mettant les axes langue + les axes browser, on en était à plus de 1h30 de compilation GWT

[OButterlin]

Quel dommage. Et dire qu'à l'époque tout le monde jurait pour cette technologie.

Ceux qui avaient testé avec 2 pages de 3 ou 4 champs peut-être
A l'époque, j'avais été réquisitionné pour valider un développement GWT au sein de la DSI... j'ai tout pété et j'ai remplacé GWT par un bon vieux Struts1/Struts-Layout qui mettait GWT à des parsec en temps de réponse...
Si GWT a séduit en son temps, c'était plus par la richesse de ses composants que par autre chose je pense...

Il est vrai que JSF/JSF2 peine à trouver sa cible, après autant d'années de gestation/évolutions, il y a toujours des choses qui ne fonctionnent pas bien, par exemple le @ViewScoped, qui pourtant est un des plus intéressants...

[Mickael Baron]

Ben GWT est bien pratique sur certains aspect, mais il n'y a rien à faire, les 2 à 3 minute de compilation par variation, ça fous mal au cul. à un moment donnée en mettant les axes langue + les axes browser, on en était à plus de 1h30 de compilation GWT

C'était à l'époque. Maintenant c'est beaucoup plus rapide. Même pour tester en dev avec le Super Dev Mode c'est très rapide.

Pour ma part, actuellement moi c'est Vaadin sur mon projet.

@Robin56, Vaadin c'est basé sur GWT, non ? J'ai toujours eu une bonne impression de ce framework. Le site est bien fait, pleins de fonctionnalités...

Mickael

[Robin56]

@Robin56, Vaadin c'est basé sur GWT, non ? J'ai toujours eu une bonne impression de ce framework. Le site est bien fait, pleins de fonctionnalités...

En effet c'est basé sur GWT. Des petites expériences que j'avais eu sur GWT, je trouve Vaadin plus simple à prendre en main. C'est un peu une façon de faire du Swing mais dans un environnement Web.

Après comme précisé par d'autres membres au dessus, une certaine lourdeur de compilation qui peut se faire sentir aussi. Mais je trouve que la prise en main est assez rapide (plus rapide qu'avec GWT personnellement).

[knarficious]

Je ne connais pas les autres, mais l'architecture de Spring est cohérente et conventionnelle.

[Gugelhupf]

Venant de Java EE (Servlet specification 2.5 à 3.1 + étudié 4.0), ayant pratiqué JSF2.x, ayant étudié Spring 3, j'ai voté pour... Spring MVC car c'est celui que j'utilise principalement cette année au travail.

Voici mon aperçu :

Positif	Negatif
Un projet Spring est très simple à mettre en place depuis la version 4 du framework. Il suffit d'indiquer la dépendance Spring Boot, puis de créer une classe main avec une annotation Spring Boot... et le tour est joué ! Fin de la préhistoire, adieu les fichiers XML de configuration pour créer des beans.	La documentation indique qu'il est nécessaire d'utiliser la balise <parent> du pom.xml pour récupérer Spring Boot, sauf que les modules dans Maven c'est comme les langages où l'héritage multiple n'existe pas : il n'est possible que d'avoir 1 seul parent, du coup il aurait été préférable de présenter des alternatives comme <dependencyManagement> pour ce type de dépendance, bien sûr ceci n'est qu'un détail.
Très rapide à s'exécuter grâce à Spring Boot, Spring embarque Tomcat (ce dernier est transparent) et ne nécessite que peu de configuration à mettre en place au niveau du pom.xml (pour ceux qui l'utilise avec un Maven). On oublie tout de suite les problèmes cancérigènes qu'on aurait pu avoir avec un projet Servlet 2.5 et une modification du fichier web.xml qui n'est pas pris en compte par Tomcat lors d'un arrêt de ce dernier.	Parlant de configuration, Spring est rétrocompatible, et donc il est possible de configurer quelque chose de plusieurs manières différente, personnellement je ne considère pas X façons de configurer quelque chose comme une richesse, mais plutôt une prise de tête.
Très répandu, ce framework est à l'initiative de l'injection de dépendance (IoC). L'apprentissage est simple car on comprend vite le rôle des composants de types @Controller, @Service, @Repository, ce qui n'est pas forcément le cas avec les annotations utilisées par le standard Java EE.	Une fois vous être lancé dans ce framework, vous vous rendrez vite compte que ce framework fait la guerre au standard Java. Mis à part les types de base et String, on à l'impression que Spring ré-implémente toutes les classes existantes.
La force de Spring réside dans le back, aujourd'hui en 2015/2016 les technos HTML5 et Angular sont très populaires et Spring n'impacte pas sur le front comme pourrait le faire un framework orienté composant tel que JSF avec ses Facelet ou GWT.

[Babas007]

Je vote JSF car c'est ce qu'on utilise pour notre projet. Est-ce que personnellement j'opterai pour cette technologie pour un nouveau projet? La réponse est: bien sûr que non!
En 2011, j'étais convaincu que c'était LA techno a utilisé, lorsque je voyais la simplicité et le résultat du showcase de Primefaces: j'étais tout simplement convaincu. Mais depuis que je travaille sur un gros projet, c'est tout l'inverse:

• Lorsque quelque chose ne fonctionne pas, et qu'on cherche à résoudre le problème en debug. C'est comme chercher une aiguille dans une bote de foin: c'est un vrai bordel, difficile de savoir d'où l'on vient. Toutes les méthodes sont appelés par rélfexion, un vrai mystère. Parlons événement Primefaces, mon listener peut prendre un ActionEvent en paramètre comme rien du tout, ça marche quand même...
• J'étais surpris de voir à quel point il était difficile de faire choses très simple en JSF,
• Les performances! L'arbre JSF! Mais quel horreur! La page client est sauvegardé coté serveur... Enough said...
• Trop de subtilités difficile à cerner que ce soit au niveau du render time, build time, les annotations JSF que l'on peut pas utilisé dans le cas d'un FileUpload par exemple, le binding, le process, l'update, etc.
• La communauté JSF se résume aux réponses impressionnantes de BalusC

J'imagine que si JSF ne faisait pas parti du standard JEE, ce framework serait déjà abandonné depuis bien longtemps. Je vous invite a voir tous les posts qui parlent de "why i hate JSF" et "why i love JSF", faites la comparaison, et vous en arriverez certainement à la même conclusion. Que choisirais-je alors? Alors aujourd'hui, je m'orienterai vers un front-end angular.js, ou bien Vaadin 7 que je trouve bon (souple, performant, riche en composants, on y retrouve pas tout plein de cas bizarre comme rencontré sur JSF)

Je vous pose alors la question: quel est la valeur ajouté de JSF? Qu'est ce qui est génial à propos de ce framework?

Bien à vous,
Babas007

[Gugelhupf]

quel est la valeur ajouté de JSF? Qu'est ce qui est génial à propos de ce framework?

Je n'irais pas jusqu'à dire que c'est génial, mais ça permet d'injecter tes beans directement dans la Facelet, et de t'abstraire toute la partie liée aux appels Ajax, ça gère le token CSRF implicitement sans que tu ailles toi-même créer un champ avec un attribut hidden (tu as un peu plus la main depuis la version 2.2 : documentation). Aussi ça part du principe que tu utilises des composants graphiques tout fait tel que Primefaces : JSF un framework orienté pour ceux qui font principalement du Java et qui n'ont pas de forte contrainte lié à la création de composant graphique spécifique, donc ayant recours à du CSS et JS. A l'opposé tu as ceux qui font tout en JS, avec de belles interfaces avec AngularJS et qui gèrent leur back en JS avec NodeJS, stratégie basé sur du full-JS.

[OButterlin]

Les performances! L'arbre JSF! Mais quel horreur! La page client est sauvegardé coté serveur... Enough said..

Ben non, tu as le choix, tu peux sauvegarder l'état de l'arbre côté client (javax.faces.STATE_SAVING_METHOD=client), personnellement, je préfère côté serveur, dans tous les cas, à un moment donné, il faudra bien reconstituer l'arbre... d'un point de vue sécurité, le côté client pose problème.

Ensuite, je dirais que comme tout framework, le préalable est de l'apprendre correctement, ce n'est pas en regardant un showcase qu'on sait comment fonctionne JSF. La plupart des problèmes que tu décris dénotent plutôt d'une mauvaise connaissance du cycle de vie JSF .

Pour la question : Pourquoi JSF ?... on peut discuter...

Je dirais, tout dépend du type d'application qu'on veut faire.
Nous avons fait le choix de JSF2/Primefaces dans notre société parce que nous développons des applications RIA, pas un nombre élevé d'utilisateurs connectés (max 500 sur une application). Dans CE contexte, le couple JSF2/Primefaces s'avère bluffant de simplicité et d'efficacité.
Contrairement à ce que dit Gugelhupf, JSF2 est ultra adapté pour développer des composants graphiques, les composite-components sont tout simplement géniaux, j'en développe plein.
Il y a des choses qui ne fonctionnent pas très bien avec certains scopes, par exemple le binding avec du @ViewScoped (d'ailleurs ce scope reste incompréhensible dans sa phase de création en plusieurs étapes )

Pour ce qui est des alternatives, les frameworks javascript peuvent poser des problèmes de compatibilité avec les navigateurs, un comble pour une application internet... il ne manquerait plus qu'on impose un navigateur au client !
Dans le principe, j'aime bien... en pratique