¿Qué es Deno y en qué se diferencia este proyecto de Node.js?

Ryan Dahl, creador de Node.js, ha pasado el último año y medio trabajando en el proyecto Deno . Este es el nuevo tiempo de ejecución de JavaScript que debería solucionar los problemas inherentes a Node.js.

No me malinterpretes. La plataforma Node.js es un excelente entorno del lado del servidor para ejecutar JavaScript. Debe su popularidad principalmente a un gran ecosistema y, de hecho, es compatible con JavaScript. Sin embargo, Ryan Dahl admite que algo sobre Node.js debería valer su atención. Esto, en particular, se trata de seguridad, de módulos y de gestión de dependencias.


En su defensa, se podría decir que no podría saber qué tan popular se volvería la plataforma Node.js en un período de tiempo bastante corto. Además, en 2009, JavaScript todavía parecía un lenguaje limitado y extraño, que se burló de todos los que no eran flojos. También debe tenerse en cuenta que en aquellos días muchas de las características de JavaScript que son comunes en estos días no existían.

¿Qué es Deno y cuáles son las principales características de esta plataforma?

Deno es un tiempo de ejecución seguro de TypeScript construido sobre el motor V8 JS desarrollado por Google. La plataforma Deno se creó con las siguientes herramientas:

• Rust (el núcleo Deno está escrito en Rust y el núcleo Node está en C ++).
• Tokio (bucle de eventos escrito en Rust).
• TypeScript (Deno, sin configuraciones adicionales, admite JavaScript y TypeScript).
• V8 (el motor JS de Google utilizado en el navegador Chrome, Node.js y otros proyectos).

Hablemos de las oportunidades que nos ofrece la plataforma Deno.

Seguridad (permisos)

Entre las características más importantes de Deno, que reciben atención especial, se puede observar la seguridad.

A diferencia de Node, Deno, por defecto, ejecuta código en un sandbox. Esto significa que el tiempo de ejecución no tiene acceso a las siguientes entidades y capacidades:

• Sistema de archivos.
• Red.
• Ejecución de otros scripts.
• Variables de entorno.

Eche un vistazo a cómo funciona el sistema de permisos de Deno. Considere el siguiente script:

(async () => {  const encoder = new TextEncoder();  const data = encoder.encode('Hello world\n');  await Deno.writeFile('hello.txt', data);  await Deno.writeFile('hello2.txt', data); })(); 

Este script crea un par de archivos de texto: hello.txt y hello2.txt . El texto Hello world coloca en estos archivos. El código se ejecuta en el sandbox. Por lo tanto, no tiene acceso al sistema de archivos.

Además, preste atención al hecho de que aquí usamos el espacio de nombres Deno , en lugar de referirnos a algo como el módulo fs , como lo haríamos en Node. El espacio de nombres Deno proporciona al desarrollador muchas funciones básicas de ayuda. Pero nosotros, usando el espacio de nombres, perdemos compatibilidad de código con el navegador. Hablaremos de esto a continuación.

Este script se puede ejecutar con el siguiente comando:

 deno run write-hello.ts 

Después de eso, veremos una notificación con el siguiente contenido:

 Deno requests write access to "/Users/user/folder/hello.txt". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)] 

De hecho, bien podemos ver esto dos veces durante cada una de las llamadas. Por supuesto, si respondemos la pregunta del sistema seleccionando la opción allow always , la segunda vez no recibiremos esta notificación.

Si elegimos una de las opciones de PermissionDenied se generará un error PermissionDenied . El proceso de script se completará, ya que no hay código para manejar errores en él.

El script se puede ejecutar así:

 deno run --allow-write write-hello.ts 

No veremos ninguna notificación; se crearán ambos archivos.

Además del --allow-write , que afecta el trabajo con el sistema de archivos, puede usar otros indicadores al ejecutar scripts. Estos son --allow-net , --allow-env y --allow-run . Abren respectivamente el acceso de script a la red, al entorno y al lanzamiento de subprocesos.

Módulos

Deno, como los navegadores, carga los módulos por URL. Al principio, muchas personas están confundidas por lo que ven en los comandos de importación del código del servidor con URL. Pero esto, de hecho, tiene sentido. Espera un poco, y lo entenderás tú mismo.

 import { assertEquals } from "https://deno.land/std/testing/asserts.ts"; 

Aquí puede tener una pregunta sobre qué tiene de especial importar paquetes por URL. La respuesta a esta pregunta es simple: mediante el uso de URL, los paquetes de Deno se pueden distribuir sin usar un registro central como npm. Npm ha tenido muchos problemas últimamente.

La organización de la importación de código a través de URL permite a los creadores de paquetes alojar su código donde lo consideren conveniente. Esto es descentralización en todo su esplendor. No más package.json y node_modules .

