Discussion :

[moldavi]

Bonjour.

Personnellement, j'utilise JS en backend parce que cela m'évite de passer constamment du JS au PHP, et que cela me permet de transférer facilement du code du front-end au back-end, et inversement. De plus, JS est pas mal pour manipuler du DOM.

Je n'en doute pas, je suis juste curieux de connaître les SLA de ce backend, et aussi des Fronts.

[Neckara]

Je n'en doute pas, je suis juste curieux de connaître les SLA de ce backend, et aussi des Fronts.

C'est très simple y'en a pas.

[Marco46]

C'est quoi le rapport entre un SLA qui est un concept commercial et le choix du langage ?!?

[moldavi]

Bonjour.

C'est très simple y'en a pas.

C'est quoi le rapport entre un SLA qui est un concept commercial et le choix du langage ?!?

C'est vrai que c'est une discussion difficile à suivre.

Les SI utilisent ce truc par phénomène de mode, par lobbying et par facilité, pas par efficacité.

SLA, performance, tout ça, c'était juste une question personnelle.

J'ai tenté d'orienter le débat, et d'expliquer l'évolution de javascript vers typescript, puis maintenant fonctionnel. Visiblement, je suis le seul à y voir une cohérence.

[Marco46]

Je repose la question, quel est le rapport entre un SLA qui est une offre commerciale et le langage choisi ? Tu peux avoir un SLA sur un produit développé avec n'importe quel langage.

Par ailleurs tu te trompes sur l'effet de mode, c'est pour des raisons techniques (de dev mais surtout d'exploitation) que Netflix et Paypal ont choisi Node vs J2EE. Je t'invite à lire leurs RETEX ils sont dispos sous forme d'articles (sur medium je crois) ou sous forme de conférences (anglais).

[moldavi]

Bonjour.

Je repose la question, quel est le rapport entre un SLA qui est une offre commerciale et le langage choisi ? Tu peux avoir un SLA sur un produit développé avec n'importe quel langage.

Vu que je pense que le fond du sujet n'est pas développé par les différentes réponses ici, j'ai posé une question qui n'a effectivement aucun rapport. J'ai lâché l'affaire sur le sujet, parce que je n'ai pas trouvé de contradictions intéressantes à relever.

Par ailleurs tu te trompes sur l'effet de mode, c'est pour des raisons techniques (de dev mais surtout d'exploitation) que Netflix et Paypal ont choisi Node vs J2EE. Je t'invite à lire leurs RETEX ils sont dispos sous forme d'articles (sur medium je crois) ou sous forme de conférences (anglais).

C'est pour des raisons techniques que Netflix ou Paypal utilisent Node.js, certainement, je n'en doute pas. Le problème ce sont les développeurs qui se disent : ben tu vois Netflix ou Paypal l'utilisent, c'est ce que c'est bien... On va aussi l'utiliser... J'appelle cela l'effet de mode.

C'est le problème quand tu as des CP/architecte/développeur qui te collent le truc Node.js parce qu’ils ont vu les fameux RETEX, sans vérifier que cela colle bien à leur projet.

Après la boîte, elle a des SLA, enfin normalement. Si une boîte n'a pas de SLA, c'est qu'elle ne perd pas d'argent et qu'elle s'en fout de ces utilisateurs. Et bizarrement, aucun de ces intervenants n'est capable de te dire combien de serveurs, en plus ou en moins, il faudra pour tenir ce SLA (je simplifie ici). Bref c'est clair qu'ils font du node.js sans aucune maîtrise, juste par effet de mode et simplicité.

Je ne doute pas que Netflix ou Paypal savent ce qu'ils font. Ils ont certainement pesé le pour et le contre avant de se lancer, et surtout bien mesuré les choses. Et après, tu as les suiveurs bêtes et méchants, ça marche pour Netflix, ça marche forcément pour nous.

[StringBuilder]

C'est pour des raisons techniques que Netflix ou Paypal utilisent Node.js, certainement, je n'en doute pas. Le problème ce sont les développeurs qui se disent : ben tu vois Netflix ou Paypal l'utilisent, c'est ce que c'est bien... On va aussi l'utiliser... J'appelle cela l'effet de mode.

C'est le problème quand tu as des CP/architecte/développeur qui te collent le truc Node.js parce qu’ils ont vu les fameux RETEX, sans vérifier que cela colle bien à leur projet.

Je ne doute pas que Netflix ou Paypal savent ce qu'ils font. Ils ont certainement pesé le pour et le contre avant de se lancer, et surtout bien mesuré les choses. Et après, tu as les suiveurs bêtes et méchants, ça marche pour Netflix, ça marche forcément pour nous.

Ca me rappelle la grande mode du XML.
Début 2000, il a été décidé que le XML était LE truc génial pour gérer des données.
Du coup, tous les DSI ont décidé de péter tous leurs logiciels pour abandonner leurs méthodes habituelles de stockage/sérialisation pour passer au XML.
Résultat : des bugs, des lenteurs, des espaces de stockages multipliés par 2 ou 3. Je me rappelle encore de ces framework en J2EE ou ASP qui généraient du XML, pour ensuite le transformer en XSL alors que c'est tellement plus simple et plus maintenable de générer directement le HTML de sortie.
On a même vu apparaître des SGBD XML, qu'encore aujourd'hui quelques développeurs affectionnent, alors que ce sont des bouses infâmes en termes de performances.

Fort heureusement, ces dernières années est apparu JSON, bien plus concis, tout aussi puissant, et plus lisible (mouarf, le truc révolutionnaire qui a plusieurs décennies, comme en témoigne le langage de déclaration des scène du Ray-Tracer PovRay, franchement très proche du JSON, et qui a près de 30 ans... :
http://www.povray.org/documentation/....html#t2_2_1_3
http://povray.org/ (le site aussi doit avoir 25 ans )

Bref, NETFLIX a des besoins, PAYPAL aussi, et effectivement, il ne faut pas croire que si tel ou tel acteur a besoin d'un outil, que c'est cet outil qu'il faut.
Si un bûcheron a besoin d'une hache pour couper un arbre, vous n'allez pas développer à la hache (ou alors ça explique pas mal de choses quand on voit certains logiciels...)