Discussion :

[zecreator]

Bonjour,

Je me pose la question : Pourquoi déployer une grosse machinerie J2EE côté serveur pour une application web qui pourrait fonctionner sous NodeJS et qui permettrait l'utilisation d'un seul langage des 2 côtés (client et serveur) ?

Y a t-il des choses que le J2EE peut faire que NodeJS ne fait pas ?

Je ne prends partie pour aucune des 2 technologies, c'est pour avoir vos arguments pour mon orientation.

Merci.

[Marco46]

Si tu as des traitements à effectuer (conso CPU) il vaut mieux développer ça avec Java ou C#.
Si tu as beaucoup de requêtes dont la payload va trigger directement une I/O (BDD, autre WS, filesystem, ...) sans effectuer de traitement il vaut mieux utiliser Node.js.

Il n'y a pas de parti à prendre sur une techno ou une autre parce qu'elles ne répondent pas au même besoin. Node.js sert à traiter un grand nombre de requêtes qui vont chacune consommer extrêmement peu de CPU. Si tu fais du calcul côté Node ça effondre les perfs du serveur (blocage de l'event loop). Ça a été conçu spécifiquement pour traiter cette problématique.

C'est aussi beaucoup plus léger et beaucoup plus rapide à démarrer.

En résumé ça scale mieux, c'est moins cher à exploiter mais c'est pas fait pour faire du calcul.

[zecreator]

Si tu as des traitements à effectuer (conso CPU) il vaut mieux développer ça avec Java ou C#...

Oui, le Java/J2EE a une image assez austère par rapport au NodeJS. On sent bien que J2EE n'est pas principalement utilisé pour des sites d'entertainement, mais plutôt pour le traitement de Big Data.

Du coup, le Java est le premier langage en demande sur le marché. Quels secteurs d'activité qui sont en demandent de J2EE plutôt que toutes autres technologies pour du web ?

PS : Je parles de J2EE, pas du J2SE ou du Java embarqué dans du hardware.

[Marco46]

La plupart des grands comptes ont leurs backends en J2EE pour des raisons historiques.

Ils sont aussi frileux sur les nouvelles technos et ont une veille techno dégueulasse puisqu'ils utilisent des prestataires en masse. Ils ont peu de profils techniques en interne. On entend encore des conneries du style Node n'est pas une techno assez mature pour être utilisée en prod (alors que tout le fortune 500 l'utilise mais c'est pas grave ). J'ai même entendu des conneries du style Git est une techno pas assez mature on préfère SVN

En revanche les startups et les boites nouvelles technos, disons en gros la "french tech" sont très friandes de nouvelles technos. Il y a vraiment beaucoup de demande sur Node.js dans ces boites.

Le big data est aussi très utilisé avec Node. Je pense à la stack Mongo / Node ou même Elastic Search / Node. Tout dépend de ce que tu as à effectuer comme traitement avant de pousser les données dans ta persistance. Si tu as beaucoup de requêtes et peu de traitements à effectuer avant de les pousser dans ta persistance Node.js est bien plus efficace.

Côté frontend les SPA avec Angular / React / Vue raflent tout. Les grands comptes ont aussi investi là dessus depuis quelques années d'abord sur AngularJS. Désormais une partie réécrit les front sur Angular et une autre partie assez significative migre vers Vue.js. Il ya une grosse demande sur React dans les startups.

Cet engouement des SPA ajoute un intérêt supplémentaire à l'usage de Node quand il est possible, ça uniformise le langage utilisé. Les organisations qui prennent des devs fullstack et qui ont une stack basée sur J2EE ou .NET vont souvent privilégier Angular pour avoir du TypeScript directement dans la webapp. C'est beaucoup moins clair quand les équipes sont séparées front / back. Mais pour palier à ça Vue 3 aura un support de TypeScript très amélioré.

[gangsoleil]

Hello,

Je vais essayer de répondre à ta question bien que je ne connaisse pas bien les frameworks JS -- j'ai principalement travaillé sur des backends en C, avec des apps J2EE en front

Comme l'a bien dit Marco46, il y a déjà un problème d'historique : lorsque tu as un logiciel en J2EE d'un million de lignes, qui fonctionne plutôt bien, tu n'as pas forcément envie d'investir pour le ré-écrire en JS.

Ensuite, il y a le problème de l'évolution des frameworks JS (rappel : je connais moins cette partie, il est possible que je raconte des boulettes, mais elles mettent probablement en avant une réalité) : il y a 5 ans, backbone (et consors) était LE truc à utiliser. Aujourd'hui, c'est REACT. Alors je sais qu'il est toujours possible de passer de l'un à l'autre, mais pour un grand compte, ou pour des secteurs pas très évolutifs (backend des banques, des assurances), c'est trop rapide (n'oublions pas qu'il reste des backends écrits en Cobol, d'autres en C qui font tourner du code qui a plus de 25 ans).

