Quelle est la pérennité des frameworks Web Java au vu des évolutions technologiques actuelles ?

Quelle est la pérennité des frameworks Web Java au vu des évolutions technologiques actuelles ?
Partagez votre point de vue

Pendant plus d'une décennie, les applications Web Java se sont appuyées sur un format assez commun :

• 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 :

Citation:

---

Envoyé par Logan Mauzaize

1. Le tout Web
Tout est connecté à Internet et pas simplement des ordinateurs : téléphone, tablette, TV, appareil photo, montre, voiture, frigo, absolument tout ! Toutes ces vues possibles deviennent ainsi difficiles à gérer pour un serveur d'application.

La vue se décorrèle encore davantage de la logique métier et de l'organisation des données.

2. Nouveaux standards
La standardisation des HTML5, CSS3 et autre ECMAScript 2015 permettent aujourd'hui aux développeurs de réaliser des applications Web très riches plus sereinement. Ces standards ont certainement aidé les navigateurs à devenir plus performants. Il faut ajouter à cela que les machines deviennent toujours plus puissantes.

Ces éléments permettent ainsi aux applications Web de prendre en charge des calculs (et donc la gestion de la vue) qu'on limitait autrefois aux clients riches.

3. Scalabilité
Puisque tout est connecté, le nombre de requêtes tend à exploser. Les serveurs d'applications doivent donc se munir d'un maximum de puissance pour être en mesure de le gérer. Séparer du traitement des données et de la génération de la vue est alors un élément nécessaire.

À cela s'ajoute que les frameworks Web sont souvent gourmands en données de session, car orientés stateful.

4. Orientation service
L'interconnexion des systèmes est également une tendance. Les frameworks Web ne permettent alors pas toujours de gérer ce type d'interface. Il devient plus logique de structurer une organisation en service plutôt que de servir du contenu web.

5. Volatilité
L'utilisation des frameworks Web tend également à s'enfermer dans une technologie. En effet, difficile de changer de framework ou carrément de socle technologique. La séparation de la vue permet ainsi de faciliter la transition technologique aussi bien niveau vue que côté traitement des données. Une équipe peut ainsi bénéficier plus facilement d'une organisation Front-End/Back-End plutôt que des développeurs Full-Stack.

Ce n'est pas la fin pour autant
La gestion d'interface côté serveur a encore quelques beaux jours devant elle. Nombreuses sont les personnes formées à Java et ses différents modèles de développement Web, mais beaucoup moins pour gérer des services, du JavaScript, etc. Les éléments de sécurité également restent à la charge du serveur. Il est alors parfois plus simple de tout gérer côté serveur pour garder le contrôle des données diffusées.

À noter qu'Angular2 fournira également un service permettant d'effectuer du prérendu (et donc du calcul de vue) auprès du serveur.

---

À travers son retour d'expérience, Logan met ainsi en évidence :

• 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

:fleche: Pensez-vous ainsi que tous ces constats sont avérés ?
:fleche: 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 ?
:fleche: La maintenabilité des applications existantes en Java ou la migration vers ces nouveaux socles peut-elle être un frein à cette transition technologique ?
:fleche: 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 :

• 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.

Il 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 ! :roll:

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'ailleurs ;)

Voila un sujet intéressant mais pour rappel Angular est uniquement destiné aux SPA ?
Donc tous le reste on fait comment coté client ?

Citation:

---

Envoyé par neoncyber

Voila un sujet intéressant mais pour rappel Angular est uniquement destiné aux SPA ?

---

C'est quoi cette bête ???

Citation:

---

Envoyé par OButterlin

Il n'y a pas qu'un type d'application web

---

Je suis tout a fait d"accord.

Certaine applications n'ont pas besoin de dynamise et pour cela, un bon vieux framework à l'ancienne fonctionne très bien.
Il ne faut pas oublier non plus les sites qui ont besoin d'accessibilité, et Javascript et accessibilité ne font pas bon ménage.

Bon après si on pouvait vraiment foutre certain framework à la poubelle çà serai un bonne chose.....

Personnellement, 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.

Citation:

---

