le nodejs

Je suis critiqué par des développeurs Java, C++, Rust, Go par ce que que j’utilise Javascript comme langage de prédilection pour le développement d’applications dans le domaine du jeu vidéo On critique le fait que Javascript à un typage faible, qu’il est mono thread, que l’éco système JS soit une "blague" dont npm serait une mascarade.. Je me retrouve un peu dans l’embarra de ne pas savoir quoi répondre, de ne pas savoir si ils n’auraient pas raison et que je serai donc tout simplement entrain de me planter..

Salut,

Ne t’en fais pas trop, ce genre de troll est assez fréquent dans le milieu (j’en sais quelque chose, mon langage de prédilection est le PHP ). Ce qui est important, c’est que ce que tu fasses ce que tu aimes réellement. Tu n’as même pas besoin de répondre à ces remarques.

Et si vraiment ça t’atteint, n’hésite pas à leur en parler, leur dire que ça te met mal à l’aise.

Je me retrouve un peu dans l’embarra […] de ne pas savoir si ils n’auraient pas raison et que je serai donc tout simplement entrain de me planter..

Certainement pas. Le JavaScript est un langage devenu aujourd’hui incontournable dans le milieu du Web. On en a de plus en plus besoin autant en back qu’en front.

Bonjour,

Je pense aussi que Javascript ait beaucoup de défaut, et npm est clairement déviant (suffit de voir le nombre d’utilisation d'un package qui te dit si un nombre est pair )

Cependant, y a des cas d’utilisation où JS est seul à répondre au besoin, typiquement le web.

Il y a toujours eu beaucoup de tension entre les utilisateurs de différents langages. De mon point de vue, ça ne s’arrête qu’à des arguments de cours de récré (c’est le mien qu’il est mieux).

Si tu veux changer de langage, tu peux être sûr que tu auras les mêmes critiques, il vaut mieux ne pas te laisser intimider par ceux-là. Ce qui ne doit pas t’empêcher d’être critique sur le langage que tu utilises.

C’est plutôt sain en revanche de remettre en question les outils qu’on utilise tous les jours, pour les améliorer, que ce soit au niveau de la courbe d’apprentissage, de son écosystème (pourquoi existe-t-il un paquet en JS pour déterminer si un nombre est impair, et pourquoi dépend-il d’un autre paquet qui détermine quant à lui s’il est pair ?), ou même des éléments de langage (pourquoi PHP a-t-il mis si longtemps à fournir la possibilité de créer des structures enum ?).

Mais je trouve cela bien plus pertinent lorsque cette remise en question est faite par des gens qui utilisent (et aiment même) leurs technologies.

Le problème derrière tout ça, c’est de connaitre les avantages et les limites du langage que tu utilises. Et pour le coup je suis moins défenseur de JS que @randyfz. Les reproches faits à JS sont ceux-ci :

On critique le fait que Javascript à un typage faible, qu’il est mono thread, que l’éco système JS soit une "blague" dont npm serait une mascarade.. Je me retrouve un peu dans l’embarra de ne pas savoir quoi répondre, de ne pas savoir si ils n’auraient pas raison et que je serai donc tout simplement entrain de me planter..

En fait, ils sont plutôt vrais… la question est surtout de savoir si c’est gênant, et si ça a une importance ou pas.

• Le typage faible (ou plus exactement dynamique) : ça veut dire qu’il va falloir comprendre les conversions de types automatiques faites par le moteur, et aussi que tu peux te retrouver à manipuler des objets (variables, paramètres) sans avoir d’idée fiable de leur structure. Ça peut être un gros avantage (on te passe « un objet » et tu utilises juste ce dont tu as besoin), mais un vrai handicap pour le travail en équipe ou l’utilisation de bibliothèques, quand il n’y a pas de moyen simple et rapide de vérifier ce que devrait contenir l’objet, ni aucune garantie qu’il contienne réellement ce qui a été promis. Si ces problématiques surgissent, TypeScript est une bonne solution.
• Le mono thread pose deux problèmes :
  1. Ça rends la gestion d’un serveur un peu casse-pieds parce que si tu veux utiliser N cœurs, tu dois avoirs au moins N instances de l’application lancées en parallèle (avec les problèmes de gestion, de communication inter-processus et de surconsommation mémoire qui vont avec),
  2. Si tu as des tâches gourmandes en CPU, tu ne peux pas les laisser tourner dans la boucle principale d’un framework à base de coroutines ou réactif, donc tu es plus ou moins obligé d’utiliser des threads. La solution JS avec les workers a des limitations (notamment sur ce que tu peux passer comme types aux workers) qui la rend casse-pieds à utiliser. Mais c’est un cas assez peu courant.
• L’écosystème JS a des produits de très grande qualité… et des clowneries sans nom, comme un peu partout j’imagine. Pour moi ses problèmes réels sont :
  1. Beaucoup trop de monde se repose sur des surcouches de surcouches de surcouches de frameworks que personne ne maitrise et qui sont inutilisables dès que tu sors du cas nominal – mais tu n’es pas obligé de les utiliser.
  2. Cette manie de tout découpe en bibliothèques microscopiques qui t’oblige à avoir un arbre de dépendances délirant dès que tu importes le moindre framework.
  3. Une hystérie très présente dans les rythmes de développement, certains présentant comme un avantage d’avoir une release par semaine. Ce point et le précédent font qu’il est difficile voire impossible de suivre les mises à jour des dépendances, ce qui est souvent sans conséquences… sauf quand arrivent des dépréciations sauvages et des corrections de failles critiques.

Sachant ça, c’est à toi de voir si ces inconvénients vont t’impacter, et comment, et surtout comment ils se positionnent face aux avantages du langage (notamment : la souplesse, la possibilité de faire des choses très vite sans trop de boilerplate code (selon ton framework ou pas), l’immensité de bibliothèques et de ressources disponibles, la facilité à trouver de l’aide, etc).

L’écosystème Java EE a quelques grosses forces bien à lui, mais la perf' n’en est pas une.

En fait, ça c’est juste… faux ? Même les vieilles applications Java EE bien codées sont capables de tenir des charges folles¹, mais en plus ça fait des années qu’il y a de très bons framework réactifs (avec I/O non bloquantes) en Java, cet argument est périmé. L’écosystème NodeJS comme JVM ont tous les deux des runtimes très performants, choisir entre ces deux là sur la base de la performance est clairement une erreur. C’est tout ce qu’il y a autour qui devrait piloter le choix : connaissances des équipes, harmonie avec le reste du SI pour éviter d’avoir 36 technologies différentes, bibliothèques et frameworks existants, contraintes de déploiement et maintenance…

pourquoi existe-t-il un paquet en JS pour déterminer si un nombre est impair, et pourquoi dépend-il d’un autre paquet qui détermine quant à lui s’il est pair ?

L’auteur l’a expliqué depuis longtemps : c’était des paquets destinés à tester… comment on construit et publie un paquet. Le problème n’est pas dans l’existence de ces paquets, mais dans le fait que certains les ont utilisés.

Je me trompe peut être, mais je pense qu’il y a deux problèmes avec le JS (qui n’en font pas un mauvais langage):

1. Comme le disait @rayandfz, "le moins formellement appris et donc le plus mal compris aussi": j’ai l’impression (mais rien de quantifiable) qu’on a une armée de dévelopeur JS sur le marché, qui ont apris à faire du JS "pour le web" et qui n’ont pas forcément reçu de formation en algorithmique pour aller avec. Ça pourrait être vrai pour un autre langage (j’ai l’impression qu’on a un peu ça avec le Python en IA), malheureusement c’est surtout vrai pour le JS.
2. Conséquence (?): on essaye d’utiliser la masse de dévellopeurs disponibles, et donc on étend le JS a plein de domaines (il y a des bindings pour un peu tout et n’importe quoi), dont des domaines ou ce n’est pas forcément pertinents (parce que le JS n’est pas adapté à certains types de problèmes, ce qui, encore une fois, n’en fait pas un mauvais langage).

Bref, comme on l’a déjà dit, et comme le redit @Spacefox, c’est important "connaitre les avantages et les limites du langage que tu utilises". Et j’ai l’impression que c’est parfois oublié (mais, encore une fois, c’est vrai pour d’autres langages, genre Python).

Quand à npm (que j’exècre par tout les pores de ma peau), le problème n’est pas npm lui même, mais la problématique générale des packages, et je n’ai pas trouvé mieux ailleurs (pip est pas spécialement mieux, par exemple). Je pense que l’analyse de @Spacefox, est ceci dit intéréssante, une partie du problème est probablement l’existence de bibliothèques microscopiques qui génère des arbres de dépendance déconnés (packages.json, je te hais!).

J’ai l’impression, dans ta formulation, que ça te gêne de recevoir ce genre de critiques et que tu cherches à les contredire absolument, voire que tu penses recevoir injustement ces critiques. Est-ce le cas ? Pourquoi donc ?

Si quelqu’un te dit que JS est faible sur l’aspect X, tu as tout intérêt à évaluer honnêtement cette critique et l’accepter éventuellement. Cela, te permettant ainsi de renforcer la maîtrise de tes outils. Car, oui, avoir conscience des faiblesses et des limites de ses propres outils, voilà une étape qui me semble nécessaire en vue de les maîtriser.

Le débat constructif avec d’autres développeurs qui exposent des expériences différentes et viennent d’autres horizons permettent de s’affranchir de ses œillères¹ !

Si tu acceptes et comprends les bonnes critiques sur JS, alors il ne sera plus question d’un quelconque embarras. Tu pourras répondre des choses du genre : « Oui, j’ai bien conscience de cette limite avec JS, mais j’estime que dans mes projets cela n’est pas un problème car X et Y » ou bien « Oui, je comprends cette critique adressée à JS, mais de mon expérience il est facile de mitiger le problème grâce à X ou Y ».

Évidemment, ce n’est pas propre à JS. C’est le cas pour absolument tout le reste aussi. Rien n’est exempt de défaut.

merci des retours et est-ce que vous savez si j’ai un interêt à partir sur JS pour tout projet ou si je dois partir sur java ou autre ?

En effet typage faible et typage dynamique sont deux concepts différents, mais en quoi le typage de JS ne serait pas faible ?
C’est un langage qui réalise des conversions implicites des données lors d’opérations entre valeurs de types différents (et dont le résultat est généralement difficilement prédictible) et ne produit jamais d’erreur de typage sur ces opérations (ce qui est la caractéristique des langages à typage fort).

Comme très souvent, le fond du problème est le caractère dogmatique des zélotes des langages X, Y et Z… À propos de JS, j’avoue que je serais bien en peine de le défendre puisque je ne l’utilise pas, et l’ai jamais utilisé, et ne l’utiliserai probablement jamais, mais j’ai très envie d’abonder dans le sens de @sgble .

Il ne faut surtout pas se faire entraîner dans cette logique de cour de récré qui voudrait absolument désigner un vainqueur entre telle et telle technologies : ça voudrait dire se mettre à raisonner dans des absolus qui sont déconnectés de la réalité, or le développement informatique consiste justement à prendre perpétuellement des décisions en fonction de la réalité que l’on a sous les yeux, là tout de suite.

Cela veut dire par exemple que :

• À moins que l’on soit dans la perspective de recruter 100 personnes dans l’année, on s’en contrefout du nombre de gens qui utilisent telle ou telle techno : on a un projet à démarrer, on a nos compétences à nous et l’obligation morale de faire de notre mieux, alors on part sur la techno que l’on connaît le mieux pour maximiser les chances de succès. C’est pas la popularité de ton langage qui t’aidera à débugger un crash du serveur de prod ou à implémenter rapidement une fonctionnalité dont tes utilisateurs ont besoin.
• Comme l’ont très bien dit @SpaceFox et @sgble : toute techno a ses problèmes "dans l’absolu", même les plus en vogue. Mais ça ne signifie pas que ce sera des problèmes pour toi dans le contexte de ton projet : par analogie, tu t’en fous que ton moteur chauffe au bout de 100km si tu ne fais que des trajets de 30km par jour…
• Le plaisir que tu as à utiliser ton langage compte énormément sur ta motivation à maintenir un projet pendant des mois/années. Bien plus que le caractère statique/dynamique, fort/faible de son typage.

Néanmoins la remarque de @sgble est super importante : ça marche aussi dans l’autre sens. Ce n’est pas parce qu’ils ont tort de t’accabler avec toutes ces âneries qu’il faut se fermer à leurs arguments ou leurs technos. Le meilleur moyen de répondre à quelqu’un qui te bassine avec Rust, par exemple, c’est encore "oui, ben j’ai essayé Rust, j’ai fait tel petit projet avec, et ce langage m’a gonflé parce que ça, ça et ça, et si j’avais à refaire le même projet, je ne choisirais certainement pas Rust pour ça : au moins avec Node je peux faire ça, ça et ça". Mais pour que cette réponse soit honnête et solide, il faut vraiment essayer la techno en question et observer quels sont les différences avec tes habitudes, et ensuite décider dans ce contexte si c’est mieux ou moins bien qu’avec Node.

Pour finir, cette démarche porte un nom. Réfléchir de façon rationnelle en se rattachant toujours à la réalité pratique que l’on a sous les yeux, quitte à faire des expériences concrètes pour se faire une idée quand on ne sait pas, c’est avoir une approche pragmatique. À mes yeux, c’est la seule approche qui permette d’aborder ce style de trolls de façon constructive tout en restant bien droit dans ses pompes.

Sur les critiques du Javascript, je dirais ceci : contrairement à beaucoup d’autres langages, il n’a pas eu une croissance rationalisée, mais a fonctionné au début du web, le javascript s’est construit n’importe comment avec des pressions des navigateurs en tendance, et les développeurs ont tendance à l’utiliser partout à tort et à travers.

Et j’ai l’impression que la plupart des reproches faits par les zélotiens sont soient basés sur ce fait, soit basé sur une préférence pour un autre paradigme (orienté-objet, ce que javascript n’est pas tout à fait mais il en est franchement pas loin, concurrent, etc.).

Je suis moi-même un bafoueur du JavaScript (basé sur le premier paragraphe, largemement démontable), bien que ne l’ayant jamais utilisé, à cause du premier fait et de l’écosystème géré par npm, mais d’un autre côté, cargo en Rust ne fait pas mieux avec les innombrables crates en dépendance. Les failles de sécurité apportées par les dépendances ne sont pas propres à npm, mais aux arbres de dépendance. Attention : je n’attends pas de contre-arguments (et je m’en ficherais, ne gâchez pas votre temps), pour une raison simple : j’admets tout à fait que ma position est dogmatique, car ce n’est pas un sujet auquel j’attache beaucoup d’importance et auquel je veux consacrer de l’énergie (l’informatique n’est pas mon métier, et le dev web encore moins). A ce titre, n’importe quelle personne qui a déjà développé quelque chose en javascript est plus calé que moi et à même de formuler des critiques. Oui, comme certains l’ont dit, taper sur javascript est un passe-temps.

Néanmoins, pour avoir travaillé avec des gens qui ont poncé JavaScript, il me semble que bon nombre des arguments qui auraient pu avoir un fondement s’effondre dès qu’on utilise TypeScript, qui rajoute des guards. Voilà, tu as là la position d’un quidam programmeur sur le javascript. Je te laisse voir si tu considères si mon avis a la moindre valeur.

Je peux juste te donner deux billes pour traiter ces arguments. On pourrait les qualifier de zététique :

• Ce qui est avancé sans preuves peut être rejeté sans preuve
• A partir du moment où quelqu’un prend le temps de faire une critique construite, je pense que tu dois (moralement) lui rendre ce temps en y réfléchissant sérieusement. Sachant que tu n’as pas uniquement les options accepter/refuser, mais tu peux juste modifier certaines de tes positions aussi.

Dernière chose : si tu te poses vraiment des questions, je te conseille la démarche suivante, et c’est celle que j’adopte avec mes proches sur les sujets touchy (vaccination, toussa).

• J’ai un débat avec une personne. On reste fixé sur nos positions.
• Néanmoins, je prends du temps pour vérifier. Généralement, je réajuste mes positions.
• Je prends le temps de démonter les positions (typiquement, dangerosité du vaccin) absurdes, en répondant point par point aux arguments.
• Un argument déjà réfuté, je ne m’y attarde même plus. Si la même personne me le répète, je lui réponds quelque chose du style "on en a déjà parlé, je t’ai déjà répondu, tu veux pas changer de disques ?" (et encore, là, je suis soft).
• A terme, ou bien tu comprends que la personne est dogmatique et ça ne sert à rien de discuter, ce qui permet d’évacuer les personnes non-constructives. Ou bien les personnes vont venir avec d’autres arguments, ou pas par flemme.

L’objectif ? Tu apprends des choses. Typiquement, le fait que javascript soit pas un langage orienté objet mais un langage orienté objet prototype (si c’est la bonne dénomination ?) est source d’erreurs quand tu écris du javascript, donc le savoir peut être bien.

Voici ce qu’avait à dire un béotien, qui a un énorme biais de confirmation.

Dernier point : si c’est des rustiens qui viennent critiquer le javascript, franchement, les écoute pas, qu’ils aillent balayer devant leurs portes (pour le coup, je suis + aguerri en rust qu’en JS, de très loin). Deux petits trucs rigolos :

• Les dépendances des crates (paquet) de Rust sont aussi gargantuesques que ceux des paquets npm.
• Le rust se vante d’être fonctionnel, sans pour autant gérer correctement les fonctions tail-récursives car le backend LLVM (jusqu’à il y a encore un an ? pas sûr que ça ait été incorporé) ne gérait pas de manière déterministe les flows tail-récursifs. Donc bon, ça la fout mal de critiquer sur le paradigme.

Aucun langage Et j’ai l’impression que la plupart des reproches faits par les zélotiens sont soient basés sur ce fait, soit basé sur une préférence pour un autre paradigme (orienté-objet, ce que javascript n’est pas tout à fait mais il en est franchement pas loin, concurrent, etc.).

Javascript est un langage qui comprend le paradigme objet (simplement par prototype)

Pour information, je ne me sent pas de répondre à chacun des arguments qui me titille par manque d’énergie mais aussi par ce que je ne suis pas sûr de certains points

Mais, je pense sincèrement que le langage est très mal compris et mal appris et que les plus part des éléments que les gens pensent être mal conçus sont en réalité bien conçus et mal compris

JS n’est pas un langage comme Java ou C#, il ne faut pas essayer de le comparer avec l’incomparable

JS n’est pas un langage comme Java ou C#, il ne faut pas essayer de le comparer avec l’incomparable

Faut pas pousser non plus, il est question de Node, donc d’une techno classiquement utilisée pour le backend. À ce titre il y a forcément un choix qui se pose pour developper le back en Node ou en autre chose, et les alternatives habituelles dans cet usage sont bien Java et C#, mais aussi Python, Go et PHP. Si un choix doit être fait, alors il y a forcément une comparaison qui s’impose.

Pareil pour les jeux vidéo : les autres technos usuelles sont C# (Unity) et C++ (UE), mais aussi le godot engine et Löve2D (Lua) et j’en passe. Là aussi, pour faire un choix il faut comparer. Même si pour démarrer sur un petit jeu, "ton langage préféré" est généralement le meilleur choix par défaut.

Tout ça est évidemment comparable. À condition que ce soit sur des critères pertinents dans le contexte du choix.

Edit : Le paradigme n’est pratiquement jamais un critère pertinent… En tout cas vachement moins que, disons, "je connais bien cette techno pour avoir bossé avec donc je n’ai pas à l’apprendre, alors que cette autre techno m’est étrangère et ne m’intéresse pas spécialement"

Le multi-thread est une solution dégueulasse au problème de la parallélisation, et la majorité des codes multi-threads ont une tonne de problèmes. On préfère un système soit multi-threads à forte isolation (ex. workers) soit multi-processus, mais surtout la perf viendra du fait que le code est non-bloquant, en particulier pour les I/O. […] D’ailleurs, Rust et Go ont une approche de la concurrence qui n’est pas tellement basée sur les bons vieux threads.

Mouais, la stratégie de parallélisation à utiliser va surtout dépendre d’une part de ce qui est disponible dans le langage pour le faire, et de ce qui est efficace pour traiter le problème en question. Typiquement, la concurrence asynchrone, c’est très bien pour gérer de l’IO non bloquante mais c’est loin d’être le seul problème qu’on a envie de gérer, et surtout c’est pas du parallélisme. Tu dis que le multi-threading est une solution dégueulasse, mais c’est surtout parce que NodeJS offre une façon relativement propre de faire du multi-processing avec des processus bien isolés les uns des autres. Le multi-processing comme on en fait de façon massive avec MPI et similaire, ça c’est vraiment du parallélisme bien dégueulasse avec peu de garanties (et rien qui permette de vérifier statiquement qu’on n’écrit pas n’importe quoi). Il est aussi ultra casse-gueule de partager de la mémoire entre deux processus, alors qu’entre deux threads c’est plus simple (surtout si t’as un système de types derrière pour te prendre la main). Rust rend même ça très gérable avec Sync. Au passage, le multi-threading est la solution standard pour faire du parallélisme en Rust (tu peux aussi faire de l’asynchrone, mais il n’y a pas de runtime standard pour ça). Go aussi retombe sur des OS-threads lorsque des goroutines sont bloquantes (et rend les communications gérables en forçant un modèle simple de message-passing).

Bref, tout ça pour dire que la stratégie à effectivement appliquer pour faire du parallélisme/de la concurrence va dépendre beaucoup du problème à résoudre et de ce qu’offre le langage/l’écosystème. Entre de la simple IO non bloquante et des tâches plus CPU-intensive, qui se prêtent plus à de la mémoire distribuée vs. partagée, etc, il y a tout un univers de stratégies. On ne peut pas balayer le multi-threading de façon générale comme tu le fais. Une observation certaine, par contre, c’est que les langages systèmes étaient coincés au moyen-âge avec des choses comme MPI et OpenMP qui sont des puits sans fond à problèmes, alors qu’on sait depuis longtemps (avec Erlang par exemple) qu’on peut faire mieux en terme de confort de développement et beaucoup plus sûr au runtime. Rust arrive comme une bouffée d’air sur ce créneau.

Pour résumer les messages de mes compères ci-dessus, la réponse est : ça dépend.

Pour un projet simple que tu seras seul à maintenir et sans gros enjeux du JS fera probablement l’affaire si c’est ce que tu connais le mieux.

Pour un plus gros projet, il faudra probablement évaluer d’autres options et faire un choix en connaissance de cause. Mais pour pouvoir faire ça il faut de l’expérience.

Commence donc par pratiquer sans trop te soucier de l’avis des autres : tant que tu arrives à produire efficacement, c’est que ton outil est pas si mal

Gros +1 pour cette phrase : le meilleur langage pour ton projet perso, c’est celui avec lequel tu es le plus à l’aise pour réaliser ce projet.

(Pour un projet en équipe, c’est plus compliqué, mais c’est un bon point de départ.)