loading...
Cover image for First look with deno (Spanish)

First look with deno (Spanish)

buttercubz profile image Erick Sosa Garcia ・3 min read

El pasado 13 de mayo fue liberada la version 1.0 de deno, un nuevo Runtime Environment para javascript y typescript creado en rust y usando v8 como motor de javascript.

pero ¿porque un nuevo entorno de ejecución para javascript?. bien ya tenemos un entorno de ejecución para javascript fuera del navegador que es node js creado por Ryan Dahl en 2009, pero este se creo sin tomar en cuenta la evolución que javascript como lenguaje iba a tener en los siguientes años.

Node js

Node js esta creado en C++ y utiliza como librería para manejar código asíncrono libuv pero en un inicio este no tenia un manejador de paquetes ni formas de importar modulos "require, import", otro problema que no solo node js posee sino que otros lenguajes interpretados tienen, es el manejo y acceso a recurso de sistema convirtiéndolos en entornos menos seguros que otros, no existía async await promesas ni otros recursos que hoy día son comunes en el lenguaje, Claro hoy tenemos NPM y require pero estos fueron introducidos en una arquitectura que no lo tenia previsto.

El problema llamado npm

todo aquel que a programado javascript con node seguro a trabajado con el directorio node_modules donde se almacenan las dependencias y librerías de desarrollo pero el problema que que npm es una empresa externa a node y esta centralizada cuando Internet y el software tiene como pauta ser descentralizado, ademas puede pasar que descargas una librería para manejar archivos del sistema y esta utiliza otras mas pequeñas, puede pasar que un script de código dentro de una de estas librerías tenga algún fin malicioso.

otro problema de npm es el llamado Dependency Hell que es la compleja dependencia de librerías unas de otras, en este post se explica mejor. pero el Dependency Hell no es un problema de node sino de npm, claro pero al npm ser una herramienta indispensable para desarrollar con node le afecta en que tenemos un directorio que dependiendo la complejidad y la cantidad de módulos y librerías puede alcanzar muchos espacio en el disco.

Dependency Hell

la imagen anterior es una representación de las dependencias de gatsby donde cada nodo representa una librería y sus uniones. link de la herramienta.

deno

ahora bien deno viene a resolver muchos problemas de node js, pero quien lidera este proyecto no es cualquiera es el mismo creador de node js Ryan Dahl ya que el es consiente de los problemas de node, pero node es un proyecto ya estable por lo que decidió empezar desde cero.

lo interesante de deno es que solo tiene aproximadamente 2 años de desarrollo, que esta escrito en rust el lenguaje de Mozilla y que no usa libuv sino tokio para manejar el código asíncrono. otras cosas interesantes es que también puede ejecutar typescript ya que viene con el compilador, tiene un fuerte énfasis en la seguridad para el manejo de recursos ya que debemos explicita mente dar acceso a los recursos como leer y escribir archivos o a la red usando las banderas " --allow-net, --allow-read y --allow-write " todo esto con un enfoque moderno ya que no soporta promesas de manera nativa sino que utiliza async await para los eventos asíncronos. no tiene node_modules, npm ni require ya que las dependencias se manejan mediante link o vínculos muy similar a GO y en remplazo de require esta import de ES6, las librerías son supervisadas por el equipo de desarrollo de deno por lo que amplia la seguridad. otra característica de deno es el toplevel await, que quiere decir esto, que la función principal que corre todo el código en el callstack ya tiene declarado async.

Este es un post que consta de dos partes esta es la primera parte, en el siguiente veremos código con deno. estará en este enlace.

Posted on by:

buttercubz profile

Erick Sosa Garcia

@buttercubz

Hello I'm Erick I study Javascript, typescript, python, go, Node js and focused in deno 🦕 Creator of Trex package manager https://deno.land/x/trex

Discussion

markdown guide