Envoyé par OButterlin

C'est quoi cette bête ???

---

Single 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.

Citation:

---

Envoyé par bilgetz

Je suis tout a fait d"accord.

Certaine applications n'ont pas besoin de dynamise et pour cela, un bon vieux framework à l'ancienne fonctionne très bien.
Il ne faut pas oublier non plus les sites qui ont besoin d'accessibilité, et Javascript et accessibilité ne font pas bon ménage.

Bon après si on pouvait vraiment foutre certain framework à la poubelle çà serai un bonne chose.....

---

Je partage en partie cette opinion.

Il y a en effet plusieurs types de besoins. Certains gros framework seront adaptés dans certains cas (des applications par exemples) là ou des micro-frameworks seront plus intéressant quand on a besoin de moins de choses: API, WebServices...

C'est difficile d'avoir un avis tranché.

Citation:

---

Envoyé par OButterlin

C'est quoi cette bête ???

---

https://en.wikipedia.org/wiki/Single-page_application

- La popularisation des SPA touchent tout les framework et toutes les technos (même NodeJS). L'excuse de l'interopérabilité entre les différent navigateurs est aujourd'hui quasi obsolète (si on oublie IE..). Certes, Angular &co ne sont pas adaptés pour tout les cas d'usages mais sont maintenant incontournable pour des applications riches.

- l'arrivée des SPA entraîne moins de besoins côté back end, d'ou le gain d'interêt pour des framework plus léger.

- Et d'un autre côté il y a bien un effritement de la popularité de JAVA en tant que back end web :
src : https://www.google.com/trends/explor...tz=Etc%2FGMT-2
Je trouve la courbe particulièrement intéressante, elle montre java perd globalement en popularité au fil du temps malgré l'arrivée d'Android. Si on regarde uniquement les statistiques sur les pays développés, le choc est d'autant plus brutal alors que la Chine et l'Inde font le chemin inverse.

Plusieurs raisons, avec les SPAs, on fait moins de java côté front-end. Mais également l'arrivée de nouvelles alternatives comme NodeJS ou encore dans une moindre mesure, les languages alternatif de la JVM Scala, Clojure. Et plus globalement avec l'avènement des archi micro-services, on ne crée plus comme il y a 10 ans des SI mono-langage et mono-database.

- Pour la question de la migration, ça implique de réécrire entièrement le front-end + une façade REST sur le back-end. C'est très lourd surtout si on rajoute la potentielle montée en compétence de l'équipe.

Petit sondage en passant : qui croit à la pérennité de Node.js ici ?

Citation:

---

Envoyé par Eric30

Single Page Application

---

Merci pour la précision, SPA étant plus connu comme la Société Protectrice des Animaux, la recherche sur google m'a gonflé :weird:

