- Recientemente han surgido críticas y preocupaciones sobre el impulso de Deno Deploy, KV, Fresh, y de la empresa y los proyectos en general
- Parte de las críticas son válidas, y el hecho de no haber compartido suficientemente el progreso por cuenta propia también contribuyó a aumentar la confusión, pero gran parte de estos rumores y críticas son especulación sin fundamento o afirmaciones incorrectas
- Desde el lanzamiento de Deno 2 (después de octubre de 2023), la adopción se ha más que duplicado según la métrica de usuarios activos mensuales
- La fuerte compatibilidad con Node de Deno 2 eliminó un gran obstáculo para su adopción real, y la plataforma se ha vuelto más rápida, más potente y más simple
Cambios y evolución de Deno Deploy
- Una de las preguntas más frecuentes es por qué recientemente se redujo la cantidad de regiones disponibles en Deno Deploy
- Detrás de esta reducción no solo están los costos, sino también los cambios en los patrones y necesidades reales de uso
- Para la mayoría de las apps, más que todas las regiones, lo importante es la velocidad, la depuración y el cumplimiento en regiones cercanas a los datos
- Desde el lanzamiento de Deploy, pasó de 25 a 35 y ahora a 6 regiones
- Muchas regiones prácticamente no se usaban, y una dispersión excesiva provocaba una caída del rendimiento (latencia, problemas de capacidad)
- Se está reconstruyendo una visión práctica de “edge” que responda a las necesidades reales de los usuarios
- Se está desarrollando una nueva versión de Deploy, y la plataforma está evolucionando hacia el hosting de aplicaciones completas
- Se planea soportar subprocesos, trabajos en segundo plano, OpenTelemetry, pipelines de build, regiones autohospedadas, etc.
- Próximamente se ofrecerán funciones para fijar apps a regiones específicas o ejecutarlas en la propia nube del usuario
Dirección de KV (almacén clave-valor)
- Deno KV es un almacén con una API simple que ofrece consistencia global garantizada y funciones en tiempo real, sin necesidad de configuración
- Es adecuado para datos de sesión, feature flags y estado colaborativo, pero no está pensado como base de datos de propósito general
- Para necesidades más amplias de gestión de datos, se están llevando adelante dos iniciativas
- Reforzar la integración de las bases de datos relacionales existentes dentro de Deno Deploy
- Impulsar un nuevo proyecto que simplifique la vinculación entre cómputo y estado (inspirado en Cloudflare Durable Objects)
- En línea con esa dirección, KV seguirá en beta, con atención continua solo a errores críticos y problemas de seguridad
- Se espera que otro proyecto asuma en adelante el papel central o una función evolucionada dentro de la solución integral de gestión de estado
Estado del framework Fresh
- Fresh sigue siendo la base de todas las apps y webs internas, y continúa manteniéndose y mejorándose activamente
- Son conscientes de la alta expectativa y la larga espera en torno a Fresh 2
- En lugar de lanzarlo apresuradamente, priorizan pulir la calidad y la estructura base
- Vale la pena consultar la publicación del blog sobre los detalles de las mejoras anunciadas recientemente
- Está previsto desplegar una versión estable de Fresh 2 durante este año
Deno, una plataforma más allá del runtime
- Deno es más que un runtime: es una plataforma de sistema completa para JavaScript
- Con un solo conjunto de herramientas es posible integrar escritura, ejecución, pruebas, despliegue y monitoreo
- Se sigue reforzando la integración, la configuración por defecto, los flags y la conexión entre herramientas
- El objetivo no es una simple equivalencia de funciones, sino construir un ecosistema integrado
- Se apunta a una mejora esencial en la calidad del desarrollo en JavaScript, y se está ampliando el alcance para lograrlo
Objetivo y razón de ser de esta plataforma
- Los lenguajes de scripting cumplen un papel indispensable en el desarrollo práctico y rápido
- JavaScript tiene un futuro aún más prometedor en términos de estandarización, gran ecosistema y escalabilidad de propósito general
- Se necesita una plataforma “con baterías incluidas”, y Deno apunta a eso (gestión de permisos, servidor web, observabilidad, lint, verificación de tipos, etc. incluidos por defecto)
- Ofrece una experiencia unificada en lugar de herramientas fragmentadas
Planes futuros y refuerzo de la comunicación
- Deno no está en retroceso, sino entrando en una fase de expansión
- Se sigue mejorando la velocidad, compatibilidad y madurez de la plataforma, y la gobernanza independiente de JSR también está creciendo
- También avanzan en colaboración comunitaria como TC39/WinterTC y en diversas actividades para el ecosistema de JavaScript
- A partir de la experiencia con Deploy y KV, se continúa desarrollando nuevos productos sostenibles y distribuidos, y pronto se revelarán más novedades
- Para reducir controversias o desconfianza, se fortalecerá la comunicación y se priorizará la confianza con los desarrolladores
3 comentarios
¿Entonces Bun es mejor que Deno?
Los rumores sobre el declive de Deno están muy exagerados
Parece que es una respuesta a esa publicación.
También publicaron por separado una explicación de por qué la actualización de Fresh se está retrasando: Actualización a Fresh 2, el framework web de Deno
Opiniones en Hacker News
Da la impresión de que desde el principio era evidente que la mayoría de los desarrolladores no despliegan solo funciones stateless simples, sino que normalmente construyen aplicaciones reales que se comunican con bases de datos, como las apps full-stack. Resulta hasta un poco obvio que apenas ahora se hayan dado cuenta de eso
Se comparte la percepción de que recientemente ha habido críticas hacia Deno, Deploy, KV, Fresh y su trayectoria de crecimiento en general. Sobre las críticas al crecimiento, no se ha visto una mención o respuesta específica, y queda la duda de si fue intencional. Ya que se dijo que algunas críticas eran válidas, habría generado más confianza que también se hiciera público cuáles eran y cómo piensan resolverlas. Ver a una empresa reconocer con honestidad incluso sus desventajas puede ser un punto a favor al momento de elegirla. Se comparte una buena experiencia con páginas como la de pros/contras de Migadu, donde se muestran ventajas y desventajas con transparencia
Al principio, la razón para entusiasmarse con Deno era que no estaba obsesionado con la compatibilidad con lo existente y podía empezar de nuevo de forma limpia y con menos complejidad. Tenía algunas incomodidades nuevas frente a Node, pero parecían manejables. Sin embargo, en vez de mantener soluciones propias, empezó a aferrarse cada vez más a la compatibilidad con Node, y ahora se siente como una estructura dual incluso más compleja que Node. Está bien que los paquetes de Node funcionen naturalmente en Deno, pero hay muchos casos límite donde no funcionan por APIs aún no implementadas o por bugs. AVA, que era el framework de testing favorito de quien comenta, sigue sin estar soportado. Antes se podía ignorar la capa de compatibilidad con npm y usar solo Deno, pero ahora eso cada vez se vuelve más molesto. Basta ver las opciones de línea de comandos: en pocos años se volvieron muchísimo más complejas, y como la mayoría existen para integrarse con npm, para esta persona son solo información innecesaria. Lo que más quería de la compatibilidad con Node era soporte para configuración de ESLint en el linter de Deno, pero no parece haber interés en eso. Aun así, desea que Deno tenga éxito porque empuja mejoras en Node. Pero siente que la dirección actual de Deno ya no es consistente con su propósito original
Se siente que Deno perdió su rumbo. Al principio tenía un posicionamiento simple: un runtime de JS/TS seguro y rápido hecho en Rust. Ahora, en el menú desplegable de “Products” de su sitio web, se añadieron varios productos de forma desordenada. Parece que intentó seguir el camino de Vercel, que después de NextJS construyó una plataforma de deploy
La expectativa por Deno desapareció desde el momento en que añadió compatibilidad con Node y abandonó su promesa inicial. Para esta persona, el principal atractivo de Deno era haber eliminado complejidades no deseadas y herencia del pasado de Node, pero ahora ya no se diferencia de Node salvo por algunas pequeñas diferencias como TypeScript integrado y permisos. bun.sh también ofrece compatibilidad con Node. Se pregunta si alguien conoce un motor de scripting TypeScript del lado del servidor que no busque compatibilidad con Node
La compatibilidad con npm es una adición de funcionalidad, así que no se siente como una pérdida. No es necesario usar APIs de Node, y basta con usar las librerías deseadas desde jsr.io. En la práctica, se sostiene que todavía puede disfrutarse en Deno una experiencia de desarrollo distinta a Node. Aun así, no hay tanta gente que quiera una “pureza” total, así que es preferible que haya optado por popularidad y pragmatismo
Se cuestiona por qué se busca un runtime de TypeScript que no persiga compatibilidad con Node. Node tiene varios problemas, pero aun así es lo bastante utilizable como para ser adoptado masivamente. Para crear una alternativa práctica hace falta (1) una ventaja suficientemente fuerte como para justificar una migración grande, o (2) al menos un costo de migración mínimo y mejoras claras en rendimiento, confiabilidad o usabilidad. Pero Deno quedó a medias en ambos puntos. No puede ejecutar código Node existente, pero tampoco ofrece ventajas lo bastante innovadoras, por lo que se considera un enfoque limitado que solo atrae a “idealistas” o desarrolladores aficionados
Como runtime de TypeScript que no persigue compatibilidad con Node, viene a la mente workerd de Cloudflare Workers, pero en esencia no es un runtime backend de propósito general y tiene la limitación de que prácticamente no ofrece paquetes básicos ni funciones integradas
Esta persona prefiere usar JSDoc. Tiene ventajas parecidas sin relación con Node y sin la complejidad de una cadena de compilación
Si en el backend no hace falta aferrarse a JS, se considera razonable evaluar alternativas mejores que TypeScript. Si se puede controlar todo el stack, no hay necesidad de quedarse en un lenguaje compile-to-JS
Se piensa que el artículo reciente probablemente sea una reacción a https://news.ycombinator.com/item?id=43863937
Aunque es un texto escrito por el CEO, se enfoca más en justificar decisiones internas que en responder críticas concretas sobre Deno. Aun así, da la impresión de que la familia de productos de Deno funciona bastante bien dentro del entorno de Deno
Todavía no inspira confianza ni convicción. Pronto se podrá ver cómo termina saliendo Deploy, pero si no hay intención de seguir desarrollando KV más allá de la beta, se piensa que no hay ninguna razón para usarlo en proyectos nuevos. Fresh supuestamente será refactorizado a alpha hacia finales de Q3, pero en realidad era un framework que prácticamente solo ofrecía lo básico, y hasta su estructura llamativa sin build/compilación parece desaparecer. El runtime sigue en desarrollo, pero resulta curioso que, pese a la declaración de que “no busca paridad funcional con otros runtimes”, las release notes se centren en compatibilidad con Node/NPM
Se considera una muy mala decisión detener el desarrollo continuo de KV. Se señala que las empresas no evitan KV porque sus funciones sean malas, sino por la etiqueta de beta. Esta persona ha usado bastante Cloudflare Workers KV y no le interesan mucho los Durable Objects, así que tenía expectativas sobre Deno KV, pero ahora parece que habrá que descartarlo. También se evalúa muy mal, a nivel estratégico, la impresión de anunciar un producto nuevo y luego abandonarlo de inmediato
Se comparte con franqueza que se estuvo evaluando usar KV, pero al no verle futuro se empezó a considerar alternativas
Surge la duda de si esto de que la mayoría de los desarrolladores despliegan no funciones stateless simples sino apps full-stack fuertemente integradas con bases de datos, en realidad aplica a todo el mundo serverless. Si es así, se pregunta si eso coincide con la intención original del movimiento serverless o si simplemente se elige para evitar infraestructura compleja como Docker o Kubernetes
Se explica que en Deno Deploy reciben con frecuencia preguntas sobre la reducción del número de regiones. Desde Deno se dice que la mayoría de las apps no necesitan ejecutarse en todas partes del mundo, sino ser rápidas cerca de los datos, fáciles de depurar y adecuadas a las regulaciones locales, y que esa es la dirección de su optimización. Pero quien comenta no lo usó justamente porque las ubicaciones regionales de Deno Deploy no estaban lo bastante cerca y eso generaba preocupación por el rendimiento. Ya existen muchas opciones más cercanas a los datos y a los usuarios, y en cumplimiento regulatorio normalmente basta con el nivel país, así que esta dirección de optimización no resulta convincente