Ayer, se lanzó Deno 1.9. La nueva versión contiene muchas nuevas funciones nuevas y mejoras de rendimiento, además de numerosas correcciones de errores.
Si ya eres un usuario de Deno y lo tienes instalado, puede actualizar a la versión 1.9 de Deno ejecutando el comando deno upgrade.
Si vas a instalar Deno por primera vez, puede utilizar uno de los métodos que se enumeran a continuación:
# Usando el Shell (macOS and Linux):
curl -fsSL https://deno.land/x/install/install.sh | sh
# Usando PowerShell (Windows):
iwr https://deno.land/x/install/install.ps1 -useb | iex
# Usando Homebrew (macOS):
brew install deno
# Usando Scoop (Windows):
scoop install deno
# Usando Chocolatey (Windows):
choco install deno
? ? Conoce más sobre Chocolatey
Nuevas funciones y cambios en Deno
Algunos de los cambios más importantes, los vas a encontrar resumidos a continuación:
- Servidor web HTTP/2 nativo: Un servidor HTTP rápido, correcto y con todas las funciones en Deno.
- Llamadas más rápidas a Rust con serde_v8.
- Compatibilidad con URL de
bloby mejoras enfetch. - Importar finalizaciones en el LSP.
- Solicitud de permisos interactiva.
Servidor web HTTP/2 nativo
El servidor HTTP actual en Deno, std/http, se implementa en TypeScript puro sobre los sockets TCP.
El servidor tiene una latencia de cola sorprendentemente buena a pesar de usar un servidor HTTP basado en scripts.
Pero el principal inconveniente de std/http es que es solamente trabaja cn HTTP/ 1.1, sin una ruta fácil hacia HTTP/2.
En última instancia, el equipo de Deno, no se quiere centrar en el negocio de escribir servidores HTTP.
HTTP es cada vez más no trivial y ya existen servidores HTTP bien implementados en código nativo.
Por lo que se ha empleado la utilización de Hyper para optar a construir una nueva API de servidor HTTP/2 nativa sobre Deno.
Esto se traduce en una mejora importante del rendimiento. Hasta un 48% de mejora, con un simple Hola Mundo, en comparación con el servidor HTTP puro de TypeScript std/http.
Llamadas más rápidas a Rust con serde_v8
El equipo de Deno, se encuentra reconstruyendo la infraestructura de enlaces para que sea significativamente más simple y rápida.
Se han eliminado más de 1500 líneas netas de código del núcleo, mejorando la sobrecarga de líneas de enlaces de la base (operaciones AKA u opcalls) hasta en ~ 65x o -98%.
En versiones anteriores de Deno, las llamadas de operaciones seguían un patrón de solicitud / respuesta, codificando sus datos en “cargas útiles” personalizadas de ArrayBuffers.
Históricamente, estas cargas útiles usaban varias codificaciones, que iban desde JSON, búferes planos hasta codificaciones binarias personalizadas.
Eso generaba un cuello de botella en el rendimiento.
@AaronO sugirió al equipo de Deno, que en lugar de serializar hacia adelante y hacia atrás entre estos formatos binarios, JS y Rust, sería más eficiente serializar directamente entre los valores v8 y Rust.
Siguiendo esa idea y un prototipo rápido, nació serde_v8. serde_v8 tiene como objetivo proporcionar una bidirección “eficiente” y de “cero sobrecarga” entre los valores v8 y Rust sin dejar de ser expresivo y familiar (ya que se basa en la fantástica biblioteca serde de David Tolnay).
Compatibilidad con URL de blobs y mejoras en fetch
Se ha introducido soporte para blob (también conocido como objetos de URL) en la nueva versión de Deno 1.9.
La API para crear y revocar URL de blobs es la misma que en el navegador.
Las URL de blob se pueden usar para crear instancias fetch de Workers Web usando new Worker y en importaciones dinámicas (usando import()).
Importar terminaciones en el LSP
A Deno Language Server, la herramienta que impulsa las extensiones del editor para Deno, se le han agregado nuevas características y otras excelentes mejoras.
En primer lugar, se ha mejorado y reintroducido la función de finalización de importación de la extensión de VS Code.
Permitiendo a los usuarios obtener información completa en las declaraciones de importación.
El LSP ofrece finalizaciones para archivos locales, archivos ya descargados al caché DENO_DIR y también desde el registro.
Actualmente, https://deno.land/ x ofrece la función de autocompletar registros.
El registro Skypack ha mostrado interés y es probable que pronto sea compatible.
Esta versión también incluye muchas correcciones de errores para el LSP, y uno de los más destacados es un error molesto en los sistemas Windows que causó que el LSP entrara en pánico cuando se encontraba con la ruta file://URL.
Permitir listas para –allow-env y –allow-run
Varias de las marcas de permisos de Deno aceptan listas de permisos que hacen posible el alcance de los permisos del programa de forma granular.
Por ejemplo, --allow-read=/tmp concede permiso de lectura solo al directorio /tmp.
Antes de la versión 1.9, ambos --allow-env y --allow-run hacían lo mismo, lo que significaba que pasar una de las dos banderas otorgaba acceso completo a las variables y subprocesos para cualquier binario en el sistema, respectivamente.
Ahora, en Deno 1.9, se puede especificar exactamente a qué variables de entorno debe tener acceso el programa, o a qué subprocesos puede generar el programa:
$ deno run --allow-env=DEBUG,LOG https://deno.com/v1.9/env_permissions.ts
$ deno run --allow-run=deno https://deno.com/v1.9/run_permissions.ts
Además, ahora Deno.permissions.query() permite consultar permisos para ejecutar binarios específicos usando el comando:
await Deno.permissions.query({ name: "run", command: "deno" });
Solicitud de permisos interactiva
Actualmente en Deno, si ejecutas un programa al que le faltan los indicadores de los permisos apropiados, arrojará un error y te echará fuera.
En Deno 1.9, se está agregando la bandera --prompt que permite a los usuarios otorgar permisos de manera iterativa según se requieran durante el tiempo de ejecución.
El uso de --prompt es especialmente útil cuando se ejecutan scripts únicos desde Internet.
Puesto que no se necesita conocer todos los permisos requeridos por adelantado, en su lugar, puede ejecutar el script sin ningún permiso y otorgárselos o denegárselos a posteriori; según los solicite el programa.
Soporte ALPN enDeno.listenTls
El protocolo HTTP/2 es independiente de la conexión.
Esto significa que podría usarse en un socket Unix, un socket TCP o en una conexión usando TLS.
Los principales navegadores web solo permiten HTTP/2 sobre conexiones TLS que anuncian soporte para HTTP/2 durante el protocolo de enlace TLS.
Esto se hace a través de la extensión TLS “Negociación de protocolo de capa de aplicación” también conocida como ALPN.
Esta extensión del protocolo de enlace TLS permite que el servidor y el cliente TLS negocien qué protocolo de aplicación utilizarán para comunicarse en la conexión TLS.
En la web, los dos protocolos de aplicación dominantes son HTTP/1.1 y HTTP/2. Estos dos protocolos tienen los nombres de protocolo ALPN “http/1.1” y “h2” respectivamente.
Los navegadores solo enviarán solicitudes HTTP/2 a los servidores que les informa de la compatibilidad con HTTP/2 y si no se enumeran protocolos ALPN o solamente a “http/1.1”.
Hasta este punto, el servidor std/http solamente admitía HTTP/1.1 por lo que no era necesario admitir ALPN en las conexiones TLS.
Con la introducción de Deno.serveHttp en la nueva versión de Deno, eso cambió, para hacer posible HTTP/2 ahora se ha tenido que agregar soporte para la especificación de los protocolos ALPN capaces de anunciar cuando se inicia un oyente TLS con Deno.listenTls.
Nueva opción predeterminada de TypeScript useDefineForClassFields
En esta versión, hemos cambiado el Deno tsconfig predeterminado para incluir la opción "useDefineForClassFields": true.
Esta opción alinea el manejo de campo de clase de TypeScript con la semántica de script ECMA estándar. Esta opción no se puede sobrescribir en el código de usuario.
Ejemplos extendidos
Si quieres ver ejemplos más completos y extendidos sobre todos los nuevos cambios de Deno, no dudes en visitar el blog oficial de Deno. ?
Fuente: Blog Oficial de Deno