Bah là, des applications d'une seule page, je ne sais pas trop ce que ça représente en volume comme applications, ce qui est sûr, c'est que ça ne correspond pas du tout à ce qu'on développe chez nous...
Si l'IHM s'adapte profondément entre les interactions (construction dynamique de l'écran), on en reviendrait à réinventer l'applet... en moins stable...

Bon, personnellement, j'aime bien le javascript pour enrichir le html monolithique... si l'avenir est là, pourquoi pas après tout, il faut savoir évoluer en permanence dans ce métier, c'est ce qui fait son intérêt (à mes yeux) ;)

Citation:

---

Envoyé par petogo

...L'excuse de l'interopérabilité entre les différent navigateurs est aujourd'hui quasi obsolète (si on oublie IE..)...

---

Tu reconnais que l'interopérabilité entre navigateur n'est pas totale là...
Et bien si tu veux développer des applications quasi utilisables, c'est ton droit, je ne me vois pas dire à des clients : "Bah, faut changer votre navigateur, IE c'est de la daube, plus personne n'utilise ça"

Idem pour Firefox/Opera/etc... puisqu'on a le cas d'une application javascript qui ne fonctionne QUE sur IE et Chrome :aie:

Il 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.

Citation:

---

pour rappel Angular est uniquement destiné aux SPA

---

Pas du tous. Beaucoup de societé l'utilise avec MVC pour des question de securité.

Bonjour

Citation:

---

Envoyé par Aeson

Pas du tous. Beaucoup de societé l'utilise avec MVC pour des question de securité.

---

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 ?

On peut aussi utiliser Angular dans le cadre de sites traditionnels sans faire du SPA, c'est même assez courant.
Genre on fait un site classique qui fonctionne avec des liens, en page à page, et pour certaines interfaces très dynamiques, on embarque une section en angular dans la page. C'est courant, et parfois plutôt souhaitable. Contrairement à la croyance populaire, ça peut être très léger avec l'utilisation de cache pour tout ce qui est statique et du JS pour les parties dynamiques. Et aussi question SEO et bookmarks, les SPA c'est pas encore ça.

Le full SPA, c'est rarement nécessaire, c'est souvent 2 ou 3 sections d'un site qui demandent beaucoup de dynamisme, pas la totalité.

A part ça, par contre pour ce qui est des frameworks java qui ont une approche tout composant (vaadin, gwt, JSF), là perso avec les progrès de JS côté client, je sens un recul.

Les développeurs JEE ont tendance à privilégier les applications d'entreprise au détriment des applications grand public. Je pense que c'est un tord. La tendance est au déplacement dans le cloud avec des applications métier qui ont les mêmes exigences que les applications grand public.

Pour le grand public, les besoins sont dictés par les usagers qui attendent la meilleure expérience utilisateur possible, avec aussi une exigence de design. D'autre part, ces applications ont de fortes contraintes financières, contrairement aux applications d'entreprises qui sont conçues autour d'un budget. Les applications dans le cloud sont initiées par des startups qui raclent les fonds de tiroirs. La richesse de l'écosystème Java est aussi la source de son inconvénient, sa complexité fait fuir. Inversement, les technos autour de JS tombent pile dans les critères des startups : un langage plébiscité par des jeunes qui coûtent moins cher que leurs aînés, sans compter que JavaScript étant moins verbeux que Java, il nécessite moins d'heures de dev que JEE.

Bref, développeurs Java (je suis des vôtres), vous avez tord de considérer JavaScript avec dédain. La tendance est clairement à ce langage, ouvrez les yeux. Vous parlez de JEE comme certains parlent encore de Swing. Bon j'exagère. JEE n'est pas mort, loin de là. Java a un socle solide du fait que la plupart des grandes entreprises qui ont rénové leur SI autour de JEE au cours des dix ou vingt dernières années. Mais la tendance actuelle est la prédominance de l'initiative informatique aux startups pour lesquelles JEE est trop lourd. Quand j'entend encore parler de JSF, ça me fait bondir. Cette techno est complètement dépassée. Il existe des tendances, au-delà des modes, en informatique, et la tendance est à l'usage de frameworks qui sont nativement responsive, je pense en particulier à Bootstrap. Je vous souhaite bien du bonheur à concevoir une application responsive avec JSF. Et ceux qui méprisent la problématique de la responsivité sont complètement à côté de la plaque. Là encore il y a des tendances de fond qu'il faut avoir la clareté d'esprit de saisir.

Tout ça pour en revenir à mon premier propos. Je pense que trop de développeurs JEE sont limités dans leur vision à l'univers des applications d'entreprises.

Bonjour à tous,

débat très intéressant, mais avec des postulats assez manichéen ...

Pour ce qui concerne les frameworks java, je doute qu'ils meurent de si tôt. Et ça ne serait pas une bonne chose. Je rejoins OButterlin sur l'efficacité du couple JSF/Primefaces. Certes, l'utilisation du javascript y est pour beaucoup. Mais çamarche très bien, et ca continuera (Primefaces est quand même très vivant). Et le fait d'avoir une stack très intégré a aussi des avantages.

Après, je m'essais depuis peu à l'autre côté du spectre, avec les microservices. Pour être précis, vert.x et vue.js. Et effectivement, c'est très intéressant. Côté serveur, on gagne clairement en modularité, ce qui permet entre autre de faire des déploiements au fur et mesure que les composants. Le deploiement est également beaucoup plus simple, avec des fatjar ou des container docker directement. Et enfin, si on combine avec une base Mongo, on traite les objets json de bout en bout, ce qui est appréciable.

Côté client, j'ai moins avancé dans mes test, mais je trouve vue.js assez agréable a utiliser. J'avoue qu'à première vue, le fait de travailler le front en pur JS offre plus de liberté. Le fait que vert.x soit polyglotte doit également aider.

Pour ce qui est de la question de la compatibilité, je pense qu'au delà il faut faire comprendre aux clients que faire des upgrades de leurs navigateurs n'est pas uniquement nécessaire pour nous faciliter la vie. C'est aussi une question de sécurité ...

Citation:

---

Envoyé par Cafeinoman

débat très intéressant, mais avec des postulats assez manichéen ...

---

Oui, tout est toujours tout blanc ou tout noir, à croire que beaucoup de développeurs ne connaissent pas les 50 nuances de gris :mouarf:

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...

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 ! :aie:

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).

