Discussion :

[Hinault Romaric]

PayPal abandonne Java pour JavaScript
Node.js a permis un gain important en performance et en temps à l’entreprise

JavaScript est très critiqué par certains pour ses faiblesses. Pourtant, au fil du temps, le langage continue à jouir d’une grande popularité sur le Web.

PayPal, le service de paiement en ligne, a récemment abandonné le langage Java sur ses serveurs pour Node.js, avec un gain considérable dans le rendu des pages Web.

Jeffe Harrell, directeur de l’ingénierie chez PayPal, décrit dans un billet de blog, les avantages architecturaux de passer de Java à JavaScript. « Imaginez un développeur HTML qui doit demander à un développeur Java de lier la page A et B », explique Harrell.

Devant ce problème, PayPal devait avoir recourt des développeurs ayant des compétences différentes pour l’application Web et l’application serveur. « Chez PayPal, le bloqueur primaire a toujours été la limite artificielle que nous avons établie entre le navigateur et le serveur », explique celui-ci.

Pour surmonter cette situation, PayPal s’est tourné vers Node.js, qui a permis à la fois d’écrire les applications devant s’exécuter dans le navigateur et les applications serveurs en JavaScript. « Il [N.D.L.R : Node.js] unifie nos spécialités pour nous permettre de créer une équipe qui comprend et réagit rapidement aux besoins des utilisateurs à n’importe quel niveau dans la pile de technologie », justifie Jeffe Harrell.

PayPal a dans un premier temps commencé à utiliser Node.js comme plateforme de test avant de passer celui-ci en production cette année.

Avant d’adopter la plateforme de développement JavaScript événementiel, PayPal par mesure de prudence, à développer un équivalent en Java de son application Node.js. Pour l’application Node.js, il a fallu deux ingénieurs et pratiquement la moitié du temps utilisé par cinq personnes pour créer la déclinaison Java. L’application Node.js avait 33 % moins de lignes de code et 44 % moins de fichiers utilisés, que l’application Java.

Les tests de performances en production sur du matériel identique ont montré que l’application Node.js était de 35 % plus rapide que son équivalent Java. S’appuyant sur ces résultats, PayPal envisage de développer toutes ses applications Web orientées client avec Node.js. « Il y a une douzaine d’applications dont la migration a été amorcée », écrit Harrell.

Source : Paypal


Et vous ?

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

[Paul TOTH]

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

Je ne suis pas fan de Java, mais je pense surtout que l'équipe de développeurs JS de Paypal est plus réactive que l'équipe de développeurs Java, voir plus compétente et là ça fait un grosse différence.

D'autre part, JS a depuis quelques années était l'objet d'un gros travail d'optimisation part plusieurs acteurs, ce qui l'a propulsé vers le haut...Java n'a pas connu cette course à la performance pour autant que je sache. Google a d'ailleurs décidé de créer la machine virtuelle Dalvik pour Android jugeant que celle de Java n'était pas adaptée aux smartphones.

Ceci dit, je n'aime pas Java, mais je n'ai pas que de l'amour pour JS, son modèle objet est des plus casse pied.

[LSMetag]

Qu'en pensez-vous ? JavaScript avec Node.js est-il une meilleure solution pour les services Web que Java ?

Je n'ai jamais utilisé NodeJS (je ne suis d'ailleurs pas du tout fan de JS), mais j'ai bien constaté que JS était vraiment très performant et léger. J'ai au contraire constaté l'aspect poussif de Java (peut-être OpenJDK est-il meilleur ?), pas simplement niveau développement, exécution et maintenabilité, mais également côté installations serveur. Sans oublier le manque de réactivité d'Oracle niveau support, contrairement à l'époque où Java était chez Sun...

Et bien sûr, il y a la question des coûts. Javascript et NodeJS sont totalement gratuits.

Donc bonne initiative de Paypal. Par contre, Oracle devrait commencer à se poser des questions... Si des grands comptes se mettent à abandonner Java, c'est qu'il y a un pb...

[_skip]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :

Je n'ai jamais utilisé NodeJS (je ne suis d'ailleurs pas du tout fan de JS), mais j'ai bien constaté que JS était vraiment très performant et léger. J'ai au contraire constaté l'aspect poussif de Java (peut-être OpenJDK est-il meilleur ?), pas simplement niveau développement, exécution et maintenabilité, mais également côté installations serveur. Sans oublier le manque de réactivité d'Oracle niveau support, contrairement à l'époque où Java était chez Sun...

Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.

Et bien sûr, il y a la question des coûts. Javascript et NodeJS sont totalement gratuits.

Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

[Washmid]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :



Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.



Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

