A estas alturas, pocos se atreven a discutir que el 27 de mayo de 2009 marcó un antes y un después en el mundo de la programación. De la mano de Ryan Dahl, aparecía en nuestras vidas (y nuestros ordenadores) Node.js. En pocas palabras: javascript en el servidor, un entorno en tiempo de ejecución multiplataforma, basado en la programación asíncrona y con unos rendimientos muy superiores a lo que estábamos acostumbrados por aquel entonces.
Nadie podría sospechar que 9 años después, durante una charla de Ryan llamada «10 things I regret about Node.js”, nos sorprendería con el anuncio de un nuevo runtime multiplataforma basado en el motor V8 de Chrome y construido con Rust: DENO.
Un sistema que llega con la madurez de su predecesor, Node.js, y que siempre había estado en la cabeza de su creador, consciente de las limitaciones del primero.
Pero, ¿qué podemos destacar de DENO?
Cómo os contaba, se trata de un runtime seguro multiplataforma basado en el motor V8 de Chrome, que soporta Javascript y Typescript de serie. Recordad que con Node.js, hay que instalar el paquete de Typescript. Aquí encontramos la primera ventaja.
Por otro lado, y adentrándonos en el «mundo» de los módulos, DENO pretende ser totalmente compatible con los navegadores. ¿Cómo lo hace? Cargando los módulos por URL; de esta manera, los creadores pueden alojar su código en cualquier lugar. Así, cuando se inicia una aplicación, DENO almacena todos los módulos importados en la caché; no descargándolos nuevamente hasta que no se lo solicitemos. Segunda ventaja.
Vayamos un poco más allá… buscando ventajas dentro de las ventajas, esto nos permite, por ejemplo, levantar más rápidamente una nueva instancia en un Software as a Service (SaaS).
En tercer lugar, hay que destacar uno de los aspectos que más le preocupaban a Ryan: la seguridad. Y es que desde un primer momento se ha convertido en un objetivo prioritario, gracias al cual, nos encontramos con una de las grandes mejoras con respecto a NodeJs: todos los programas de DENO se ejecutan en su propio entorno aislado, por lo que, de manera predeterminada, DENO no permitirá que un programa acceda al sistema de archivos, la red, a la ejecución de otros scripts y/o a las variables de entorno.
Además, DENO, a diferencia de Node, siempre muere por errores no detectados. Así se evita que la ejecución continúe provocando resultados no previsibles.
En definitiva… ¿estamos ante el sucesor de Node? Según su propio creador, no. Pero lo que si es cierto es que aún quedan muchas versiones por ver y que es muy probable que se convierta en una opción más que viable para construir grandes proyectos.
