Discussion :

[_skip]

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

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.

[VirgApps]

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.

[OButterlin]

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

[FaridM]

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.

[npuzin]

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 !

[OButterlin]

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

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.

[Felykanku]

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.

[npuzin]

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)

[tchize_]

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.

[npuzin]

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

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.

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.

[OButterlin]

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.

[Robin56]

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.

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 ?

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.

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 ?

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

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

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.

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 ?

[OButterlin]

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

[_skip]

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.

[npuzin]

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.

[OButterlin]

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.

[fr1man]

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

[_skip]

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.

[OButterlin]

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 .