Quelle est la pérennité des frameworks Web Java au vu des évolutions technologiques actuelles ?
Partager votre point de vue
Le 2016-06-16 11:02:32, par Robin56, Modérateur
Pendant plus d'une décennie, les applications Web Java se sont appuyées sur un format assez commun :
Cependant, cette tendance tend à évoluer depuis quelques années. De nombreuses raisons émergent poussant à l'abandon de l'utilisation des frameworks Web Java. Est-ce un effet de mode ou cela se base-t-il sur de réelles bonnes pratiques ? C'est ce que nous allons tenter de cerner à travers ce débat.
Logan de l'équipe Java nous donne son avis sur cette tendance. Il l'explique par plusieurs points majeurs :
Envoyé par Logan Mauzaize
À travers son retour d'expérience, Logan met ainsi en évidence :
Toutes ces tendances vont dans le même sens : une plus forte utilisation de frameworks Web basés sur d'autres langages (JavaScript en premier lieu) et des modèles ne se basant plus sur les frameworks Web Java éprouvés. À noter que tout ceci met en évidence une véritable problématique : la maintenabilité de l'existant (la reprise des applications Web développées entièrement en Java).
Votre opinion
Pensez-vous ainsi que tous ces constats sont avérés ?
Et s'ils le sont, qu'ils mettent la perte de vitesse de Java dans le monde web, voire de la disparition à moyen terme des frameworks Web Java ?
La maintenabilité des applications existantes en Java ou la migration vers ces nouveaux socles peut-elle être un frein à cette transition technologique ?
Envisagez-vous une migration ?
N'oubliez pas de justifier toute position au sein de vos commentaires.
Pour aller plus loin
Voici quelques liens pour approfondir le sujet :
Merci à tous pour votre participation.
- un Front-End s'appuyant sur un framework Web Java (Struts, JSF, etc.) ;
- un Back-End en Java classique.
Cependant, cette tendance tend à évoluer depuis quelques années. De nombreuses raisons émergent poussant à l'abandon de l'utilisation des frameworks Web Java. Est-ce un effet de mode ou cela se base-t-il sur de réelles bonnes pratiques ? C'est ce que nous allons tenter de cerner à travers ce débat.
Logan de l'équipe Java nous donne son avis sur cette tendance. Il l'explique par plusieurs points majeurs :
- l'émergence des microframeworks comme mentionné à travers ce sondage : Utilisez-vous les microframeworks Java en 2016 ? Si oui, lesquels ? ;
- la popularisation des modèles à base de JavaScript du côté Front-End (à la place d'un framework Web Java). L'on peut citer AngularJS ;
- le passage à des solutions n'étant plus orientées Java (comme celles à base de NodeJS).
Toutes ces tendances vont dans le même sens : une plus forte utilisation de frameworks Web basés sur d'autres langages (JavaScript en premier lieu) et des modèles ne se basant plus sur les frameworks Web Java éprouvés. À noter que tout ceci met en évidence une véritable problématique : la maintenabilité de l'existant (la reprise des applications Web développées entièrement en Java).
Votre opinion
N'oubliez pas de justifier toute position au sein de vos commentaires.
Pour aller plus loin
Voici quelques liens pour approfondir le sujet :
- Quel framework Web Java utilisez-vous principalement en 2016 ?
- État de GWT en 2016
- Quel est votre retour d'expérience d'AngularJS sur la maintenabilité quand les applications grandissent ?
- Comment convaincre votre DSI d'adopter Node.js et AngularJS ?
Merci à tous pour votre participation.
-
yann2Membre expérimentéBonjour
Je ne comprend pas vraiment cette remarque parce qu'on peut très bien faire du SPA avec du MVC et MVC n'adresse pas de problématique de sécuritédu coup ? le 22/06/2016 à 14:46 -
OButterlinModérateurQuel rapport entre un protocole d'échange (SOAP) et un langage de programmation (Java) qui aurait été mis à mal ? On peut très bien écrire des webservice en java et utiliser SOAP comme format...
On n'a pas besoin de webservice pour échanger du JSON...
Du coup, ta phrase ne veut pas dire grand chose...
Non, ça ne marche pas de la même manière partout, loin s'en faut
Même avec jQuery on peut avoir des surprises d'un navigateur à l'autre.le 24/06/2016 à 18:07 -
tchize_Expert éminent séniorA la seule condition que tes pages web n'aient pas besoin d'être indexable par un moteur de recherche. Tu ne pourra pas créer un site de commerce en ligne par exemple sans générer des vues coté serveur, parce que c'est la seule choses que les robots d'indexation vont reconnaitre. Tu peux faire un site web pur JS, mais personne ne le visitera puisque personne ne le trouvera. Tu ne peux pas non plus créer des pages à partager sur facebook ou google plus qui utilisent du angularjs, sinon la preview dans les partages facebook sera ridiculement blanche.
Les applications single page, j'en fait. Du angular et du GWT. Le gros problème de ces technos, c'est que demander au browser de charger un JS de 3M pour afficher la page, c'est assez risible en terme de performances (et encore, avec GWT je monte à 20M de js). Alors on sort la moulinetter uglyfy pour améliorer les perfs et réduire l'empreinte mémoire de la page, ce qui rajoute à la mocheté de la chose. Mais d'un point de vue gestion, c'est bien pratique parce qu'on a beaucoup moins de traffic sur le serveur pour générer les vue et bien moins de prises de tête pour gérer des raraichissements partiels.
Aussi, les archi SPA, souvent, ne sont pas concues pour permettre une navigation multipage ("ouvrir dans un nouvel onglet", ce qui fout en l'air le flux de travail de l'utilisateur. Et enfin, comparez une belle page html avec du css3 bien propre et la même page générée par angularjs avec des template, la différence de consommation mémoire fait peur. J'ai des pages SPA qui occupent 200M dans le browser, ça fait peur. le 27/06/2016 à 11:24 -
ddoumecheMembre extrêmement actifPetit sondage en passant : qui croit à la pérennité de Node.js ici ?le 22/06/2016 à 11:09
-
Traroth2Membre émériteIl faut reconnaitre que dans les dernières versions, les navigateurs sont largement unifiés, même IE et Edge. Après, tout le monde n'a pas la dernière version.
De plus, il existe de nombreuses bibliothèques permettant de mettre à niveau, shim et polyfill, et bien sûr modernizr, qui permet de conditionner le fonctionnement de l'appli non par navigateur, mais par fonctionnalité disponible, ce qui est une bien meilleure pratique.le 22/06/2016 à 13:36 -
OButterlinModérateurOui, tout est toujours tout blanc ou tout noir, à croire que beaucoup de développeurs ne connaissent pas les 50 nuances de gris
Blague à part, je ne nie pas l'intérêt d'avoir des IHM plus dynamiques, la séparation des couches, du design et de la couche métier, est très intéressante, les 2 nécessitant des compétences particulières que peu de gens cumulent...
Mais bon, peut-être le problème vient-il de javascript justement, ce n'est peut-être pas la meilleure réponse, c'est en tout cas mon avis vu les problématiques de ce langage pour le moment... Je ne peux qu'espérer qu'il y aura une unification du langage qui permettra d'éviter les écueils de compatibilité. Ou alors un langage comme Dart JS... je m'en fiche un peu, du moment que ça fonctionne partout...le 22/06/2016 à 21:30 -
OButterlinModérateurIl n'y a pas qu'un type d'application web, je ne pense pas que les nouvelles tendances visant à déporter une partie de la charge de l'interface au poste client soient forcément une bonne chose, j'ai toujours le problème de la compatibilité du javascript sur les différents navigateurs.
Pour moi, tant qu'il n'y aura pas unification de ce langage sur les navigateurs, il n'y aura pas d'avenir dans ce sens... ça reviendrait à imposer un navigateur pour une application, un non sens total !
Les frameworks "à l'ancienne" comme disent certains me semblent évoluer dans le bon sens, intégrant du "dynamisme" javascript à l'IHM.
Le couple JSF2/Primefaces reste pour moi une référence pour le développement d'applications RIA.
Pour un site de vente en ligne à fort trafic, j'utiliserais certainement autre chose, plus "basique" et donc plus réactif...
Pour ce qui est de l'utilisation abusive de la session (HttpSession), c'est surtout un problème de mauvaises pratiques des développeurs qui se simplifient la tâche plutôt que de se poser les bonnes questions...
Ceci dit, rien n'est pas parfait, dans aucune des technos d'ailleursle 16/06/2016 à 12:32 -
ddoumecheMembre extrêmement actifPersonnellement, je pense que les frameworks basés sur du Javascript sont très innovants car créés surtout par de jeunes enthousiastes, et directement impactés par les changement de mode graphique des OS.
Comme cela ne coute pas très cher de créer un tel framework, mais qu'en plus il faut vendre du service aux éditeur de contenu en ligne, les frameworks sont condamnés pour l'instant à une perpétuelle évolution.
En conséquence, struts est mort depuis longtemps et JSF suit son chemin (de toute façon, personne n'a pas le digérer) avec une quantité d'offres d'emplois ridicule.
Coté backend, on ne ressent pas une telle nécessité d'évolutions permanente et JavaEE et Spring sont donc là pour durer.le 22/06/2016 à 10:23 -
Eric30Membre actifSingle Page Application
Une bestiole qui consiste comme son nom l'indique à transférer toute la charge au client, la page ne se chargeant en fait qu'une fois, le navigateur, via JavasScript, ne récupére que les données utiles, la mise en forme ne se faisant que côté client.le 22/06/2016 à 10:48 -
CincinnatusMembre expérimentéPour ce qui est des SPA en javascript, hier j'ai commencé à lire le support d'une présentation sur le "futur" du web, afin de voir si regarder la vidéo sur InfoQ valait le coup.
L'auteur s'amuse à mixer Angular2 et React, featherjs (?), Redux (?), webpack (??)... Pour arriver à suivre il faut être l'auteur d'au moins 2 de ces frameworks !
Tout ça pour dire que les frameworks javascript sont encore plus menacés d'obsolescence ! Pour rappel, Primefaces, cité plus haut, utilise JQuery en définissant des composants par dessus, et toute la partie JS est masquée (mais reste accessible si nécessaire). çà c'est le meilleur des deux mondes : du solide (Java) et du réactif côté client / ajax (Primefaces/Jquery).le 23/06/2016 à 10:23