Pour la plupart, à pas grand chose a part l'effet de mode.
Node est bon dans des cas où l'i/o est très grand face au cpu, étant base sur un modèle de non blocking i/o, ça permet de maintenir un très grand nombre de connexions clientes ouvertes.
L'exemple de base, c'est une appli de chat.
Le problème, c'est que tu te tapes un écosystème jeune, un gestionnaire de dépendance qui a défrayé la chronique récemment, et pas qu'un peu, et un langage franchement bof.
Et dès que tu devient cpu bound, tu bloques l'event loop, et c'est une réelle catastrophe.
Disons que l'async io et l'event loop single threade, c'est pas forcément trivial à coder, le langage se trimballe des tares, et dans la plupart des cas où je l'ai vu utilisé, un modèle threade aurait tres largement tenu la charge, tout en évitant la complexité de l'async.
Bref, c'est une techno qui a du bon, mais tres souvent utilisée dans des cas pas adapté du tout.
[^] # Re: Le javascript
Posté par groumly . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 10.
Pour la plupart, à pas grand chose a part l'effet de mode.
Node est bon dans des cas où l'i/o est très grand face au cpu, étant base sur un modèle de non blocking i/o, ça permet de maintenir un très grand nombre de connexions clientes ouvertes.
L'exemple de base, c'est une appli de chat.
Le problème, c'est que tu te tapes un écosystème jeune, un gestionnaire de dépendance qui a défrayé la chronique récemment, et pas qu'un peu, et un langage franchement bof.
Et dès que tu devient cpu bound, tu bloques l'event loop, et c'est une réelle catastrophe.
Disons que l'async io et l'event loop single threade, c'est pas forcément trivial à coder, le langage se trimballe des tares, et dans la plupart des cas où je l'ai vu utilisé, un modèle threade aurait tres largement tenu la charge, tout en évitant la complexité de l'async.
Bref, c'est une techno qui a du bon, mais tres souvent utilisée dans des cas pas adapté du tout.