Citation:

---

Envoyé par OButterlin

Oui, tout est toujours tout blanc ou tout noir, à croire que beaucoup de développeurs ne connaissent pas les 50 nuances de gris :mouarf:

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...

---

Je suis passé par les deux phases. Venant du monde des applications de bureau (fat clients).

J'ai été un fervent défenseur de l'approche composant, avec 0 JS écrit à la main. Depuis que c'est plus forcément considéré comme un crime de ne plus supporter IE8, faire du javascript n'est plus aussi frustrant que ça l'était il y a encore 5-6 ans, j'ai mis de l'eau dans mon vin. Les frameworks JS font généralement un assez bon travail à niveler les petites différences qui restent. Le langage reste un peu dégueulasse pour les gens qui sont habitués à du typage statique et de la compilation mais avec des outils comme typescript, ça va tout seul. Je trouve que de nos jours, l'argument d'utiliser un framework orienté composant pour ne plus faire de javascript a perdu un peu de son éclat. Du coup je me suis remis sur les solutions plus "orienté requêtes" avec modèle traditionnel : URL => Controller => templating HTML / retour JSON.

En plus, on se rend finalement compte que le design c'est un métier, en cours de route j'ai accepté le fait que ce n'était pas le mien et que je serais toujours une grosse bille en CSS/HTML, c'est aussi plus simple pour moi de déléguer ou d'outsourcer du html recraché par Spring MVC, Play, ou Grails que d'aller faire un thème pour JSF, Vaadin ou GWT. La séparation est bienvenue. Puis j'ai l'impression de mieux contrôler ce qui se passe sur le serveur ou le client, même si ça implique plus de micromanagement. Wicket avait trouvé un compromis sympa pour résoudre ce problème de séparation entre le design et le backing code mais bon, il avait passablement de défauts aussi.

Je pense quand même que Java a plutôt bien tenu la route question pérennité, il y a eu des frameworks web par dizaines qui ont fait leur temps, c'est vrai. Je regretterai toujours qu'on ait voulu transformer les navigateurs en OS mais il y a eu un gros paquets de changement dans les façons de concevoir les applications webs. Il y a plus beaucoup d'UI web écrites y'a 10 ans, ou même 5 ans qui restent maintenues. Pour moi c'est donc logique qu'avec ces évolutions, certaines solutions d'il y a 6-7 ans en arrière, qui étaient pensées pour répondre aux problématiques précises de leur époque, soient devenues caduques.

Ce qui a fait le plus de mal à java au fond, c'est peut être pas la myriade de frameworks de qualité très variable, mais l'illusion du domain model tout objet, la surabstraction, les gâteaux à 7 couches et la surarchitecture en général. Je pense que la mentalité présente entre 2005-2010 dans le monde Java a donné les pires monstres architecturaux au détriment des solutions simples et que ça a énormément nuit à l'image de cette techno. Avis personnel qui n'engage que moi.

Citation:

---

Envoyé par verbose

