O que é o Deno e como esse projeto é diferente do Node.js?

Ryan Dahl, criador do Node.js, passou o último ano e meio trabalhando no projeto Deno . Este é o novo tempo de execução JavaScript que deve corrigir os problemas inerentes ao Node.js.

Não me interpretem mal. A plataforma Node.js. é um ótimo ambiente do lado do servidor para executar JavaScript. Ele deve sua popularidade principalmente a um enorme ecossistema e, de fato, suporte ao JavaScript. No entanto, Ryan Dahl admite que algo sobre o Node.js deve merecer sua atenção. Isso, em particular, trata de segurança, de módulos e de gerenciamento de dependências.


Em sua defesa, pode-se dizer que ele não sabia o quão popular a plataforma Node.js. se tornaria em um período bastante curto de tempo. Além disso, em 2009, o JavaScript ainda parecia uma linguagem limitada e estranha, ridicularizada por todos que não eram preguiçosos. Também deve ser observado que, naqueles dias, muitos dos recursos JavaScript comuns hoje em dia não existiam.

O que é o Deno e quais são as principais características desta plataforma?

Deno é um tempo de execução seguro TypeScript, construído sobre o mecanismo V8 JS desenvolvido pelo Google. A plataforma Deno foi criada usando as seguintes ferramentas:

• Rust (o núcleo do Deno está escrito em Rust e o núcleo do Node está em C ++).
• Tokio (loop de evento escrito em Rust).
• TypeScript (o Deno, sem configurações adicionais, suporta JavaScript e TypeScript).
• V8 (mecanismo JS do Google usado no navegador Chrome, Node.js e outros projetos).

Vamos falar sobre quais oportunidades a plataforma Deno nos oferece.

Segurança (permissões)

Entre as características mais importantes do Deno, que recebem atenção especial, destaca-se a segurança.

Ao contrário do Node, o Deno, por padrão, executa o código em uma sandbox. Isso significa que o tempo de execução não tem acesso às seguintes entidades e recursos:

• Sistema de arquivos.
• Rede.
• Execução de outros scripts.
• Variáveis ​​de ambiente.

Veja como o sistema de permissões de Deno funciona. Considere o seguinte script:

(async () => {  const encoder = new TextEncoder();  const data = encoder.encode('Hello world\n');  await Deno.writeFile('hello.txt', data);  await Deno.writeFile('hello2.txt', data); })(); 

Este script cria um par de arquivos de texto - hello.txt e hello2.txt . O texto Hello world colocado nesses arquivos. O código é executado na sandbox. Portanto, ele não tem acesso ao sistema de arquivos.

Além disso, preste atenção ao fato de que aqui usamos o namespace Deno , em vez de nos referirmos a algo como o módulo fs , como no Node. O espaço para nome Deno fornece ao desenvolvedor muitas funções auxiliares básicas. Mas nós, usando o espaço para nome, perdemos a compatibilidade do código com o navegador. Falaremos sobre isso abaixo.

Este script pode ser executado com o seguinte comando:

 deno run write-hello.ts 

Depois disso, veremos uma notificação com o seguinte conteúdo:

 Deno requests write access to "/Users/user/folder/hello.txt". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)] 

De fato, podemos ver isso duas vezes durante cada uma das chamadas. Obviamente, se respondermos à pergunta do sistema selecionando a opção allow always , na segunda vez não receberemos esta notificação.

Se escolhermos uma das opções de deny , será PermissionDenied um erro PermissionDenied . O processo de script será concluído, pois não há código para lidar com erros.

O script pode ser executado assim:

 deno run --allow-write write-hello.ts 

Não veremos nenhuma notificação; os dois arquivos serão criados.

Além do --allow-write , que afeta o trabalho com o sistema de arquivos, você pode usar outros sinalizadores ao executar scripts. Eles são --allow-net , --allow-env e --allow-run . Eles respectivamente abrem o acesso do script à rede, ao ambiente e ao lançamento de subprocessos.

Módulos

Deno, como navegadores, carrega módulos por URL. No início, muitas pessoas ficam confusas com o que veem nos comandos de importação de código do servidor com URLs. Mas isso, de fato, faz sentido. Espere um pouco - e você mesmo entenderá.

 import { assertEquals } from "https://deno.land/std/testing/asserts.ts"; 

Aqui você pode ter uma pergunta sobre o que há de tão especial na importação de pacotes por URL? A resposta a esta pergunta é simples: através do uso de URLs, os pacotes Deno podem ser distribuídos sem o uso de um registro central como o npm. Ultimamente, a Npm tem tido muitos problemas .

A organização da importação de código via URL permite que os criadores de pacotes hospedem seu código sempre que acharem melhor. Isso é descentralização em toda a sua glória. Chega de package.json e node_modules .