Cuando iniciamos la aplicación, Deno carga todos los módulos importados y los almacena en caché. Una vez que se almacenan en caché, Deno no los volverá a cargar a menos que solicitemos explícitamente que se --reload utilizando el indicador --reload

Con respecto a este sistema de trabajo con módulos, se pueden hacer varias preguntas importantes.

¿Qué sucede si el recurso en el que se encuentra el código del módulo es inaccesible?

El código del módulo no se almacena en un registro centralizado. El recurso web que aloja este código puede no estar disponible por muchas razones. Durante el proceso de desarrollo, o peor aún, llevar el proyecto a producción, es arriesgado esperar que el alojamiento del módulo siempre esté disponible.

Como ya se mencionó, Deno almacena en caché los módulos cargados. Dado que el caché se almacena en un disco local, el creador de Deno recomienda procesarlo utilizando el sistema de control de versiones (es decir, git) e incluirlo en el repositorio del proyecto. Con este enfoque, incluso cuando el recurso en el que se almacena el código es inaccesible, todos los desarrolladores de proyectos conservarán el acceso a las versiones descargadas de los módulos.

Deno almacena el caché en la carpeta especificada por la variable de entorno $DENO_DIR . Si no configuramos esta variable, Deno almacenará el caché en el directorio estándar del sistema para cachés. La $DENO_DIR se puede configurar para que apunte a alguna carpeta en nuestro repositorio local. Esta carpeta puede procesarse utilizando su sistema de control de versiones.

▍ ¿Necesito importar constantemente módulos por URL?

Introducir URL largas regularmente puede aburrirse rápidamente. Afortunadamente, Deno nos ofrece dos formas de facilitar esta tarea.

La primera forma es usar la capacidad de reexportar el módulo importado desde el archivo local. Por ejemplo, podría verse así:

 export { test, assertEquals } from "https://deno.land/std/testing/mod.ts"; 

Supongamos que el archivo en el que se encuentra el comando anterior se llama local-test-utils.ts . Ahora, si necesitamos volver a test o assertEqual funciones assertEqual , podemos importarlas así:

 import { test, assertEquals } from './local-test-utils.ts'; 

Como resultado, resulta que no importa si el módulo fue cargado por URL o no.

La segunda opción es crear un mapa de importación en forma de un archivo JSON:

 {   "imports": {      "http/": "https://deno.land/std/http/"   } } 

Cuando se utiliza un archivo similar, el comando de importación puede verse así:

 import { serve } from "http/server.ts"; 

Para que este esquema funcione, debe informar al sistema sobre el uso del mapa de --importmap en el proyecto, utilizando el indicador --importmap cuando se ejecuta el script:

 deno run --importmap=import_map.json hello_server.ts 

▍¿Cómo se gestiona el control de versiones del módulo?

El control de la versión del paquete es su responsabilidad. Desde el punto de vista del cliente, elegir la versión de paquete correcta parece agregarlo a la URL:
https://unpkg.com/liltest@0.0.5/dist/liltest.js .

Compatibilidad del navegador

La plataforma Deno se esfuerza por la compatibilidad de su código con los navegadores. Desde un punto de vista técnico, cuando usamos módulos ES, no estamos obligados a usar algunas herramientas de ensamblaje, como webpack, que proporcionan la capacidad de ejecutar la aplicación en un navegador.

Sin embargo, herramientas como Babel convierten el código JS moderno a código compatible con ES5. Como resultado, este código puede ejecutarse incluso en navegadores no más nuevos que no admiten capacidades modernas de JavaScript. Pero este enfoque también tiene un signo negativo, que consiste en el hecho de que los paquetes de proyectos web crecen debido al hecho de que obtienen mucho código auxiliar.

En realidad, tomamos decisiones sobre los objetivos de nuestros proyectos. Elegimos las herramientas adecuadas.

Soporte de TypeScript

Deno simplifica el uso de TypeScript, eliminando la necesidad de que los desarrolladores configuren cualquier cosa para ejecutar el código TS. Pero los programas Deno también se pueden escribir en JavaScript sin problemas.

Resumen

Deno, el nuevo entorno de tiempo de ejecución para TypeScript y JavaScript, es un proyecto interesante que ha estado demostrando sostenibilidad por algún tiempo. Sin embargo, antes de que pueda considerarse listo para la producción, todavía tiene un largo camino por recorrer.

El enfoque descentralizado para trabajar con módulos implementados en Deno tiene como objetivo liberar el ecosistema de JavaScript de un repositorio de paquetes centralizado, que hoy es npm.

Ryan Dahl dice que espera lanzar Deno 1.0 a fines del verano. Si está interesado en el futuro de este proyecto, preste atención a su repositorio .

Estimados lectores! ¿Qué opinas de Deno?