Ryan Dahl: Do Node.js e Deno ao registro JSR ‘moderno’

Ryan Dahl continua encontrando novas abordagens para tecnologias familiares. Mais de uma vez, ele desempenhou um papel central na evolução de um ecossistema existente. Agora ele faz parte de um esforço para modernizar os vários módulos de código que os desenvolvedores importam para seus projetos todos os dias. E não se trata apenas de atualizar repositórios e cadeias de fornecimento, mas, em última análise, da forma como o desenvolvimento seguro é executado.

Em um episódio recente do podcast do Stack Overflow que apresentou Dahl, o editor do StackOverflow, Ryan Donovan, começou reconhecendo que Dahl “iniciou todo o movimento JavaScript no backend” – antes de segui-lo em 2018 com o tempo de execução Deno para JavaScript, TypeScript, e WebAssembly. No podcast, Dahl resumiu sucintamente grande parte do esforço comercial do projeto Deno hoje: “para construir, vamos chamá-lo, um tempo de execução em nuvem, um tempo de execução JavaScript multilocatário que abrange regiões de data center – abrange até nuvens – e está configurado para lidar com muitos, muitos usuários ao mesmo tempo.”

Mas Dahl também gravou a entrevista apenas duas semanas depois de Deno ter anunciado o lançamento do novo JavaScript Registry, que Dahl disse garantirá que seus pacotes publicados “sejam modernos e sigam as melhores práticas”.

Dahl usou o podcast para explicar as múltiplas ambições por trás do projeto, oferecendo uma visão de como será um repositório seguro no futuro.

E ao longo do caminho, ele até ofereceu uma previsão sobre o que está por vir para o JavaScript…

Por que JSR?

Entre outras coisas, os pacotes JSR incluem arquivos de declaração de tipo. Mas Dahl disse que o novo repositório está tentando resolver o fato de que o JavaScript tem dois sistemas de módulos diferentes que “não funcionam bem um com o outro” – módulos CommonJS e ECMAScript (ou ESM). Na opinião de Dahl, o ESM “agora está incorporado em todos os navegadores da web, a verdadeira maneira de fazer módulos”. (“Os módulos ECMAScript chegaram como padrão”, explica o FAQ do repositório.) Portanto, o JSR suporta apenas módulos ES.

Mas, além disso, “existem mais tempos de execução de JavaScript do que apenas Node.js e navegadores. Com o surgimento de Deno, Bun, Workerd e outros novos ambientes JavaScript, um registro de pacotes centrado em Node.js não faz mais sentido para todo o ecossistema JS.” E com o TypeScript emergindo como um padrão de fato, “Um registro moderno deve ser projetado com o TypeScript em mente”.

No entanto, além disso, Dahl vê tudo num contexto mais amplo. “Deno em geral está tentando aprimorar o JavaScript…” ele disse no podcast. “Cabe a nós, como desenvolvedores, realmente levar esse ecossistema para o futuro. E Deno está tentando fazer isso na camada de tempo de execução, mas o que percebemos é, na verdade, um problema na camada de registro onde você compartilha código.”

O JSR não pretende ser um substituto do registro de pacote npm atual, mas um extensão, Dahl explicou. “Em certo sentido, você pode pensar nisso como um superconjunto de npm, da mesma forma que o próprio TypeScript é um superconjunto de JavaScript.”

Você sabia que os pacotes JSR podem ser usados ​​no Node.js sem nenhuma configuração?

⬇️⬇️⬇️ pic.twitter.com/4AtwLtmX4q

-JSR (@jsr_io) 6 de março de 2024

Mas Dahl pensou muito no npm. “Por muito tempo, eles nem mantiveram checksums de pacotes npm. E houve casos em que hackers entraram no registro e potencialmente alteraram tarballs que foram publicados, e não há como saber porque não há soma de verificação desses tarballs.” Há também problemas na cadeia de suprimentos – o problema não apenas de solicitações pull maliciosas, mas de códigos maliciosos vindos do upstream…

