Discussion :

[fredoche]

M'enfin si j'ai bien lu il n'y a rien en prod pour l'instant, juste des migrations amorcées.

Tu n'as pas bien lu

Our first adopter of node.js in production wasn’t a minor application; it was our account overview page and one of the most trafficked apps on the website

Paypal est dans le business depuis plus de 10 ans et c'est une des boites qui doit gérer le plus de transactions au monde.
S'il y a un truc qui balbutie peu, c'est plutôt l'informatique bancaire. Genre si c'est pas de ce métier qu'est né l'informatique, chez ceux qui ont toujours eu besoin de compter.

Et il y a des mecs ici qui s'imaginent que l'explication à ce choix technologique est un manque d'optimisation coté java :

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

j'imagine que c'est de l'humour ?

Imikado, tu crois vraiment que paypal n'audite pas ses applications ?

Si vous avez bien lu l'article, la motivation essentielle mise en avant à ce changement est de faire tomber la barrière (la frontière) qui existe entre développement front-end et back-end, et javascript est un langage qui concerne ces 2 cotés du développement.

Les performances ne sont ensuite qu'un constat, et il est dit ici que pour le coup on compare bien des "pommes avec des pommes", les 2 développements JS et Java ayant été fait en parallèle, sur le même cahier des charges. Le développement Java est prêt à être substitué à celui sur node.js en cas de besoin.

[smaila]

J'ai une fois postée sur LinkedIn la question a un développeur sur laquelle des technologies est tendance aujourd'hui et permet d'avoir des retombées financières acceptable. Cette personne m'a dit de me concentrer sur javascript car il y a peu de développeur javascript et plus de demande dans cette technologie a cause de justement de la performance des applications écrites en ajax et ces variantes. Bien que je sois très attiré par java, je crains fort javascript ne vole la vedette a java comme cela a pu bien été le cas à PAYPAL. Donc un conseil qui vaut pour moi meme, meme si nous sommes attirés pour une raison ou une autre par d'autres technologies autres que javascript il serait sage d'avoir javascript en particulier node.js sous la manche et sur nos CV

[LSMetag]

J'ai une fois postée sur LinkedIn la question a un développeur sur laquelle des technologies est tendance aujourd'hui et permet d'avoir des retombées financières acceptable. Cette personne m'a dit de me concentrer sur javascript car il y a peu de développeur javascript et plus de demande dans cette technologie a cause de justement de la performance des applications écrites en ajax et ces variantes. Bien que je sois très attiré par java, je crains fort javascript ne vole la vedette a java comme cela a pu bien été le cas à PAYPAL. Donc un conseil qui vaut pour moi meme, meme si nous sommes attirés pour une raison ou une autre par d'autres technologies autres que javascript il serait sage d'avoir javascript en particulier node.js sous la manche et sur nos CV

Je suis d'accord avec ce développeur. Je rajouterais qu'il en va de même pour .NET. Javascript est très tendance avec son modèle asynchrone et ses Frameworks, a une demande augmentant fortement depuis quelques années, permettant d'effectuer des développements portables, réactifs.
.NET est au niveau de J2EE et tout autant recherché en entreprises, mais les compétences sont beaucoup plus rares puisqu'à l'école on enseigne très peu .NET, au contraire de J2EE.

Donc oui c'est une bonne stratégie, qui marche très bien pour moi (aucun mal à trouver du travail, avec pourtant un CV pas forcément exemplaire) ^^'.
Je continue avec cette stratégie en bossant sur du Dart et du No-SQL en pariant sur l'avenir.

[Washmid]

Je suis d'accord avec ce développeur. Je rajouterais qu'il en va de même pour .NET. Javascript est très tendance avec son modèle asynchrone et ses Frameworks, a une demande augmentant fortement depuis quelques années, permettant d'effectuer des développements portables, réactifs.

Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.

Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !



Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque.

[LSMetag]

Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.

Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !



Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque.

Pour être franc, je bosse d'abord au feeling. Si une techno m'intéresse et me semble utile, je l'étudie.

Même en autodidacte, les entreprises qui voudront l'utiliser te prendront car peu la maîtriseront. Donc beaucoup moins de concurrence que si tu rentres dans le moule avec J2EE que tout ingénieur a appris à l'école.

Alors il y a une part de risque à faire ça. Mais me concernant ça a bien payé.