Quand j'entend encore parler de JSF, ça me fait bondir. Cette techno est complètement dépassée. Il existe des tendances, au-delà des modes, en informatique, et la tendance est à l'usage de frameworks qui sont nativement responsive, je pense en particulier à Bootstrap. Je vous souhaite bien du bonheur à concevoir une application responsive avec JSF. Et ceux qui méprisent la problématique de la responsivité sont complètement à côté de la plaque. Là encore il y a des tendances de fond qu'il faut avoir la clareté d'esprit de saisir.

---

Bonjour,
je rebondis simplement sur ce propos, il n'y a AUCUN PROBLÈME à intégrer Bootstrap et JSF... et donc rendre responsive une application JSF. C'est faisable à la main et il existe même des librairies (Bootfaces, Butterfaces...) mais on peut largement s'en passer.

Citation:

---

Envoyé par _skip

Ce qui a fait le plus de mal à java au fond, c'est peut être pas la myriade de frameworks de qualité très variable, mais l'illusion du domain model tout objet, la surabstraction, les gâteaux à 7 couches et la surarchitecture en général. Je pense que la mentalité présente entre 2005-2010 dans le monde Java a donné les pires monstres architecturaux au détriment des solutions simples et que ça a énormément nuit à l'image de cette techno. Avis personnel qui n'engage que moi.

---

C'est un problème récurrent... on peut vraiment dire que trop de choix tue le choix... et ce n'est pas prêt de s'arrêter, suffit de voir la petite guerre JEE / Spring (pour n'en citer qu'une)...

Citation:

---

Envoyé par OButterlin

C'est un problème récurrent... on peut vraiment dire que trop de choix tue le choix... et ce n'est pas prêt de s'arrêter, suffit de voir la petite guerre JEE / Spring (pour n'en citer qu'une)...

---

Je pense que cette citation s'applique plus à Javascript qu'a Java.
En Java c'est soit Java EE soit Spring. Il y a quelques autres framework pour les hipsters mais très peu utilisé par rapport au deux cités.
En JavaScript c'est AngularJS, Ember.js, Vue.js, React.js...
D'ailleurs il y a qu'à regarder comment AngularJS 1 s'est fait remplacer par la version 2.

Effectivement pour ma part, je laisse java de plus en plus de côté au profit du javascript (voire typescript), avec angularjs et nodejs.

D'abord les web services SOAP 1.2 ont achevés le java selon moi car tellement précis et rigoureux que les développeurs ont préférés se tourner vers JSON, plus permissif et évolutif.

Et puis le javascript c'est rapide, c'est léger, ca marche partout, alors pourquoi s'en priver !

Citation:

---

Envoyé par npuzin

D'abord les web services SOAP 1.2 ont achevés le java selon moi car tellement précis et rigoureux que les développeurs ont préférés se tourner vers JSON, plus permissif et évolutif.

---

Quel 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...

Citation:

---

Envoyé par npuzin

Et puis le javascript c'est rapide, c'est léger, ca marche partout, alors pourquoi s'en priver !

---

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.

Je pense Que J2EE est
un framework qui s'impose parce Qu'il permet de réaliser
énormément de choses Que nul n'ignore.

Citation:

---

Envoyé par OButterlin

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.

---

Comme plusieurs personnes ont dit avant moi dans cette discussion, la compatibilité du javascript est excellente dans tous les navigateurs relativement récents (IE9+, safari, chrome, firefox) de nos jours.

A part peut être dans les banques qui ont 10 ans de retard technologique, je pense que l'architecture de référence aujourdhui, c'est une application web single-page en javascript, et un back-end rest.

La génération de html côté serveur, honnêtement c'est old-school.

Pour n'en citer que deux, yahoo et google font tous les deux des SPA (et ma boite depuis 2 ans aussi)

Citation:

---

Envoyé par npuzin

A part peut être dans les banques qui ont 10 ans de retard technologique, je pense que l'architecture de référence aujourdhui, c'est une application web single-page en javascript, et un back-end rest.

---

A 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.

Citation:

---

Envoyé par tchize_

A la seule condition que tes pages web n'aient pas besoin d'être indexable par un moteur de recherche.

---

