Hace unos a?os, observamos una sobrecarga de Node : Node.js se utilizaba a menudo por razones cuestionables o sin tener en cuenta otra alternativa. Aunque entendemos que algunos equipos prefieren un stack de un solo lenguaje, a pesar de las desventajas, seguimos defendiendo la programaci¨®n pol¨ªglota. En aquel momento, se?alamos que Node.js ten¨ªa una merecida reputaci¨®n de eficiencia en cargas de trabajo con uso intensivo de E/S, pero mencionamos que otros frameworks se hab¨ªan puesto al d¨ªa y ofrec¨ªan mejores APIs y un rendimiento general superior. Tambi¨¦n advertimos que Node.js nunca fue adecuado para cargas de trabajo de c¨®mputo intensivo, una limitaci¨®n que sigue siendo un desaf¨ªo significativo. Ahora, con el auge de las cargas de trabajo con uso intensivo de datos, tambi¨¦n vemos a los equipos tener dificultades con estas.
Las tecnolog¨ªas, especialmente las ampliamente populares, tienen tendencia a ser sobreutilizadas. Lo que estamos viendo en este momento es un uso excesivo de Node , una tendencia a usar Node.js indiscriminadamente o por razones equivocadas. Entre ellas, en nuestra opini¨®n destacan dos. La primera, escuchamos con frecuencia que se debe usar Node.js para que todo el c¨®digo pueda ser escrito en el mismo lenguaje de programaci¨®n. Nuestra visi¨®n sigue siendo que la programaci¨®n pol¨ªglota es una mejor aproximaci¨®n, y esto funciona en ambos sentidos. La segunda, en ocasiones escuchamos a equipos citar el rendimiento como raz¨®n para elegir Node.js. Aunque hay infinidad de pruebas comparativas m¨¢s o menos razonables, esta percepci¨®n radica en la historia. Cuando Node.js se hizo popular, fue el principal framework en adoptar el modelo de programaci¨®n no bloqueante y esto le permiti¨® ser muy eficiente en tareas con alta carga de E/S (ya lo mencionamos cuando escribimos sobre Node.js en 2012), pero puesto que ahora los frameworks con capacidades no bloqueantes ¡ª algunos con modernas y elegantes APIs ¡ª existen en otras plataformas, el rendimiento ya no es una raz¨®n para elegir Node.js
Las tecnolog¨ªas, especialmente las ampliamente populares, tienen tendencia a ser sobreutilizadas. Lo que estamos viendo en este momento es un uso excesivo de Node , una tendencia a usar Node.js indiscriminadamente o por razones equivocadas. Entre ellas, en nuestra opini¨®n destacan dos. La primera, escuchamos con frecuencia que se debe usar Node para que todo el c¨®digo pueda ser escrito en el mismo lenguaje de programaci¨®n. Nuestra visi¨®n sigue siendo que la programaci¨®n pol¨ªglota es una mejor aproximaci¨®n, y esto funciona en ambos sentidos. La segunda, en ocasiones escuchamos a equipos citar el rendimiento como raz¨®n para elegir Node.js. Aunque hay infinidad de pruebas comparativas m¨¢s o menos razonables, esta percepci¨®n radica en la historia. Cuando Node.js se hizo popular, fue el principal framework en adoptar el modelo de programaci¨®n no bloqueante y esto le permiti¨® ser muy eficiente en tareas con alta carga de E/S (ya lo mencionamos cuando escribimos sobre Node.js en 2012), pero puesto que ahora los frameworks con capacidades no bloqueantes ¡ª algunos con modernas y elegantes APIs ¡ª existen en otras plataformas, el rendimiento ya no es una raz¨®n para elegir Node.js
