Por que Deno?

Se você olhar meus projetos no Codeberg, vai ver uma grande preferência por Deno nos meus projetos JavaScript, ao invés de Node.js. Nesse texto eu quero dar meus motivos.

Após experimentar Deno^[1] desde a versão "beta", eu comecei a usar para valer depois do lançamento da versão 2.0, que corrigiu todas as minhas reclamações do ambiente de execução. Hoje eu acredito que Deno é a melhor forma de fazer um protótipo de projeto JavaScript, e escala muito bem para produção também.

Esse texto assume que você já saiba um pouquinho de programação. Preferencialmente Node.js, mas não é necessário.

O que o fullstack realmente significa

Antes de continuar, gostaria de fazer um exercício. Se você estiver num navegador desktop eu gostaria que você abrisse o console JavaScript dele e execute o seguinte código:

const {
  parse,
  parseRange,
  satisfies,
} = await import(
  "https://cdn.jsdelivr.net/gh/oscarotero/std@1.3.3/semver/mod.js"
);

const version = parse("1.2.3");
const range = parseRange(">=1.0.0 <2.0.0");

if (satisfies(version, range)) {
  console.log("Versão %cOK", "color: green; font-weight: bold");
} else {
  console.log("Versão %cnão suportada", "color: red; font-weight: bold");
}

Você deve ver algo do tipo Versão OK ou Versão não suportada dependendo do valor passado para a variável version. Mas se você tentar executar o mesmo código em Node.js, você vai ver um erro na linha do ERR_UNSUPPORTED_ESM_URL_SCHEME reclamando do "https" no import, além de que não há maneiras de se formatar a saída do console sem adicionar algum pacote npm como o Chalk.

Pois o código acima é perfeitamente válido no Deno. E esse é o primeiro ponto que eu gosto do Deno: usar padrões web o máximo possível, sem criar um novo "dialeto" da linguagem, como acontece com Node.

Eu acredito que JavaScript é uma boa primeira linguagem de programação devido a extremamente baixa barreira de entrada que é ter um navegador de internet. Se você aprendeu a programar para a Web, aprender Node é quase como aprender uma nova linguagem, e vice-versa. Por isso a comunidade desenvolvimento frontend hoje é tão dependente de bundlers e compiladores que traduzem e mudam o código para funcionar na Web.

Não que você deva colocar o seu código Deno totalmente numa página Web e executar de lá, mas é reconfortante poder usar as mesmas técnicas e sintaxe de um em outro.

Inclusive, se você tá acostumado com Node.js, deve estar estranhando aquele import ali.

O que importa é o que interessa

Uma das grandes características de Deno com relação aos outros tempos de execução JavaScript é permitir imports via HTTPS, com a possibilidade de usar importMaps para criar aliases para esses imports (ambas tecnologias da Web, inclusive). Na versão 1.x, essa era a única forma de divulgar e importar bibliotecas, o que tornava o maior impedimento para eu usar Deno, e eu não estava sozinho.

E eu entendo. Um dos grandes lamentos de seu criador foi o quão dependente Node.js era do NPM. Lembrando que NPM não faz parte da mesma entidade que cuida do Node.js, nunca fez. Hoje NPM é de responsabilidade da Microsoft por meio do Github, empresas que tão passando, no momento de escrita desse texto, por baixa aprovação dos desenvolvedores, para dizer o mínimo. Porém, negar todo o conhecimento e conteúdo contido nos repositórios do NPM foi, em minha opinião, um erro.

Deno 2.0 corrige esse erro de um jeito que gostei muito. Não só manteve os imports HTTPS como adicionou suporte a pacotes npm por meio da flag npm:, além de também criar um novo repositório chamado JSR (usando a flag jsr:) e permitir quase todos os módulos nativos do nodejs (node:). Isso torna Deno o ambiente JS mais completo de todos com relação a imports. Node permite nativamente apenas node: (duh), com possibilidade de usar jsr: se usar yarn ou pnpm, ou mediante uma ferramenta para traduzir JSR para NPM. O mesmo vale para Bun. Deno continua o único backend com suporte a https:.

Não só isso, como toda a biblioteca padrão do Deno está disponível pelo JSR. O que significa que se você aprende a usar essa biblioteca, você ainda pode usar nos outros ambientes. Assim como a sintaxe da Web, é um conhecimento que você não perde.