Enfin, il y a des problèmes de performance -- peut-être de perception de performance. Prenons un cas réel : un module quelconque, qui doit traiter quelques millions de transactions en 12h. Gagner ou perdre 1 milliseconde par traitement, ça semble dérisoire, mais c'est 1h par jour de gagné ou de perdu (1ms * 3 600 000transactions = 3 600 secondes de traitement = 1h). Si ton traitement dure 1h, tu te fous de cette heure, si ton traitement dure 11h, c'est critique.

Changer ce backend pour le ré-écrire avec des technologies modernes (js, bases noSQL, ...) permettrait peut-être de diviser le temps de traitement par 2, mais à quel prix ?

Voilà, pour moi, les technologies dont tu parles sont, dans ces domaines, bien pour les front, mais trop coûteux pour les backends. Par contre, pour les entreprises avec moins d'historique, c'est une bonne piste.

[Marco46]

Enfin, il y a des problèmes de performance -- peut-être de perception de performance. Prenons un cas réel : un module quelconque, qui doit traiter quelques millions de transactions en 12h. Gagner ou perdre 1 milliseconde par traitement, ça semble dérisoire, mais c'est 1h par jour de gagné ou de perdu (1ms * 3 600 000transactions = 3 600 secondes de traitement = 1h). Si ton traitement dure 1h, tu te fous de cette heure, si ton traitement dure 11h, c'est critique.

Voilà, pour moi, les technologies dont tu parles sont, dans ces domaines, bien pour les front, mais trop coûteux pour les backends.

C'est surtout que c'est pas fait pour ça. Node.js n'est pas fait pour effectuer des traitements, il est fait pour avaler / cracher un très grand nombre de requêtes par seconde.

Si ton traitement c'est prendre un POST / PUT et le mettre presque tel quel dans une DB, ou tirer une requête avec un GET sans trop de transformation, alors Node.js est hyper performant. Si tu dois calculer plein de trucs c'est juste pas fait pour ça.

il y a 5 ans, backbone (et consors) était LE truc à utiliser. Aujourd'hui, c'est REACT.

Backbone c'était il y a 10 ans. Il y a 6 ans jusqu'à il y a 2 ans c'était AngularJS / Ember.

Depuis 2 ans c'est Angular / Vue / React.

[gangsoleil]

Backbone c'était il y a 10 ans. Il y a 6 ans jusqu'à il y a 2 ans c'était AngularJS / Ember.

Depuis 2 ans c'est Angular / Vue / React.

Merci pour cette correction -- je l'avais bien dit que je me planterai là dessus

Là où je ne me suis pas planté, c'est que dans certains domaines, c'est trop rapide : le backend sur lequel je travaille a des bouts de code qui ont plus de 25 ans, donc il est difficile de concilier ça avec une techno qui sera dépassée en 5 ans. Attention, je ne dis pas que l'un est mieux que l'autre, simplement que ce sont 2 mondes qui ne peuvent pas s'entendre -- mais ils peuvent cohabiter sans soucis.

[el_slapper]

J'ai refondu, en 2008, dans une assurance, du code comptable qui datait de 1972. On est restés en COBOL pour rester compatibles avec le reste du SI. Le montant de mon assurance auto est toujours calculé par ce code, en 2019. C'est le rythme des grands comptes. Fatalement que chez eux, J2EE, c'est encore tout neuf.

[zecreator]

Du coup, si je veux espérer avoir un poste durable et sécurisé au sein d'une société grand compte, je devrais choisir quoi ? Node JS ou J2EE ?

[Marco46]

J2EE sans hésitation. Et c'est un JavaScript fanboy qui te dit ça

[gangsoleil]

Du coup, si je veux espérer avoir un poste durable et sécurisé au sein d'une société grand compte, je devrais choisir quoi ? Node JS ou J2EE ?

J2EE, définitivement. Regarde le commentaire d'el_slapper, il est on-ne-peut plus vrai.

[kbadache]

Pour info, aujourd'hui on parle de Java EE ou même Jakarte EE et non plus J2EE.

