👂🏼 ⚓️ 💂 5 reclamaciones a Deno 🧕🏼 🤓 👁️

Prefacio

No soy parte del equipo deno. No soy su fan. No lo sigo. Ni siquiera creo en él. Pero al ver la reacción negativa de la comunidad, simplemente no puedo evitar intervenir. En este artículo, me gustaría considerar los reclamos más comunes contra Deno y ofrecer un punto de vista alternativo.

Deno - el asesino de NodeJs

Esto no es verdad. De esta manera, solo es promovido por "testigos deno", fanáticos locos o traductores hambrientos. Hasta donde yo sé, incluso el propio Ryan Dahl (autor Deno) no posiciona su desarrollo como un reemplazo o alternativa a NodeJs. Más bien, su visión es "lo que pueden ser los mismos nodos en el futuro". El concepto, si lo desea (no regañamos los conceptos de automóviles o teléfonos inteligentes por su impracticabilidad en las realidades modernas). Desde el punto de vista de Ryan, NodeJs tiene algunos problemas. Y le mostró a la comunidad una cierta idea de cómo se podrían resolver estos problemas. Y puedes participar en esto. Ven a GitHub ahora mismo y describe los problemas arquitectónicos que ves. Discutirlos. Encuentra soluciones.

No creo que Deno reemplace a NodeJs. Pero puede convertirse para él en lo que se ha convertido TypeScript para JavaScript.

Importar por URL

Mucha gente lo mira un poco desde el ángulo equivocado. La idea es descartar la lista de dependencia global para todo el proyecto. Para que en lugar de un gran package.json tenga su propia lista independiente de dependencias en cada uno de sus módulos / archivos. Veo varias ventajas en esto.

Si necesita escribir alguna característica, no es necesario que observe qué dependencias ya se utilizan en el proyecto. No estás limitado a ellos. Usas lo que necesitas.
Puede agregar funcionalidad sin mirar el legado. Los nuevos módulos tendrán sus propias dependencias, y los antiguos tendrán las suyas.
Durante la migración de un proyecto grande a una nueva versión de alguna dependencia, puede cambiar la base del código y desplegar estos cambios en partes.

Pero para este enfoque, necesita la capacidad de describir las dependencias para cada módulo. Nombre, versión y dónde obtener esta dependencia. Como resultado, importe con una URL. Y esa ni siquiera es la noción de Deno. Esto es parte del estándar . Es solo que todos están acostumbrados a trabajar como solían hacerlo. Pero esta no es la única forma.

Pero, ¿cómo trabajo ahora sin Internet?

Al igual que trabajarías con NodeJs. Qué Deno, que NodeJs descargue dependencias en un directorio separado. Solo en NodeJs inicia esto npm install, y Deno lo hace automáticamente la primera vez que lo inicia .

Suena interesante, pero me niego!

No hay problema. Existe tal cosa: importar mapas . Y Deno lo apoya , aunque no completamente. Por lo tanto, puede describir sinónimos para todas las dependencias llegando a un análogo package.json. Pero no estará limitado a esto:

Los módulos individuales aún pueden usar sus propias versiones de dependencia, ignorando el mapa de importación según sea necesario.
La especificación de mapas de importación sugiere la capacidad de especificar múltiples fuentes para descargar. Deno actualmente no es compatible con esto. Pero técnicamente es posible. Puede indicar varias fuentes y, si una no está disponible, la dependencia se descargará de la otra.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

¡Sin npm, no puedo ofrecer la utilidad de consola a nivel mundial!

Bueno, en realidad puedes . deno installEsto es un análogo npm install --global. Deno descarga, compila la biblioteca requerida en un binario y la guarda globalmente. La diferencia es que debe otorgar a la biblioteca algún tipo de permiso. Es decir, un paquete instalado globalmente no tendrá acceso a la red, a los archivos, ni a ningún lugar sin su consentimiento.

Extraño sentimiento deja vu

Y no es sin minuciosidad. Deno es el mismo NodeJs . Solo veo algunas diferencias:

Deno rechazó la compatibilidad con versiones anteriores. Lo que le permitió darse cuenta de las mismas cosas, usando no su propia bicicleta, sino la bicicleta descrita en la especificación del lenguaje. Estoy seguro de que si surgiera algún tipo de "Nodo-siguiente" sin compatibilidad con versiones anteriores, obtendríamos lo mismo que Deno ofrece. Y NodeJs se está moviendo gradualmente en esta dirección: todos los nuevos chips ES (como módulos ES, espera de nivel superior, etc.) se están introduciendo gradualmente en NodeJs.
Denegación de la lista general de dependencias. Esto puede ser un más o menos. Depende de los casos específicos. Pero no se puede negar que dicha arquitectura tiene derecho a existir.
La idea es evitar que el script acceda al sistema sin permiso explícito.

Esas son todas las diferencias en mi opinión. Así que no veo razón para odiar a Deno. ¿Es esa su agresiva gente de relaciones públicas :)

5 reclamaciones a Deno