+1000

Comparer un framework (node.js) à un language (java) c'est sans grande signification.

Et le côté statique permet de faire des choses aussi basiques qu'indispensables comme autoriser le factoring, la navigation dans le code, etc. etc.

[Voyvode]

Double the requests per second vs. the Java application. […] our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.

Entre les lignes : notre code Java était pourri.

There’s a disclaimer attached to this data: this is with our frameworks and two of our applications.

[Edit]
http://benchmarksgame.alioth.debian....=java&data=u64
Java a une performance brute clairement supérieure à JavaScript (et un code source effectivement plus lourd).

PayPal obtient de meilleurs performances avec Node.js parce que :

1. leur code Java était, au mieux, mal adapté ;
2. ils se sont retroussés les manches avec Node.js ;
3. ils veulent faire du buzz trollesque.

[fr1man]

Je rejoins tout à fait _skip.
J'adore ces superbes analyses avec de beaux graphiques pour prouver qu'on a raison, alors qu'on ne sait rien sur la façon dont tout a été développé.

[Saverok]

Mettons face à face un 4x4 baroudeur et une micro citadine
Je vais en en montagne en traversant des chemins de terre tout pourris
j'arrive 5x plus vite à ma destination avec le 4x4
Conclusion : le 4x4 est meilleur et je vais équiper toute la flotte de mon entreprise avec des 4x4!!

[koyosama]

Je vois les tests de performances mais pas les tests de sécurité. J'ai envie dire que la vitesse voilà, elle me semble secondaire comparé à la sécurité.

[Markand]

Personnellement je pense que les graphismes ont du sens.

1. Node.js est un framework javascript extrêmement simple. De base, il fournit qu'une API JavaScript pour coder une application rapidement. On a aucun système de template, de session, d'ORM de base. Ça peut justifier un gain en rapidité.

2. Node.js est codé en C++. Bien que Java soit aussi un langage compilé, le C++ reste plus performant dans certains domaines.

3. Pour avoir travaillé dans une entreprise où on faisait du développement Java. Je peux assurer que ce n'est pas que le code qui fait la rapidité. Pour installer une application web java il faut un conteneur (Tomcat, Glassfish, JBoss, etc.) Ces derniers rajoutent une couche d'exécution supplémentaire ce qui ralentit encore une fois l'application. De plus, la plupart des applications web java inclue des gros framework nécessitant pas mal de ressources (JSF, Primefaces, Hibernate (ou JPA), Spring, etc).

Mais effectivement, il aurait été intéressant de savoir plus en détails ce qui était utilisé côté Java chez PayPal.

[FelipeVervena]

La majorité des pages de Paypal sont servies en CGI : autant utiliser C++ ou C pour une performance maximale plutôt que JS ou Java. Il serait temps de revenir aux sources encore faut-il trouver les compétences.

[beekeep]

La majorité des pages de Paypal sont servies en CGI : autant utiliser C++ ou C pour une performance maximale plutôt que JS ou Java. Il serait temps de revenir aux sources encore faut-il trouver les compétences.

oui mais la tu explose le temps de dev, il faut trouver un bon compromis.

[SylvainPV]

Autant j'adore Node.js et j'ai un projet node en prod sur un VPS qui tourne comme une horloge depuis des mois, autant ça m'effraie de voir qu'un site comme Paypal opte pour un environnement serveur qui n'a pas atteint la sacro-sainte version 1.0.

[michel.bosseaux]

Peut-être faudrait-il, sans parler des compétences comparées des devs Java et Javascript de Paypal, se demander s'il ne faut pas + de compétences pour prendre en main Java (et toutes ses librairies et frameworks) que Javascript, et que même comme cela, ce qui n'empêcherait quand même pas le développement Java de rester plus lent, plus délicat.

Mais c'est vrai que sans + de détails de la part de Paypal, c'est dur de trancher. On sait seulement que 2 personnes ont fait le travail de 5 en moitié moins de temps, soit si je calcule bien une productivité multipliée par 5 par personne. Ca ne peut pas être seulement dû aux compétences, les développeurs Java de Paypal sont là depuis des années, ils connaissent leur boulot à force... donc ou bien Javascript / Node.js est vraiment plus simple pour développer un projet (possible, mais p-e pas avec un tel facteur), ou bien toutes les fonctionnalités n'y sont pas (que ce soit celles visibles pour l'utilisateur, ou comme mentionné dans un des commentaires précédents, au niveau de la sécurité).

[la.lune]

Ce que j'aime juste souligner ici avant de dire ce que je pense, c'est que je me demande quand est ce que les gens vont oublier l'idée que java est lent en exécution?

