Deno

El entorno de desarrollo de Deno y Deno mismo son rudimentarios, no deberían usarse en un entorno de producción.
Considerando el tiempo de desarrollo de Deno, el equipo de Deno ha tenido un rendimiento deficiente,
hasta el punto de que Node.js ha ido alcanzando gradualmente las características de Deno, y han surgido competidores en el mismo nicho como Bun.
Es difícil tener confianza en el futuro de Deno.
  • Desarrollado con Rust.
  • La API es lo más compatible posible con el entorno web.
  • Cuenta con deno fmt, deno lint, deno test, deno bench con una opinión fuerte.
  • Seguro por defecto, con un sistema de permisos de grano fino que soporta la solicitud dinámica de permisos.
    Actualmente, debido a que Deno tiene muchos campos de uso interno, los permisos de grano fino pueden ser muy inconvenientes de usar, y al final uno se verá forzado a usar permisos de grano grueso.
  • Soporte nativo para TypeScript, lo cual es cada vez más importante a medida que la comunidad JavaScript transita hacia TypeScript.
  • Compatibilidad con Node.js.
Las funcionalidades integradas de Deno generalmente carecen de pruebas rigurosas, dependiendo de la comunidad para reportar errores.
Aunque las LTS muestran una tendencia a acortarse en varios proyectos, el hecho de que Deno 2 declarara 6 meses como LTS en su lanzamiento sigue siendo risible.
Deno Land Inc. se dedica al desarrollo de clones/alternativas de otros productos del ecosistema.
Estos productos carecen claramente de una consideración profunda y su mantenibilidad es cuestionable.
Esta tendencia también ha afectado a Deno mismo, por ejemplo, la compatibilidad con Node.js es un ejemplo típico de cómo el bombo de marketing prevalece sobre la entrega real:
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
Cuelgues frecuentes, picos de CPU en LSP · Issue #943 · denoland/vscode_deno
Proyectos de Deno con un tamaño considerable ralentizarán la respuesta del LSP, lo que fácilmente desanima a los desarrolladores que quieren usar Deno.
En contraste, los proyectos basados en Node.js y TypeScript no tienen problemas similares en absoluto.
La configuración predeterminada del LSP de Deno es bastante conservadora; por ejemplo, el valor predeterminado de documentPreloadLimit es 1000, lo cual es fácilmente superado en el desarrollo real.
El diseño del modelo de streams WHATWG es bastante rudimentario, muy inferior a los streams de Node.js.
Por ejemplo, el usuario ni siquiera puede saber si un stream se ha cerrado o cuándo se ha cerrado.
Los módulos determinarán su protocolo según cómo se importen.
Cuando un módulo se importa como un módulo local, el import.meta.url del módulo tendrá el protocolo `file`.
Cuando un módulo se importa como un módulo remoto, su import.meta.url tendrá el protocolo `http`/`https`.
El problema es que un número considerable de APIs solo soportan un protocolo; por ejemplo, Deno.readFile solo soporta el protocolo `file`, no `http`/`https`.
Esta situación aumenta la carga cognitiva del desarrollador al usar import.meta.url.
El problema fundamental radica en que Deno no expone la ruta local del módulo importado (caché), lo cual es un problema que podría resolverse a nivel de diseño.
https://github.com/denoland/deno/issues/5987
Es bastante lamentable que Deno resuelva los problemas relacionados con la lectura de archivos haciendo que la función `fetch` soporte el protocolo `file`.
https://github.com/denoland/deno/issues/3196
TypeScript no soporta la compilación de rutas de módulos con extensión .ts a extensión .js,
mientras que las rutas de módulos de Deno siempre tienen la extensión .ts.
Por lo tanto, el código de proyectos TypeScript diseñados para módulos de Node.js no funcionará en Deno.
TypeScript 5 comenzó a soportar la opción de configuración `allowImportingTsExtensions`, lo que permite usar la extensión .ts en un proyecto,
pero esta opción está restringida a ser usada solo cuando la configuración es `noEmit` o `emitDeclarationOnly`,
lo que significa que usar la extensión .ts no permite generar código utilizable para Node.js.
El registro de paquetes de JavaScript impulsado oficialmente por Deno.
Aunque JSR se promociona como un registro de paquetes de JavaScript moderno, sigue siendo solo la versión de npm de Deno.
JSR no es un superconjunto de npm, al igual que TypeScript no es un superconjunto de JavaScript.
Este registro es en gran medida una solución a los problemas de gestión de dependencias existentes en Deno (el boomerang lanzado por Ryan Dahl en 2018 finalmente le golpea):
Diferentes módulos importarán dependencias de diferentes registros, o importarán diferentes subversiones de dependencias del mismo registro debido a la falta de SemVer.
Esto lleva a la inflación del tamaño del proyecto (lo que aumentará la carga del LSP) y a la falta de igualdad referencial entre las dependencias importadas.
La oficina de Deno afirma que el registro de paquetes original deno.land/x seguirá siendo utilizable,
pero considerando que la biblioteca estándar oficial `std` en deno.land/x ya está descontinuada, no tiene sentido esperar seguir publicando paquetes en deno.land/x.
Ahora se puede usar (como el soporte para módulos npm añadido en Deno 1.28) el prefijo dedicado jsr:, lo que simplifica la URL.
https://github.com/oakserver/oak
https://fresh.deno.dev/
El framework web full-stack lanzado oficialmente por Deno en 2022, que rivaliza con Next.js.
No se recomienda usarlo, porque:
  • Casi ninguna librería de React está probada para soportar Deno.
  • Internamente utiliza Preact, una variante ligera de React, lo cual es una ruta tecnológica sin futuro.
Deno puede importar JSDOM a través de CDN.
import { JSDOM } from 'https://esm.sh/jsdom@22.1.0'
https://github.com/b-fuze/deno-dom
Este proyecto es un binding del paquete `html5ever` de Rust.
SQLite usando Deno FFI.
Ventajas:
  • La interfaz es básicamente la misma que `better-sqlite3`.
  • Alto rendimiento.
SQLite compilado a WASM.
Ventajas:
  • Permisos mínimos.
  • Multiplataforma.
Desventajas:
  • Limitado por la API del sistema de archivos de Deno.
  • Muy pocas opciones de compilación están habilitadas por defecto, es muy probable que necesites compilarlo tú mismo.
Desde Deno 1.21, la biblioteca estándar ha proporcionado una cantidad considerable de funciones de prueba,
lo que permite realizar la mayoría de las pruebas sin necesidad de utilizar bibliotecas de terceros.
Esta elección tecnológica de Deno evita eficazmente el problema de vinculación con el proveedor en las pruebas de Node.js.
La biblioteca estándar actual ya soporta estilo BDD, mock/stub, comparación de instantáneas, simulación de temporizadores:
https://deno.land/std@0.181.0/testing
https://github.com/denoland/deno_std/issues/1779
Deno proporciona un comando integrado deno bundle para empaquetar un proyecto en un solo archivo de script.
Ryan Dahl propuso eliminar este comando, pero esta idea fue posteriormente retirada.
Sin embargo, en v1.31, este comando fue marcado como obsoleto sin ninguna discusión comunitaria, y el manual oficial recomendaba usar esbuild en su lugar.
En v2.4, deno bundle regresó inexplicablemente, utilizando esbuild internamente.
En v2.5, se añadió soporte para usar archivos HTML como punto de entrada para el empaquetado.
Al ejecutar un script con el comando deno run, se carga el verificador de tipos de TypeScript, lo que hace que el proceso de Deno use más memoria.
Si el script se compila primero con deno compile y luego se ejecuta, el uso de memoria del script mejorará notablemente.