Pas d'accord. Google sait très bien indexer les SPA. J'en veux pour preuve le site d'angularjs par exemple, qui est une application Single Page (url https://docs.angularjs.org/#!/api ou https://docs.angularjs.org/api).

Citation:

---

Envoyé par tchize_

Aussi, les archi SPA, souvent, ne sont pas concues pour permettre une navigation multipage ("ouvrir dans un nouvel onglet")

---

Idem que précédement, tu vas sur le site d'angularjs, "ouvrir dans un nouvel onglet" marche très bien, de même que le bouton "back" du navigateur.

Citation:

---

Envoyé par tchize_

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

---

Honnêtement je demande a voir un JS de 3M... Faut pas oublier de minifier ses JS et surtout d'activer la compression GZIP au niveau du serveur web.

Citation:

---

Envoyé par npuzin

Comme plusieurs personnes ont dit avant moi dans cette discussion, la compatibilité du javascript est excellente dans tous les navigateurs relativement récents (IE9+, safari, chrome, firefox) de nos jours.

---

Bon, on ne va pas tourner en rond avec ton expérience... je te dis qu'on a fait l'acquisition d'une application JS qui ne fonctionne correctement qu'avec IE et Chrome... Si tu ne veux pas entendre l'argument (vérifié) que le JS n'est pas 100% compatible avec tous les navigateurs, ça te regarde... Et ce n'est pas un problème de navigateur obsolète, nous avons les toutes dernières version de Firefox.

Merci à tous pour votre participation.

Je vois que tout le monde a réussis à conserver un débat argumenté et ne virant pas au troll et je vous en félicite. Suite à vos interventions, j'ai plusieurs demandes de complément à vous demander.

Citation:

---

Envoyé par bilgetz

Il ne faut pas oublier non plus les sites qui ont besoin d'accessibilité, et Javascript et accessibilité ne font pas bon ménage.

---

Peux tu détailler ton propos ? En quoi l'accessibilité est limitée avec JavaScript ?

Citation:

---

Envoyé par OButterlin

Tu reconnais que l'interopérabilité entre navigateur n'est pas totale là...
Et bien si tu veux développer des applications quasi utilisables, c'est ton droit, je ne me vois pas dire à des clients : "Bah, faut changer votre navigateur, IE c'est de la daube, plus personne n'utilise ça"

---

Justement, n'as tu pas l'impression que la tendance s'inverse ces dernières années ? J'ai l'impression que par le passé la solution informatique était dictée par les contraintes de navigateur du client. Désormais, j'ai l'impression que la solution informatique dicte le navigateur à utiliser par le client. Comme s'il devenait plus acceptable de devoir imposer un navigateur à utiliser par le client au vu des besoins IHM. Ce n'est qu'une impression personnelle.

Citation:

---

Envoyé par verbose

La richesse de l'écosystème Java est aussi la source de son inconvénient, sa complexité fait fuir. Inversement, les technos autour de JS tombent pile dans les critères des startups : un langage plébiscité par des jeunes qui coûtent moins cher que leurs aînés, sans compter que JavaScript étant moins verbeux que Java, il nécessite moins d'heures de dev que JEE.

---

Quand je vois les framework JavaScript qui commencent à se multiplier, n'est ce pas également une source de complexité ? J'ai l'impression qu'un développeur Java voulant utiliser JavaScript ne va pas savoir vers quel framework se tourner.

Ensuite, j'ai quelque doute sur le fait qu'un langage verbeux nécessite plus d'heures de développement qu'un langage moins verbeux. D'où sors tu cela ? D'une expérience personnelle ou d'une quelconque source ?

Citation:

---

Envoyé par Cafeinoman

débat très intéressant, mais avec des postulats assez manichéen ...

---

Quels postulats trouves tu manichéens dans l'article ?

Citation:

---

Envoyé par _skip

Ce qui a fait le plus de mal à java au fond, c'est peut être pas la myriade de frameworks de qualité très variable, mais l'illusion du domain model tout objet, la surabstraction, les gâteaux à 7 couches et la surarchitecture en général. Je pense que la mentalité présente entre 2005-2010 dans le monde Java a donné les pires monstres architecturaux au détriment des solutions simples et que ça a énormément nuit à l'image de cette techno. Avis personnel qui n'engage que moi.