L'intérêt de ce framework est d'avoir le maximum d'outils pour faire tourner une application comme la sécurité, les transactions, les pools de connexions au bases de données...

C'est vrai que ça reste quand même lourd, c'est pourquoi aujourd'hui très peu en font et utilise plutôt Spring Framework.
D'autant plus qu'avec Spring Boot, il est aujourd'hui possible de développé très très vite une application tout en ayant les mêmes fonctionnalités que Jakarta EE (voir plus comme l'AOP, une énorme facilité de tests...).
L'avantage aussi c'est qu'on bénéficie de l'écosystème de java.
Je connais pas très bien nodejs, mais je suis pas sûr qu'il offre autant d'outils.
Je travaille aussi avec des applis en js et le nombre de fichiers de conf est comparable à ce qu'il y avait en java il y a 10 ans (webpack.config(dev|prod).js, karma.conf.js...).
Je n'ai jamais eu à écrire un fichier de conf pour faire tourner Junit...

Je pense aujourd'hui que même pour une petite appli, Spring Boot permet d'aller plus vite au résultat final.

[Marco46]

L'avantage aussi c'est qu'on bénéficie de l'écosystème de java.
Je connais pas très bien nodejs, mais je suis pas sûr qu'il offre autant d'outils.

L'écosystème JS est beaucoup beaucoup beaucoup plus vaste et riche que l'écosystème Java, de plusieurs ordres de grandeurs ça soutient pas la comparaison.

Je travaille aussi avec des applis en js et le nombre de fichiers de conf est comparable à ce qu'il y avait en java il y a 10 ans (webpack.config(dev|prod).js, karma.conf.js...).
Je n'ai jamais eu à écrire un fichier de conf pour faire tourner Junit...

Il n'y a pas besoin de fichier de conf pour exécuter des TU en JS non plus. Karma sert à exécuter dans le browser pour avoir l'API DOM dispo ou exécuter des tests e2e et c'est assez largement obsolète (et c'est même pas un framework de test c'est juste un runner). Webpack sert à générer un livrable ça n'a aucun rapport.

[kbadache]

L'écosystème JS est beaucoup beaucoup beaucoup plus vaste et riche que l'écosystème Java, de plusieurs ordres de grandeurs ça soutient pas la comparaison.

Il n'y a pas besoin de fichier de conf pour exécuter des TU en JS non plus. Karma sert à exécuter dans le browser pour avoir l'API DOM dispo ou exécuter des tests e2e et c'est assez largement obsolète (et c'est même pas un framework de test c'est juste un runner). Webpack sert à générer un livrable ça n'a aucun rapport.

Ah? en quoi l'écosystème js est beaucoup, beaucoup plus vaste et riche?
Du multithreading?
Gestion des transactions?
Messaging queue?
Batch?
Job scheduler?
Comment tu testes tes requêtes en bdd?
Equivalent de Kafka? Elastic search?
Gestion des logs (ELK)?
Gestion de l'authentification et des autorisations?

Et bien sûr je parle de chose mature, pas de framework utilisé par 50 personnes dans le monde.

Ok, ne testons pas le web.
Pour nodejs : https://jasmine.github.io/setup/nodejs.html il y a bien un peu de conf.

En quoi webpack n'a aucun rapport? Donc tu ne génère pas de livrable? Tu livre ton projet tel quel? Pas de minification?

Bref, le but c'est pas de dire que js/java c'est bien/pas bien.
Ca n'est pas utilisé pour la même chose, par contre aujourd'hui, c'est pas du tout déconnant d'utiliser java même pour un petit projet.

[Marco46]

Ah? en quoi l'écosystème js est beaucoup, beaucoup plus vaste et riche?

Ben en nombre de packages dispo sur le registre déjà. 3 fois plus en JS et croissance bien plus importante.

En projets sur GitHub.

C'est déjà pas mal, et ya quand même pas photo.

Du multithreading?

Effectivement tu ne connais pas grand chose à Node. Difficile de discuter dans ces conditions. L'event loop ça te parle ?

Gestion des transactions?

Ça n'a aucun rapport avec le langage c'est le propre d'une base de données d'être ACID ou pas. Si tu parles d'outil de type Hibernate il y a des équivalents en JS comme Sequelize qui sont très utilisés et qui évidemment supportent les transactions.

Messaging queue?

Pareil c'est pas propre au langage c'est du tooling autour. Ya des clients pour redis, RabbitMQ, etc ... Comme dans les langages les plus utilisés.

