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