---

Quels sont les éléments qui te font penser que des approches basés sur des framework JavaScript ne souffrent ou souffriront pas des mêmes symptômes ? Quand je lis des témoignages de personnes mixant plusieurs frameworks JavaScript, n'est ce pas un signe que l'on complexifie également les solutions pour surachitecturer.

Citation:

---

Envoyé par tchize_

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.

---

Ne serait-on donc pas en train de dire que faire porter de plus en plus de chose par le client est finalement le symptôme de mauvaises pratiques de développement et d'architecture ?

Citation:

---

Envoyé par Robin56

Justement, n'as tu pas l'impression que la tendance s'inverse ces dernières années ? J'ai l'impression que par le passé la solution informatique était dictée par les contraintes de navigateur du client. Désormais, j'ai l'impression que la solution informatique dicte le navigateur à utiliser par le client. Comme s'il devenait plus acceptable de devoir imposer un navigateur à utiliser par le client au vu des besoins IHM. Ce n'est qu'une impression personnelle.

---

Si une application web a besoin d'un navigateur particulier, ce n'est plus une application web pour moi.
Je trouve totalement inacceptable de devoir imposer un navigateur pour une application web.

Ce qui s'améliore depuis quelque temps, c'est la compatibilité de javascript sur les différents navigateurs, c'est une très bonne chose... hélas, elle n'est pas encore totale pour le moment... mais ça avance.
Avec des outils comme JQuery qui rajoute une couche d'abstraction, il reste peu de problèmes (ou je ne les ai pas encore rencontrés).

Il n'y a pas que le javascript qui pose problème d'ailleurs, le CSS n'est pas interprété tout à fait de la même manière d'un navigateur à l'autre non plus :aie:

Citation:

---

Envoyé par Robin56

Quels sont les éléments qui te font penser que des approches basés sur des framework JavaScript ne souffrent ou souffriront pas des mêmes symptômes ? Quand je lis des témoignages de personnes mixant plusieurs frameworks JavaScript, n'est ce pas un signe que l'on complexifie également les solutions pour surachitecturer

---

Je vois pas où j'ai dit que le monde des frameworks javascript était sain. J'ai juste comparé des frameworks orientés composant à ceux plus orientés "requête" faut de leur trouver un meilleur nom.
Et pour la surarchitecture, il y a une grosse différence dans le sens où javascript se limite généralement au code client et à l'UI. On voit parfois un peu d'injection de dépendances mais en principe ça ne va pas beaucoup plus loin et heureusement. On est très loin des stacks Java qu'on pouvait rencontrer côté serveur à la JSF + Facelets + Spring + Spring security + hibernate en mode gateau à 6 couches il y a de ça quelques années. Dans aucun autre langage je n'ai vu des tutoriels de 17 pages pour créer une application hello world avec 2 vues. Il n'y a qu'en java qu'on avait cette manie de déconner avec des frameworks et de promouvoir ce mythe d'orientation objet absolue et d'indépendance totale entre les couches, ce qui était de toutes façons un pari perdu d'avance pour toute application non triviale.

Citation:

---

Envoyé par _skip

Dans aucun autre langage je n'ai vu des tutoriels de 17 pages pour créer une application hello world avec 2 vues.

---

Tout à fait d'accord avec toi concernant la sur-architecture qu'on a pu observer dans le monde java ces dernières années.

Citation:

---

Envoyé par _skip

Dans aucun autre langage je n'ai vu des tutoriels de 17 pages pour créer une application hello world avec 2 vues.

---

Faut pas déconner là quand même, Java n'a rien à voir avec des tutoriels mal fait ou trop compliqués ;)

Personnellement, je ne trouve pas les développements web côté serveur si compliqués que ça, la promotion du modèle MVC a dès le début été une bonne chose et la plupart des frameworks dignes de ce nom l'utilisent (struts, jsf pour ceux que je connais très bien).

