Discussion :

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

[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 ?

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