Batch?

Pareil.

Job scheduler?

Pareil.

Comment tu testes tes requêtes en bdd?

Je ne sais pas de quoi tu veux parler exactement, peut être de tests d'intégration ? Ben comme dans n'importe quel langage.

Equivalent de Kafka? Elastic search?

Là aussi c'est du tooling. C'est outils ne sont pas exclusivement utilisables avec Java. C'est pas parce que Elastic est dev en Java qu'il faut faire un projet Java pour l'utiliser.

Gestion des logs (ELK)?

Pareil.

Gestion de l'authentification et des autorisations?

Pareil.

Et bien sûr je parle de chose mature, pas de framework utilisé par 50 personnes dans le monde.

Ben ouai c'est vrai que Node n'est pas mature. C'est juste utilisé par la totalité du fortune 500, Netflix a basardé sa stack J2EE pour Node avec des résultats hallucinants, Paypal gère plusieurs milliards d'euros de transaction chaque jour exclusivement avec du Node mais c'est pas mature et ils utilisent aucun tooling, c'est juste des oufs les mecs.

Ok, ne testons pas le web.

Jamais dit une chose pareille.

Pour nodejs : https://jasmine.github.io/setup/nodejs.html il y a bien un peu de conf.

Je sais pas qui utilise Jasmine avec du Node mais ça doit vraiment pas courir les rues. C'est pas du tout la lib la plus utilisée pour. Regarde plutôt du côté de Mocha ou de AVA.

Mais comme tu connais mal l'écosystème JS, tu le dis toi-même ça ne m'étonne pas ...

En quoi webpack n'a aucun rapport? Donc tu ne génère pas de livrable? Tu livre ton projet tel quel? Pas de minification?

On parlait pas des tests ? Webpack n'a pas de rapport avec les tests.

Bref, le but c'est pas de dire que js/java c'est bien/pas bien.

C'est pourtant ce que tu essaies maladroitement de faire non ? Du coup je réponds.

Ca n'est pas utilisé pour la même chose, par contre aujourd'hui, c'est pas du tout déconnant d'utiliser java même pour un petit projet.

J'ai jamais dit le contraire, j'ai même conseillé sur ce fil de discussion à un dev qui veut sécuriser sa carrière dans un grand compte français de s'orienter vers du Java

Comparer le JS actuel avec le Java d'il y a 10 ans alors que c'est Java qui est à la bourre par rapport à JS pour faire du web c'est quand même hallucinant. Alors on est en France, on a toujours plusieurs années de bourre (d'où mon conseil d'aller vers J2EE en France surtout compte tenu de l'historique des SI) mais sache que ce n'est pas du tout la même tisane là où les tendances se créent c'est à dire aux USA. Le développement web s'oriente nettement vers du full JavaScript et c'est pas près de s'arrêter.

Mais en France oui effectivement c'est pas déconnant de faire du Java.

[zecreator]

Sinon, que pensez-vous de ActionScript et Flash ? Doit y avoir encore pas mal d'opportunités avec ces langages, non ?

OK, je déconne... c'était pour détendre l'atmosphère.

Bon, au final, je me lance un petit projet perso de LMS en Angular + J2EE (pardon Java EE). Je vais me faire la main sur les outils autour de ces 2 technos.
Merci pour toutes vos infos et conseils.

[deltree]

Sinon, que pensez-vous de ActionScript et Flash ? Doit y avoir encore pas mal d'opportunités avec ces langages, non ?

OK, je déconne... c'était pour détendre l'atmosphère.

Bon, au final, je me lance un petit projet perso de LMS en Angular + J2EE (pardon Java EE). Je vais me faire la main sur les outils autour de ces 2 technos.
Merci pour toutes vos infos et conseils.

La vache tu m'a fait peur, je commençait déjà à sortir mon clavier à trolls

Oui ton choix est très bon au niveau pro. Tu peux aussi voir Spring boot, qui permet quasi la même chose que JEE (un concurent en somme) et qui n'a pas été évoqué dans le thread.

(edit flash/actionscript je l'ai remplacé par angular chez un client qui ne voyait pas le problème à garder du flash, d'ou mon éruption cutanée)

[zecreator]

flash/actionscript je l'ai remplacé par angular chez un client qui ne voyait pas le problème à garder du flash, d'ou mon éruption cutanée)

Claire. Ravi d'avoir viré ce malware, heu, cette techno.