Ensuite, dès qu'il y a accès à la DB, il y a des couches supplémentaires mais ça, on l'aura partout.

@OButterlin
Tu ne peux pas nier que faire du web en Java n'est pas simple du tout, ou alors, tu as oublié à force d'en faire tous les jours.
Heureusement, les architectures "légères" sont arrivées avec entre autre Spring Boot, Play framework, etc...

Citation:

---

Envoyé par OButterlin

Faut pas déconner là quand même, Java n'a rien à voir avec des tutoriels mal fait ou trop compliqués ;)

Personnellement, je ne trouve pas les développements web côté serveur si compliqués que ça, la promotion du modèle MVC a dès le début été une bonne chose et la plupart des frameworks dignes de ce nom l'utilisent (struts, jsf pour ceux que je connais très bien)..

---

Tu vas rire j'avais justement JSF 1 en tête en écrivant ce post. Tu te souviens? Son fichier de mapping XML à la con, son incapacité à faire de la composition de page sans avoir recours à des hacks ou à facelets (bravo pour un besoin aussi basique), les implémentations de taglibs qui partaient dans tous sens... Gérer les permissions sur les vues en intercalant un intercepteur dans le fameux cycle de rendu d'une complexité et d'une imprévisibilité telle que ça ramenait les gens à passer des heures sur le net pour se résigner entre folie et désespoir à finalement écrire de bons gros ServletFilters pourris rempli de cast juste pour vérifier un couple login / mot de passe dans une Session et rediriger en cas de problème?
Honnêtement, pour n'importe qui venant de Ror, PHP ou d'ASP.net et qui se frottait à du Java, c'était un truc de cosmonaute. Ca ne faisait absolument aucun sens. Et il faut que tu te dises (enfin je pense que tu as connu ça très bien) que les frameworks alternatifs n'avaient pas la visibilité du standard! Après avoir fait du wicket, puis du stripes, c'est finalement sur des trucs comme grails et play1 que j'ai repris plaisir à bosser sur du web en java. Je vais pas en plus te parler de ce qui gravitait autour comme solution entre JPA (intersection entre toplink et hibernate), EJB (démence) et Spring et ses XML qui était recommandé presque de facto pour la couche service. On est en 2008, imagine pendant 5 minutes la gueule d'un mec qui débarque à ce moment-là dans le monde web java et qui connaît pas la spécification Servlet, qui est pas familier avec les serveurs d'application... J'étais ce mec là, et de mon expérience, le développement web en java a été la chose la plus fouillie et difficilement accessible de toute ma carrière.

Pour être tout à fait honnête, je fais du web Java depuis l'an 2000, en commençant avec les servlets/JSP et JDBC.
J'avais jeté un oeil sur les EJBs à cette époque mais ça ne fonctionnait pas trop bien il faut le reconnaître... même avec VisualAge for Java qui générait à peut près tout, c'était vraiment chiant.
Je suis passé sur Struts 1 en 2006 avec Hibernate pour la couche DB.
En 2008 on s'est mis à utiliser les EJB3 et depuis, on tourne avec eux pour la couche métier.
JSF1, je ne l'ai pas connu, j'ai commencé avec JSF 1.2 et comme c'était avec Seam et Richfaces, il faut bien reconnaître que ça fonctionnait bien.
Maintenant, on tourne avec la pile JSF2 / Primefaces / EJB3 et ça fonctionne super bien et relativement simplement. Je dis "relativement" parce que Primefaces nécessite de se pencher un peu sur son API pour éviter les erreurs basiques, idem pour JSF2 d'ailleurs.
Si on cherche du "tout cuit" tout de suite, ce n'est pas évident, mais bon, mes collègues te diraient la même chose sur javascript qu'ils trouvent imbitable avec son absence de typage. Moi j'aime bien, je suis persuadé que si les éditeurs de navigateurs arrivent à se mettre d'accord sur une norme commune, ça aura du sens pour l'IHM.

Donc, en résumé, oui, j'ai un peu oublié la complexité de l'écosystème JEE, je ne peux pas prétendre comprendre un débutant "tombant" là-dedans :mouarf:.