Tenho mais a falar sobre JSR, mas fica para outro texto. Agora quero falar sobre as ferramentas disponíveis no Deno.

Santo cinto de utilidades, Batman!

Ao criar um projeto JavaScript hoje em dia é quase obrigatório você instalar, pelo menos, um formatador de código, normalmente prettier, um analisador de qualidade de código estático tipo o eslint, e uma ferramenta de execução de testes como o Jest. Você pode escolher não usar, claro, mas para projetos de complexidade média a grande eles são de extrema importância. Isso vale também para suporte à linguagem TypeScript.

Deno traz tudo isso por padrão, por meio dos comandos deno fmt, deno lint, deno test e deno check, respectivamente. É uma ideia tão simples e boa que Bun, lançado 3 anos após Deno, fez o mesmo.

Então, não importa se o seu projeto tem apenas um arquivo de 10 linhas, ou é um monstro de centenas de kLoC, você ganha "de graça" essas ferramentas e não precisa se preocupar em manter essas "dependências de desenvolvimento" atualizadas^[2].

Até porque deixar dependências desatualizadas é uma grande falha de segurança. Nesse sentido, Deno tem mais uma carta na manga.

Segurança é o padrão

Já parou para pensar que Node tem acesso a todas a suas variáveis de ambiente? Que o código de uma dependência pode executar qualquer programa existente no teu computador? E o valor dessas variáveis e resultado dessas execuções podem ser enviados para qualquer servidor na internet sem você nem perceber?

Pois é. Isso pode acontecer. Tanto pode como já aconteceu algumas vezes. Basta uma rápida procura na internet por "npm supply chain attack" que você vai encontrar relatos de código malicioso escondidos em dependências de bibliotecas amplamente difundidas.

Deno bloqueia tudo por padrão. Acesso à internet? Só para baixar dependências. Leitura de arquivos? Só os arquivos de código-fonte. Execução de programa? Acesso a portas? Variáveis de ambiente? Informação do sistema? Tudo bloqueado e informado durante a execução. Com a opção de liberar explicitamente o que você está seguro e confortável com o que o código precisa.

Eu mesmo só fui me dar conta disso quando eu tentei executar um projeto Node no Deno e ele começou a listar todas as variáveis de ambiente e informações do sistema que o código tá acessando e me perguntar se o acesso era permitido ou não. Passei mais tempo escolhendo "sim ou não" do que de fato executando aquele "Hello world".

Isso pode ser chato no primeiro momento? Sim. Dá para desativar? Dá também. Mesmo assim, a visibilidade é importante e a cada nova versão Deno facilita a gestão desses acessos, e isso me traz um sincero alívio que o código que eu estou executando é seguro não só na minha máquina como na máquina de qualquer contribuidor dos meus projetos.

'node'.split('').sort().join('')

Esses são os motivos pelos quais eu escolhi Deno como meu ambiente "padrão" quando se trata de JavaScript e TypeScript: compatibilidade com padrões existentes na Web, ferramentas integradas, e segurança.

Entendo que Bun e Node continuam tendo seus pontos fortes. Também entendo que Deno ainda é um ambiente de nicho que pode dificultar alguns fluxos de trabalho como o uso de LLMs (apesar de que isso para mim é um bônus). Mas nenhum outro ambiente faz tudo o que eu preciso como o Deno.

E eu nem falei de ações da equipe do Deno fora do contexto de execução de código, como o processo conta a Oracle sobre a posse da marca registrada "JavaScript". Que é outro buraco que eu não quero entrar agora.

Espero que esse texto seja instrutivo. Não acho que todo mundo deva mudar para Deno, mas acho extremamente importante que todos saibam que JavaScript não significa Node.

Que a Força esteja com você.

A expressão JavaScript é um termo registrado como marca (trademark) nos Estados Unidos e, atualmente, a Oracle Corporation detém os direitos sobre essa marca.

O presente artigo não implica, de forma alguma, qualquer endosso, afiliação, apoio institucional ou autorização da Oracle Corporation ou de seus representantes legais ao conteúdo editorial, às atividades do escritório autoral, ou às iniciativas aqui descritas. Qualquer uso comercial da marca JavaScript deve observar as normativas de propriedade industrial aplicáveis e, se necessário, obter aconselhamento jurídico adequado para mitigar riscos de violação de direitos de marca.