¿Por qué tardó tanto tiempo JavaScript en comenzar a usarse en el lado del servidor?

Lo siento, voy a nadar río arriba en este …

Node.js es una de las peores cosas que le sucedió a la industria del software en los últimos tiempos, a toda una generación de programadores se les está enseñando la peor de todas las formas de hacer concurrencia, en un sistema que no escala ni el rendimiento ni el tamaño del proyecto y con uno de los idiomas más plagados de dificultades jamás creadas.

JavaScript ya era lo suficientemente doloroso en el navegador, ¿por qué alguien pensó que era una buena idea usarlo en el servidor?

Pagaremos el precio de esta moda publicitaria equivocada en las próximas décadas.

De todas las formas de hacer concurrencia, las devoluciones de llamada son, con mucho, las peores, Twisted estaba plagado de ellas y es la razón principal por la que falló, y eso fue con un lenguaje mucho más sano y razonable como Python (Python sin pila era una alternativa mucho mejor) y usó un modelo similar al CSP de Go).

Y lo triste es que hay alternativas mucho mejores con muchos más modelos y entornos de sonido, C # (con ASP .NET), Erlang y Go son algunos ejemplos obvios, y eso es para las situaciones altamente especializadas donde tienes grandes necesidades de concurrencia , para cualquier otro problema, cualquier otra cosa será mucho mejor que Node.js, incluso PHP.

Porque hasta el motor Google V8 (y node.js), nadie había escrito un intérprete del lado del servidor lo suficientemente rápido como para usar Javascript del lado del servidor, donde la mayoría de las bibliotecas en ese momento estaban relacionadas principalmente con el navegador y el DOM.

Hoy, incluso ChakraCore de Microsoft quiere una parte de la acción competitiva de ser el enlace / intérprete del lado del servidor para Javascript.

¡La competencia es buena!

¡Y así comienza! Microsoft pide a Node.js que permita ChakraCore (Edge) junto con el motor V8 de Google