🙌🏽 🧗🏻 🐁 5 reivindicações a Deno 🕷️ 🔠 👨‍🚒

Prefácio

Não faço parte da equipe deno. Eu não sou fã dele. Eu não o sigo. Eu nem acredito nele. Mas, vendo a reação negativa da comunidade, não posso deixar de intervir. Neste artigo, gostaria de considerar as reivindicações mais comuns contra Deno e oferecer um ponto de vista alternativo.

Deno - o assassino dos NodeJs

Isso não é verdade. Dessa forma, ele é promovido apenas por “testemunhas deno”, fãs loucos ou tradutores famintos por publicidade. Até onde eu sei, até o próprio Ryan Dahl (autor de Deno) não posiciona seu desenvolvimento como um substituto ou uma alternativa aos NodeJs. Em vez disso, sua visão é "o que podem ser os mesmos NodeJs no futuro". O conceito, se você quiser (não repreendemos os conceitos de carros ou smartphones por sua impraticabilidade nas realidades modernas). Do ponto de vista de Ryan, os NodeJs têm alguns problemas. E ele mostrou à comunidade uma certa idéia de como esses problemas poderiam ser resolvidos. E você pode participar disso. Venha para o GitHub agora e descreva os problemas de arquitetura que você vê. Discuta-os. Crie soluções.

Acho que o Deno nunca substituirá os NodeJs. Mas pode se tornar para ele o que o TypeScript para JavaScript se tornou.

Importar por URL

Muitas pessoas olham um pouco do ângulo errado. A idéia é descartar a lista de dependência global de todo o projeto. Portanto, em vez de um grande package.json, você tem sua própria lista independente de dependências em cada um dos seus módulos / arquivos. Eu vejo várias vantagens nisso.

Se você precisar escrever algum recurso, não precisará examinar quais dependências já são usadas no projeto. Você não está limitado a eles. Você usa o que precisa.
Você pode adicionar funcionalidade sem olhar para o legado. Os novos módulos terão suas próprias dependências e os antigos terão suas próprias.
Durante a migração de um projeto grande para uma nova versão de alguma dependência, você pode alterar a base de código e implementar essas alterações em partes.

Mas, para essa abordagem, você precisa da capacidade de descrever as dependências para cada módulo. Nome, versão e onde obter essa dependência. Como resultado, importe com um URL. E essa nem é a noção de Deno. Isso faz parte do padrão . É que todos estão acostumados a trabalhar como estão acostumados. Mas esse não é o único caminho.

Mas como agora trabalho sem a Internet?

Assim como você trabalharia com os NodeJs. O que Deno, que NodeJs baixam dependências em um diretório separado. Somente nos NodeJs você inicia isso npm install, e o Deno faz isso automaticamente na primeira vez que o inicia.

Parece interessante, mas eu recuso!

Sem problemas. Existe uma coisa: importar mapas . E Deno o apoia , embora não totalmente. Assim, você pode descrever sinônimos para todas as dependências acessando um analógico package.json. Mas você não ficará limitado a isso:

Os módulos individuais ainda podem usar suas próprias versões de dependência, ignorando o mapa de importação conforme necessário.
A especificação de mapas de importação sugere a capacidade de especificar várias fontes para download. Deno atualmente não suporta isso. Mas tecnicamente é possível. Você pode indicar várias fontes e, se uma não estiver disponível, a dependência será baixada da outra.
```
{
   "imports": {
      "moment/": [
         "https://deno.land/x/moment/",
         "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
      ]
   }
}
```

Sem npm, não posso entregar o utilitário do console globalmente!

Bem, na verdade você pode . deno installIsso é analógico npm install --global. O Deno baixa, compila a biblioteca necessária em um binário e a salva globalmente. A diferença é que você deve dar à biblioteca algum tipo de permissão. Ou seja, um pacote instalado globalmente não terá acesso à rede, aos arquivos ou a qualquer lugar sem o seu consentimento.

Sentimento estranho deja vu

E não é sem rigor. Deno é o mesmo NodeJs . Vejo apenas algumas diferenças:

Deno rejeitou a compatibilidade com versões anteriores. O que lhe permitiu perceber as mesmas coisas, usando não sua própria bicicleta, mas a bicicleta descrita na especificação do idioma. Estou certo de que, se algum tipo de "Nó seguinte" surgisse sem compatibilidade com versões anteriores, teríamos a mesma coisa que Deno oferece. E os NodeJs estão gradualmente se movendo nessa direção: todos os novos chips ES (como módulos ES, espera de nível superior etc.) estão sendo gradualmente introduzidos nos NodeJs.
Recusa da lista geral de dependências. Isso pode ser um sinal de mais ou menos. Depende dos casos específicos. Mas não se pode negar que essa arquitetura tenha o direito de existir.
A idéia é impedir que o script acesse o sistema sem permissão explícita.

Essas são todas as diferenças na minha opinião. Portanto, não vejo razão para odiar Deno. É esse o seu pessoal agressivo de relações públicas :)

5 reivindicações a Deno