Après, on peut sortir le raisonnement inverse. On ne connaît pas l'avenir d'une techno jeune. Mais pourquoi justement ne pas participer à cet avenir plutôt qu'être attentiste ?

Justement, je ne suis pas très raccord avec les entreprises qui ne misent que sur du mature, car je n'aime pas l'inertie. Je préfère utiliser tout le panel des technos qui s'offrent à moi pour choisir ce qui conviendra mieux à mon application et à ses utilisateurs.

Bien sûr, il faut bien concevoir son appli pour faciliter les migrations en cas de pépin. Il faut aussi garder en tête qu'il faudra choisir les ingénieurs pas forcément par rapport à leur CV, mais par rapport à comment est faite leur tête, et leur laisser quelques semaines pour se former.

[23JFK]

Sont malins chez paypal, ils ont réussi à mettre dans leurs serveurs une technologie encore plus prisée par les blackhats que le java. Vue la facilité avec laquelle se réalisent des attaques par injection sous javascript (merci le typage faible), tout le temps qu'ils pensent avoir gagné en production, va être perdu en sessions de rustinages.

[fr1man]

@ LSMetag

Sauf que l'ecosystème JAVA est dépendant du JCP et que les choix faits sont réfléchis pour ne pas tout remettre en cause tous les ans.
C'est quand même plus facile pour une équipe qui ne dépend de personne, de pondre un Node.js, un Playframework ou autre.
C'est bien beau tous ces nouveaux frameworks qui sortent tous les mois, mais qui sait ce qu'ils deviendront dans quelques mois mois/années.
Tu pars sur du standard, tu sais que ça ne sera pas abandonné en peu de temps, et que tu continueras à trouver de la main d'oeuvre compétente.
Peut-être que Node.js ou autre, ne sera qu'un pétard mouillé et vite oublié...qui peut le dire...

[imikado]

Sont malins chez paypal, ils ont réussi à mettre dans leurs serveurs une technologie encore plus prisée par les blackhats que le java. Vue la facilité avec laquelle se réalisent des attaques par injection sous javascript (merci le typage faible), tout le temps qu'ils pensent avoir gagné en production, va être perdu en sessions de rustinages.

Javascript est typé: http://web.developpez.com/actu/59624...-a-l-accepter/

De plus, le typage ne protège pas de tout: pour un type string, on peut faire du xss et/ou de l'SQL injection

Et concernant le XSRF/DDOS le typage ne protège en rien

[Gugelhupf]

Javascript est typé

A vrai dire je ne connais pas de langage avec des variables non-typé.

En PHP et JavaScript il est possible de faire ce genre de chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
var entier= 1;
alert(typeof(entier)); // number

entier= "1";
alert(typeof(entier)); // string

En Python, même si on ne précise pas le type (duck typing), ce genre de chose n'est pas permis par exemple.

Le fait de pouvoir effectuer des opérations mathématiques sur certaines chaines de caractères (au format entier/décimal) rend la maintenance plus difficile.

Mais je ne sais pas si c'est le pire, en ce qui concerne la portée des variables par exemple (valable aussi pour PHP) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if(true){
    var toto = 1;
}

alert(toto); // Affiche 1, variable toto existe toujours

[bunam]

Je me demande si paypal™ a utilisé SmartOS de Joyent qui est la boite qui a crée NodeJS...
SmartOS doit être la meilleure alternative pour faire du NodeJS (dtrace, isolation avec les zones...)
Si oui c'est un aussi un mauvais coup pour Red Hat ou Oracle qui devait fournir précédemment l'OS.

[lxwfr]

Déjà appris ses quelque fonction à vrai n'utilise jamais, Peut-être dû au FAILLES DE SECURITE (Les nouvelle mise à jours=correction).
No.JS j'ai pensé !!! je vais apprendre plus tard (déjà vu quelque part).

[oLie]

Le problème initial chez PayPal étant la rationalisation de leurs compétences JS, je pense que l'objectif est atteint.

Au sujet des perfs, les avancées technologiques couplées à une efficacité budgétaire promeuvent l'application du "commodity hardware", déresponsabilisant le développeur sur l'aspect performance (voir aussi sur la production de code "propre"). C'est d'ailleurs le même principe avec le NoSQL, on "l'accepte" aujourd'hui car le hardware est capable de supporter ce qui était considéré comme de mauvaises pratiques il y a 20 ans sur du hardware moins performant.