JSR tenta fornecer mais visibilidade com uma maneira simples de fornecer assinaturas criptográficas aos pacotes. Pacotes criados no GitHub (usando GitHub Actions) podem fornecer um token OpenID Connect para JSR que publicará a assinatura criptográfica correspondente no blockchain Sigstore. “Podemos fazer esses ‘atestados criptográficos’, como são chamados, de onde os pacotes foram construídos – e publicá-los nas páginas dos pacotes e expor esses detalhes aos usuários.” Resumindo, ele fornece um registro de onde vem o código. “E isso é importante para a confiança, certo?

“É construir uma rede de confiança.”

Mais tarde, Dahl chama isso de certa forma de “uma extensão de commits assinados…”

“As coisas que inventei em 2010 para o Node.js simplesmente não são o lugar onde os navegadores estão indo agora. E acho que há uma necessidade real de diminuir a distância entre os navegadores.”

—Ryan Dahl

Tudo faz parte de uma visão para um futuro mais seguro. “No final do dia, você pegará uma série de dependências e construirá seu microsserviço e, em seguida, executará isso como um contêiner Docker em alguma infraestrutura Kubernetes. E seria muito bom… poder dizer que todo o software em execução dentro deste contêiner Docker tem atestados que o rastreiam até um usuário verificado em algum lugar e que não há nenhum código em execução aqui que não tenhamos sabe de onde veio.

“Estamos construindo a infraestrutura para isso. E o que provavelmente acontecerá é que, no futuro, cada microsserviço terá uma atribuição clara para todas as suas dependências. E isso é muito bom – então você realmente mitigou o risco da cadeia de abastecimento.”

Dahl também enfatiza que o novo repositório (ao contrário do npm) “é completamente open source. O back-end, o front-end – tudo é de código aberto e licenciado pelo MIT.”

A JSR não faz parte das operações comerciais da empresa Deno. “JSR é para a comunidade JavaScript. É uma tentativa de elevar o nível do JavaScript e foi projetado para poder ser executado de maneira muito barata em software de nuvem comum… Gostaríamos, eventualmente, de ter essa coisa em uma base e operando de forma independente. Estamos tentando construir aqui uma instituição para o futuro do JavaScript.”

Agora em seu estágio “beta público” no jsr.io, o JSR é oficialmente anunciado como um registro de pacote “para JavaScript e TypeScript modernos”.

Dahl enfatizou no podcast que não é um pacote gerente. “Você pode usar seu gerenciador de pacotes existente, mas conectá-lo a este novo registro…”

Olhando para o futuro

A certa altura, Dahl reconheceu que o TypeScript era “muito, muito útil. Tem uma utilidade clara.” Tanto é verdade que ele prevê que seu conceito de superconjunto de tipos de JavaScript “provavelmente será codificado em padrões. Talvez não neste ano, no ano que vem ou no ano seguinte, mas acho que com o tempo o TypeScript encontrará seu caminho para os padrões e realmente se tornará parte do que é o JavaScript.”

Quando questionado sobre previsões sobre o futuro do JavaScript, Dahl começou dizendo que a linguagem está “profundamente incorporada” no ecossistema web atual e “Definitivamente não irá desaparecer tão cedo… Ao contrário de muitas outras tecnologias no mundo, sinto-me confiante em dizer que o JavaScript estará aqui daqui a cinco anos, se não daqui a 10, se não daqui a 20 anos.”

Ele até colocou isso nos termos mais pragmáticos possíveis. “Como o seu banco depende de JavaScript. Não vai desaparecer tão cedo.”

Mas olhando especificamente para o que está por vir, Dahl disse “O futuro do JavaScript são os navegadores. Os navegadores sempre ditarão o futuro do JavaScript.”

Portanto, embora haja obviamente uma grande comunidade escrevendo JavaScript do lado do servidor, “qualquer código do lado do servidor deve diminuir a lacuna para o JavaScript do navegador”. É parte do motivo pelo qual eles estão empurrando módulos ECMAScript em vez de módulos CommonJS.

“As coisas que inventei em 2010 para o Node.js simplesmente não são o lugar onde os navegadores estão indo agora. E acho que há uma necessidade real de diminuir a distância entre os navegadores.”

A postagem Ryan Dahl: Do Node.js e Deno ao registro JSR ‘Moderno’ apareceu pela primeira vez em The New Stack.