Quando iniciamos o aplicativo, o Deno carrega todos os módulos importados e os armazena em cache. Uma vez armazenados em cache, o Deno não os recarregará, a menos que solicitamos explicitamente que sejam --reload usando o sinalizador --reload .

Em relação a este sistema de trabalho com módulos, várias perguntas importantes podem ser feitas.

E se o recurso no qual o código do módulo estiver localizado estiver inacessível?

O código do módulo não é armazenado em um registro centralizado. O recurso da web que hospeda esse código pode não estar disponível por vários motivos. Durante o processo de desenvolvimento, ou, pior ainda, colocar o projeto em produção, é arriscado esperar que a hospedagem do módulo esteja sempre disponível.

Como já mencionado, o Deno armazena em cache os módulos carregados. Como o cache é armazenado em um disco local, o criador do Deno recomenda processá-lo usando o sistema de controle de versão (ou seja, git) e incluí-lo no repositório do projeto. Com essa abordagem, mesmo quando o recurso no qual o código está armazenado estiver inacessível, todos os desenvolvedores do projeto terão acesso às versões baixadas dos módulos.

Deno armazena o cache na pasta especificada pela variável de ambiente $DENO_DIR . Se não configurarmos essa variável, o Deno armazenará o cache no diretório padrão do sistema para caches. A $DENO_DIR pode ser definida para que aponte para alguma pasta em nosso repositório local. Essa pasta pode ser processada usando seu sistema de controle de versão.

▍Preciso importar constantemente módulos por URL?

A inserção regular de URLs longos regularmente pode ser entediada rapidamente. Felizmente, Deno nos dá duas maneiras de facilitar essa tarefa.

A primeira maneira é usar a capacidade de reexportar o módulo importado do arquivo local. Por exemplo, pode ser assim:

 export { test, assertEquals } from "https://deno.land/std/testing/mod.ts"; 

Suponha que o arquivo no qual o comando acima está localizado se chame local-test-utils.ts . Agora, se precisarmos das funções test ou assertEqual , podemos importá-las assim:

 import { test, assertEquals } from './local-test-utils.ts'; 

Como resultado, verifica-se que não importa se o módulo foi carregado por URL ou não.

A segunda opção é criar um mapa de importação na forma de um arquivo JSON:

 {   "imports": {      "http/": "https://deno.land/std/http/"   } } 

Ao usar um arquivo semelhante, o comando import pode se parecer com o seguinte:

 import { serve } from "http/server.ts"; 

Para que esse esquema funcione, é necessário informar o sistema sobre o uso do mapa de --importmap no projeto, usando o sinalizador --importmap ao executar o script:

 deno run --importmap=import_map.json hello_server.ts 

▍Como o controle de versão do módulo é gerenciado?

O controle de versão do pacote é de sua responsabilidade. Do ponto de vista do cliente, escolher a versão correta do pacote é como adicioná-la ao URL:
https://unpkg.com/liltest@0.0.5/dist/liltest.js .

Compatibilidade do navegador

A plataforma Deno busca a compatibilidade de seu código com os navegadores. Do ponto de vista técnico, quando usamos módulos ES, não somos obrigados a usar algumas ferramentas de montagem, como o webpack, que oferecem a capacidade de executar o aplicativo em um navegador.

No entanto, ferramentas como Babel convertem o código JS moderno em código compatível com ES5. Como resultado, esse código pode ser executado mesmo em navegadores não mais recentes que não suportam recursos modernos de JavaScript. Mas essa abordagem também tem um sinal de menos, que consiste no fato de os pacotes de projetos da Web crescerem devido ao fato de eles receberem muito código auxiliar.

Na verdade - tomamos decisões sobre os objetivos de nossos projetos. Nós escolhemos as ferramentas apropriadas.

Suporte TypeScript

Deno simplifica o uso do TypeScript, eliminando a necessidade de os desenvolvedores configurarem qualquer coisa para executar o código TS. Mas os programas Deno também podem ser escritos em JavaScript sem problemas.

Sumário

Deno, o novo ambiente de tempo de execução para TypeScript e JavaScript, é um projeto interessante que vem demonstrando sustentabilidade há algum tempo. No entanto, antes que possa ser considerado pronto para produção, ele ainda tem um longo caminho a percorrer.

A abordagem descentralizada para trabalhar com os módulos implementados no Deno visa liberar o ecossistema JavaScript de um repositório de pacotes centralizado, que hoje é npm.

Ryan Dahl diz que espera lançar o Deno 1.0 no final do verão. Se você está interessado no futuro deste projeto - preste atenção ao seu repositório .

Caros leitores! O que você acha do Deno?