Au final, [ame="http://www.youtube.com/watch?v=AFXK03FCa14"]c'est (et ça a toujours été) la monnaie qui dirige le monde[/ame], nous ne sommes que des pions qui, au mieux, cherchent des solutions efficientes dictées par la direction financière et relayé par la DSI, ou au pire, qui subissent des choix d'orientations technologiques parfois douteuses, dictées par des "solutionneurs" d'efficience

[nah-masse-the]

@oLie: ca fait beaucoup de buzword pour dire que l'ingenieurie logiciel est une science qui evolue, si on a du NoSQL aujourd'hui c'est pour pouvoir scaler horizontalement les bases de donnees, pas une question de bonne ou mauvaise pratique... Deja entendu parler du CAP theoreme?


@Gugelhupf: Tout les languages sont types, la seule difference se fait au niveau du typage for ou faible. Le C est type faiblement, tu peut acceder a une valeurs en memoire en la considerant comme un entier ou une chaine de caratere.


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

Va donc coder en assembleur, sans bibliotheque standard pour s'occuper de la memoire ou des entree sortie standard. Serieusement. Fait le. Retourne au sources. J'ai des cartes perforees pour toi si tu veux.


@Washmid
"Facebook étant revenu à Java suite à l'implémentation de son appli android en javascript suite aux problèmes de performances, il faut donc en conclure que l'avenir c'est Java.
Ha, autant pour moi, quelques mois plus tard, Paypal fait exactement le contraire, il faut donc en conclure que l'avenir c'est javascript !
Plus sérieusement j'en conclut qu'il vaut mieux étudier chaque besoin avant de choisir une techno, et que les généralités sont un peu... à côté de la plaque."

Enfin un peu de bon sens, merci.

[oLie]

c'est interessant comme idée, dans ce cas pourquoi ne pas l'avoir inventé dès le début...

[sekaijin]

Comme toujours on peut voir une "gerre" de chapelle.
pour ma part je regarde la démarche et le résultat m'importe peu.

tout cela pour moi confirme une chose que je pense depuis longtemps. Si on analyse sans apriori les solutions disponible sur le marché et qu'on défini des odjectifs clairs on peu choisir de façon opportune.

la question ici n'est pas de savoir si JS ou C++ ou Java est plus rapide, moins gourmand ou quoi que ce soit de ce genre.

La question est Dans ce contexte précis, avec les compétence présente, qui de Node.js et de Java est le plus adapté pour atteindre les objectif fixés.

Paypal en fonction de CES besoins à choisi Node.js.

cela ne signfi nulement que Node.js est meilleur que qui que ce soit.
cela signifi que du point de vu de Paypal pour ce besoin dans ce contexte avec ces compétences Node.js est apparu comme le plus approprié.

Pour ceux qui disent que C++ ou je ne sais quel langage serait plus rapide
posez vous la question de savoir pourquoi on écrit encore des shell scripts.

pour moi cette affaire devrait servir d'exemple et Paypal serait bien en lumière si elle publiait sa methode de choix.

je lis ici ou là que ce genre de post ou d'annonce vise à tuer Java ou je ne sais quoi d'autre.

moi ce que je lit c'est que Node.js peut être concidéré comme une alternative. non pas un remplaçant mais un outil de plus.

quand rubi à débarqué on a eu droit au même phénomene. Oui techniquement rubi était bien mais avion snous la preuve que pour une grosse app il faisait l'affaire ? puis petit a petit certains ce sont lancé et on monté que c'était viable.
ça n'a tué personne ça a juste ajouter une possibilité de plus.

Node.js est arrivé est de la même façon on a eu quelque dev ici où là mais pour un responssable choisir Node.js n'était pas facile car trop jeune. depuis il a fait petit à petit ces preuves.
aujourd'hui Paypal nous dit "Node.js est vaible pour une applie de grandes ampleur. Nous y croyons, nous avons évalué la solution, et nous l'avons retenus"

Je dis Chouette un outil de plus. lorsque nous aurons un projet pour faire notre choix nous mettrons en face des besoin et du contexte un outils de plus nous aurons donc une chance de plus d'avoir un outil adapté.

qui à parlé de tuer Java ? qui à dis que JS était plus rapide que Java, qui a dit que JS était meilleur ?

A+JYT

[sparkyXI]

D'un autre côté ce n'est pas étonnant: en le réécrivant complètement en js ils ont pu optimiser leurs code, éliminer ce qui n'était pas utile, mieux penser les algo.

S'ils l'avaient réécrit en java, ils auraient aussi eu des gains de performance,