Et comme _skip l'a mentionné le java d'aujourdui n'est pas le java des années 90, le moment où on a voulu créer le concept d’écrire une seule fois et exécuter partout utilisant les machines virtuelles.

Java a pourtant des performances à l’échelle de C/C++. A titre d'info, il faut savoir que ce n'est pas un bon matin que Facebook a décidé de compiler son code php en C++, puis en binaire, mais c'est après des analyses qui sont bien faites sur tous les autres langages.

Je vous invite à lire la présentation "Facebook architecture de 600 millions d'utilisateur", ici, sur la 24e slide, ils ont présenté les résultats des performances entre les langages comme illustre cette image:



Au lieu d'utiliser java qui dépasse de très loin php en performance, ils ont choisit de profiter du petit gain que C++ en a au dessus de java.

Comme vous voyez java est très performant devant ces concurrents sur le web excepté relativement JavaScript qui n'est pas sur la graphe .

J'ai vu un exemple avec de petit portion de code que vous pouvez même tester par ici, un même code qui s’exécute 1 minute 16 secondes en python, et 1 minute 9 secondes en php, et 41 seconde en Perl, s’exécute en seulement 18 seconde en java.

Mais il ne faut pas penser que c'est le seul côté que java gagne en performance, sur script à longue durée, mais c'est plutôt en trafic et en activités que les ingénieurs qui ont conçu Java EE ont fait le grand boulot. Ça ne va pas s'observer en exécuter une requête ou deux, mais quand vous allez exécuter des milliers de requêtes à la fois.

Une seule servlet(java) vivant répond à un millier de requête à la fois, le moment où par exemple php créer un nouveau programme pour chaque requête, étant donné qu'il est basé sur le modèle CGI(Common Gateway Interface). C'est pour cela que beaucoup sites à fort trafic choisissent java vu sa robustesse.

Pour ce qui est Java vs JavaScript côté serveur, d'abord c'est que personne ne peut nier les performance de node et sa légèreté qui sont aussi relatives.

J'aime bien Node.js sur le fait que tu crée ton propre serveur et tu choisit les modules à charger et tu peux choisir les objets que tu veut garder en mémoire tout long de la vie du serveur, car ce qui fait la force d'une plateforme web c'est composants serveurs vivant ou mort sous la décision du développer.

Alors en Java EE, ils ont voulus standardiser les choses et ne pas obliger le développeur à créer ses propres serveurs, mais créer juste les composants et paramétrer leurs cycle de vie.

Ainsi, ce qui fait ce ce n'est pas nous même qui gèrent nos composants mais c'est le serveur(midlware), lui aussi qui s’exécute sur la machine virtuelle java, donc quelques milliseconde en retard et quelques charges en mémoire qui font que JavaScript lui dépasse.

Mais a mon avis, vu que java c'est du compilé contrairement à JavaScript, si on pourrait développer avec comme on développe avec Node.js, mais avec une bonne architecture, java dépasserait bien JavaScript.

Mais tout reste que côté architecture et bonne structure des applications, java ne se compare pas à JavaScript, et Java EE ne se compare pas à Node.js. De même que les framwork et les outils de développement, test, débogage, intégration continue.... Tout cela, doit être pris en compte et là je rejoint ce que _skip a mentionné.

[xulien]

Au delà de la vitesse d’exécution, je pense que le gain de performance observé viens surtout de la nature évènementiel et asynchrone de node

[LSMetag]

Je veux pas recommencer un énième troll java vs reste du monde mais tout de même :



Euh non je pense pas que ce genre de critique se vérifie complètement, les performances de java sont carrément bonnes à l'heure actuelle. On est plus dans les années 90. Et niveau maintenabilité il y a l'avantage amené par l'aspect statique du typage et la compilation, à qualité de code égale, je préfère 100 fois maintenir une app d'un million de lignes en java qu'en javascript.



Faire du java cela coûte quoi? Autant les outils que les frameworks sont gratuits et largement aboutis.

Pour en revenir à l'article, je pense que c'est un peu chaud de tirer des conclusions JS > java ou Java > js. Cela dépend aussi de l'équipe et des stacks qui ont été employées. Si côté java ils ont utilisé du JSF + EJB ou d'autres standards du même style, je veux bien croire qu'ils devaient être plus nombreux pour faire moins. Ca aurait été plus intéressant si on avait su exactement ce qui était comparé ici. Car "java" tout seul pour une application web ça ne nous dit pas grand chose, y'a une infinité de possibilité qui peuvent donner des résultats très variables. Ca peut être des des pommes, des poires, des choux et des patates...