D.

[AlexRutny]

Les développeurs de Paypal se font de la pub à peu de frais (merci à qui?). Il est vrai que l'on est jamais mieux servi que par soi-même. Pour avoir des benchs un peu sérieux et surtout reproductibles (les codes sources sont accessibles), je vous recommande le site : http://www.techempower.com/benchmarks/ (je n'ai pas d'actions chez eux!).

En conclusion node.js a encore qq progrès à faire pour concurrencer les meilleurs frameworks en terme de performances...

[sovop]

@Paul TOTH:
moi je ne pense pas que l'équipe JS du Paypal est plus compétent que celui Java, mais au contraire je pense le Team-Backend est le le plus compétent et peux imaginer aussi que c'est ce dernière qui a fait le refactoring ou re-dévélopment total en JS.

La raison pour ce point de vue est que dans pas mal des cas (je ne généralisent pas) les Frontendlers ont des problèmes à comprendre et appliquer les design patterns et les concepts OO même les plus simples comme l'héritage. En plus il y a le risque qu'ils implementent un spagetti-code :.

[ddoumeche]

Je suis d'accord pour dire que JS n'est pas encore mature dans ce genre de contexte. mais c'est justement parce que certain font ce genre de portage et d'annonce qu'on avance vers plus de maturité.

S'il vous plait arrêté de dire qu'on perd énormément en citant le débogage
On debugue très bien avec JS debugueur pas à pas, jsunit et tout ce qu'il faut pour faire du code de qualité comme dans tous les langage.

quant au typage fort autant je suis d'accord pour dire qu'on ne l'a pas avec JS autant je me demande en quoi c'est une perte.
quand je vois la quantité de code produit dans les langage à typage fort pour palier le manque de souplesse du typage je me dis que PARFOIS le typage dynamique à du bon.

par contre pense qu'il manque encore des outils de profiling à la hauteur des grosse applications.

Je suis toujours étonné de voir depuis des années fleurir au sein même de domain ou on prone le typage fort et la poo à base de classe, divers langage qui introduise du typage dynamique du typage faible etc.
que dire des capacité runtime de objective-c de c# que dire de langage comme scala et bien d'autres. tous introduise à des doses plus ou moins importantes des notion qui assouplissent les contraintes du typage fort.

Ce phénomène général (on le vois partout) montre pour moi que parfois les langage au typage trop fort sont des contraintes.

JS est effectivement à l'opposé cela fait peut être peur. mais pour moi ce n'est pas une tatre c'est une caractéristique à exploiter. c'est sur qu'il faut penser autrement. mais il n'est rien de pire que la pensé unique.

A+JYT

Même si je suis en désaccord sur certains points exposés ci après, je rejoins une partie de ton analyse : JavaScript est immature, mais s'améliore.
Non pas que je méprise ce langage, je l'utilisais même couramment il y a 10ans, même coté serveur via jscript sur asp (pour la mutualisation des librairies entre contexte serveur et client).
Mais comme d'autres, je me suis rendu compte des multiples problèmes de telles solutions.

Déja, au pur niveau développement, on ne débogue pas du code hébergé sur Node.Js avec JS debugueur. Existe-t'il un déboggeur pour ca d'ailleurs ? Aptana Studio ? nous en sommes rendu au niveau du php il y a 10 ans.
Et tu relèves le problème du profiling: faisable dans les browsers, pas encore faisable dans NJS.

Certes il y a JSUnit si l'on fait du code modulaire, mais cela ne peut détecter que des problèmes sur le code testé et une couverture de test à 100% est illusoire. Or js est un langage interprété: si quelqu'un committe du code qui ne compile pas, ce ne sera probablement pas relevé par l'usine logicielle, mais par les collègues.

Au final, je ne vois pas le gain de temps sur le développement

[Mickael_Istria]

Déja, au pur niveau développement, on ne débogue pas du code hébergé sur Node.Js avec JS debugueur. Existe-t'il un déboggeur pour ca d'ailleurs ?

Je pense qu'il faut plutot chercher du cote de Chrome Dev Tools, Firebugs et compagnie pour pouvoir debugger du JS deploye.
Sinon, dans le dev, en utilisant une combinaison de live-deploy, live-reload et compagnie pour redeployer le bout de JS a chaque changement, on arrive a peu pres a un environnement convenable, mais comme tu le fais remarquer, c'est du meme acabit que PHP.