Je sais que Java et ses frameworks sont bien pour de très grosses applis, devant gérer beaucoup d'accès concurrentiels. La communauté est très importante aussi. Le langage en lui même est très fonctionnel et beaucoup de créations de la communauté sont disponibles gratuitement.

Alors oui il aurait été bien d'avoir plus de détails sur comment avait été développé Paypal.

Chaque fois que j'ai utilisé Java, il fallait toujours rajouter un serveur d'applications bien lourd, style JBoss, WebsPhere,... La grosse usine à gaz.
J'ai utilisé Eclipse (Juno, même Kepler). Ok c'est bourré de fonctionnalités, mais ça rame quand même pas mal. Par contre, j'ai apprécié IntelliJ de JetBrain, mais peu utilisé en entreprise.

Tous les projets sur lesquels j'ai dû bosser, il fallait payer. Pour le support d'Oracle, pour le serveur d'applications WebSphere avec Portal et WCM (et même pour un Eclipse modifié par IBM). Ces trucs étaient tellement lourds qu'il était impossible de les installer sur nos machines en local. D'ailleurs ils n'ont acheté qu'une licence tellement c'était cher, nous privant de la possibilité de debugguer (un seul serveur pour tout le monde). Et les utilisateurs en étaient mécontents.

Je préfère Java question développement, mais je sens toujours une lourdeur, même sur des applications simples. Au contraire, Javascript, on est toujours dans l'"instantané" quand on le voit à l'oeuvre.

Je ne vois pas l'intérêt de Java/J2EE si le projet n'est pas énorme, avec de très gros besoins (IOC, AOP, internationalisation, une tonne d'utilisateurs en simultané, Log4J, 10 projets,...).
Ces fameux graphiques ont quand même été faits en comparant 5 coeurs avec Java à un seul coeur avec JS. Alors oui peut-être que ça avait été programmé avec les pieds.

Il est idiot de dire JS>Java et vice versa je suis d'accord.

Mais je suis assez surpris qu'un gros compte décide de refondre toute son infrastructure Java (qui a dû coûter bonbon en matos et ingénieurs et qui a fait des années) avec une techno bien différente, qui n'est pas encore mature.

[Firwen]

Au delà de la vitesse d’exécution, je pense que le gain de performance observé viens surtout de la nature évènementiel et asynchrone de node

Exactement.

Je suis trés trés loin d'être un Java boy, mais il faut reconnaitre que Java a de trés bonne performances en terme d'executions. Généralement supérieur à celles des moteurs JavaScript les plus évolués comme V8 ( http://benchmarksgame.alioth.debian....g=all&data=u32 ).
Les problèmes de performances de Java viennent généralement bien plus de la gestion mémoire par GC que de l'execution elle-même, problème qui touche Javascript également.

Le gros avantage de NodeJS en terme de performance vient de son système d'I/O asynchrones qui scale nettement mieux que le classic design "synchronous blocking I/O per thread" utilisé généralement en Java.

[Traroth2]

Je pense que la différence de performance s'explique bien plus par l'architecture et les principes de fonctionnement que par l'utilisation de tel ou tel langage, dans ce cas précis.

Les serveurs web Java EE, dits aussi conteneurs de servlets, comme Tomcat, par exemple, traitent chaque requête avec un thread séparé, ce qui n'est pas réellement utile. Cette architecture massivement multithreadé consomme inutilement des ressources : changement de contexte, ouverture d'une connexion sur le serveur pour chaque requête, augmentation du heap de la JVM pour tous ces threads, etc.

Node.js et Vert.x (son équivalent Java, que je connais mieux, personnellement) sont conçus de manière radicalement différente : on a un thread d'écoute qui lit les requêtes à partir d'une file d'attente et les traite l'une après l'autre. Ce thread lance ensuite des threads de travail qui vont effectuer le traitement proprement dit. On a donc nettement moins de connexions ouvertes simultanément (puisqu'on les ouvre seulement quand on en a effectivement besoin de transférer des données) et moins de threads simultanés, d'où moins de consommation mémoire et moins de changements de contexte pour le processeur.

[Mr_Exal]

Entre les lignes : notre code Java était pourri.




[Edit]
http://benchmarksgame.alioth.debian....=java&data=u64
Java a une performance brute clairement supérieure à JavaScript (et un code source effectivement plus lourd).

PayPal obtient de meilleurs performances avec Node.js parce que :

1. leur code Java était, au mieux, mal adapté ;
2. ils se sont retroussés les manches avec Node.js ;
3. ils veulent faire du buzz trollesque.

Tout est dit. Leur code java devait vraiment être merdique niveau optimisation ...