Por que Deno é um passo errado no futuro

PorAntónio César de Andrade

https://www.youtube.com/watch?v=Uf1md0k6ATs

Para provar que não sou contra “Deno” e JavaScript em geral, gostaria de declarar algo. Eu amo JavaScript mais do que tudo. Minha pilha de tecnologia principal envolve apenas JavaScript – Node / React / MongoDB / React Native / NativeScript / Ionic / o nome dele. Eu construí um Canal de 100 mil no YouTube e um plataforma de desenvolvedor principalmente em uma única linguagem de programação – JavaScript. Mas, ao mesmo tempo, é importante manter-se prático e manter a cabeça limpa para ver os dois lados da moeda. Deno tem um lado bom e um lado que as pessoas ainda não estão vendo / escrevendo. Vou escrever meus pontos de vista no segundo lado. Vamos lá!

Deno v / s Node – não há “nenhuma concorrência”

Muitas pessoas na indústria estão dizendo que “oh, bem, não há concorrência entre Deno e Node, há muito que ambos podem aprender um com o outro”. Até certo ponto, eu concordo, há muito que Node e Deno podem aprender um com o outro. Mas não há competição? Eu discordo completamente disso. Vejamos os recursos comuns do Deno e do Node:

  1. Ambientes de tempo de execução para JavaScript
  2. É executado em qualquer computador em que você possa executar o V8
  3. Suporte padrão ECMAScript
  4. Ativamente mantido

Se você se tornar um fã do “Deno” dois anos depois, nunca escolherá o Node para o seu próximo projeto. Simplesmente não é possível. Da mesma forma, se você nunca trabalhou com TypeScript antes e deseja experimentar o Deno, ou talvez queira ter alguns módulos NPM, não escolheria o Deno. É isso mesmo, existe uma divisão de desenvolvedores em Deno e Node – eu diria que é um exemplo muito bom de espaço competitivo.

Deno – por que

Em primeiro lugar, gostaria de listar em nome de Deno, o que e por que ele se apresenta como um tempo de execução melhor:

  1. Supera deficiências do nó
  2. Ambiente de tempo de execução seguro por padrão
  3. Suporte TypeScript cozido em
  4. Promete todo o caminho
  5. Construído sobre Rust (vs C ++ para Nó)

Na próxima seção, selecionarei todos esses pontos um por um e mencionaria o que o Node pode aprender com eles, e sempre que necessário, por que o Deno não faz muito sentido.

Deno – por que não

Vamos pegar os USPs de Deno e dividi-los um por um:

Ambiente de tempo de execução seguro por padrão

Esta é a característica mais célebre de Deno, e estou surpreso por que. Por padrão, o Deno executa seu código JavaScript em uma caixa de proteção segura – impedindo o acesso ao sistema de arquivos e à rede, a menos que você aceite explicitamente. Deno faz isso porque deseja imitar o navegador. Mas por que? Por que você deseja imitar o navegador em primeiro lugar? Deno cumpre o padrão ECMAScript, o que é ótimo! Mas o que há com o amor louco dos navegadores? Entendi, você deseja manter a compatibilidade entre o código escrito em clientes e servidores. Mas foi tão fortemente apresentado por Deno ao ponto que acredito que Deno simplesmente seguiu o caminho errado.

O nó não suporta “tempo de execução seguro” – e depois de muito pensar, acredito que há poucas razões para suportá-lo também.

  1. É um fato conhecido que você não deve executar códigos / executáveis ​​não confiáveis ​​em seus sistemas. Esse é o objetivo de sempre optar por bibliotecas como express para Node, em vez de um módulo npm obscuro dizer que funciona 100x mais rápido que o express. A confiança vem do uso da comunidade.
  2. Eu não conheço nenhuma linguagem de programação que suporte esse sandbox em sua essência. Embora possa parecer sofisticado, parece algo que deve ser feito por um ambiente de contêiner, como o Docker. Confiaria em uma boa configuração do Docker executando código de nó não confiável o dia todo, acima da execução de código de nó não confiável em um ambiente Deno em área restrita. Por quê? Porque a Docker é uma empresa de bilhões de dólares construída em torno apenas de um único objetivo – sandboxing.
  3. O sandbox é difícil – eu não sou um guru de segurança cibernética, mas quanto mais recursos houver, maior será a área da superfície de ataque. Deno promete um ambiente de tempo de execução seguro, e eu não diria de maneira alguma que ele possa ser comprometido imediatamente, mas apenas afirme um fato aqui – a segurança é difícil de implementar corretamente. Deno está assumindo uma enorme responsabilidade aqui. As maiores empresas do mundo administram seus programas de whitehat e gastam centenas de milhões de dólares todos os anos para indivíduos e empresas de segurança independentes. Como está a Deno em termos de seu ambiente verdadeiramente seguro? O tempo vai dizer.

Então, o que o Node pode aprender com Deno sobre isso? Eu diria que não muito. O nó * pode * querer trazer alguns sinalizadores de ambiente seguro de seus concorrentes, mas não vejo sentido. Sem ofensas, mas se você é estúpido o suficiente para executar aleatoriamente código arbitrário em seus sistemas, você também pode clonar um repositório C / C ++ e executar um comando make sobre ele e comprometer todo o seu sistema. Tanto quanto eu sei, você não pode “sandbox” o sistema de arquivos ou o acesso à rede em linguagens de baixo nível como C / C ++ – simplesmente não é eficiente.

Suporte TypeScript cozido em

Hurrah para TypeScript. Estou realmente feliz que Deno o suporte imediatamente. Mas vamos reverter um pouco. Você sabe por que o JavaScript (e o Node) tem um trilhão de desenvolvedores em todo o mundo? Porque a barreira de entrada é quase nula. O JavaScript é flexível e perdoa muitos erros – enquanto traz alguns dos comportamentos mais estranhos que você esperaria de um computador determinístico. Isso é muito ruim para aplicativos em nível de produção, nos quais você não quer coisas desagradáveis, e para os alunos, é perdoador – o que às vezes pode frustrá-lo com erros desagradáveis ​​-, mas também permite que as pessoas escapem com seus erros inicialmente. Permite que eles “se movam rápido e quebrem coisas”, se eu citar.

Para os iniciantes, receio que, se optarem pelo Deno (que exige o uso do TypeScript), veremos muitos códigos como este, porque eles ainda não entendem o TypeScript e desejam executar o JavaScript no servidor :

const httpResponse: any = await getAPIResponse({ myParams })
// ...
const someOtherVariable = something() as any
// ...
any, any, any

TypeScript é um superconjunto de JavaScript. Você também pode escrever código TypeScript incorreto, apenas usá-lo não torna seu JavaScript à prova de balas.

É tudo divertido e bom até você perceber que pode escrever o código Node no TypeScript. Estou certo de que todas as grandes empresas que usam Node na produção estão escrevendo Node no TypeScript – zero exceções. O JavaScript simplesmente não é escalável quando você lida com vários arquivos, várias dependências e uma infinidade de códigos. O TypeScript é um kit de ferramentas revolucionário no ecossistema JavaScript e permite o uso do melhor dos dois mundos – linguagem estática e dinâmica.

Para isso, Deno argumenta que o suporte ao TypeScript deve ser incorporado. Eu perguntaria por que? Claro, você pode precisar de babel e webpack para fazer o trabalho, mas não é esse o objetivo de ter kits de ferramentas por aí? Não queremos aprimorar o DX? O JavaScript continuará sendo o JavaScript e, se o Deno executasse o TypeScript (ou uma linguagem como o TypeScript) diretamente, eu não teria problemas. Mas ele também não está executando o TypeScript, converte seu código TypeScript em JavaScript e o executa. Nesse ponto, parece que o Deno é uma versão monolítica do kit de ferramentas de testes de empacotamento do Node, formatador de código, TypeScript, tudo de uma vez. Não posso falar para todos os desenvolvedores, mas gostaria que o núcleo da minha linguagem de programação fosse enxuto e adicione outros utilitários, se e quando eu quiser. Por que eu precisaria de uma ferramenta interna para formatação de código, quando existe mais bonita e tem o único objetivo de formatar o código? Por que resolver coisas que não estão quebradas?

Embora seja verdade que a arquitetura monolítica fornece muitas ferramentas no mesmo local, também é verdade que é volumosa e que um núcleo enxuto é muito mais fácil de manter e dimensionar.

Promete todo o caminho

Este ponto do lançamento do Deno 1.0 não fez muito sentido para mim como distinção. Tenho todo o respeito pelos criadores iniciais do Node e pelos atuais criadores do Deno. Mas o Node tem algo que Deno não tem – experiência e apoio de uma enorme variedade de desenvolvedores em todo o mundo. O Node é contribuído por quase 3000 pessoas e é o pioneiro no tratamento de E / S assíncrona. Claro, o Deno é baseado no Rust e expõe uma abstração semelhante a uma promessa, no entanto, o Node possui C ++ e 3000 desenvolvedores e 10 anos de trabalho + resultados de experimentos.

O modelo assíncrono do nó não está quebrado, as promessas e o modelo do ouvinte de eventos não estão quebrados, por isso não tenho certeza de como o Deno pode corrigir o que não está quebrado.

hasta la vista npm

Coisa enorme. Deno não suporta o NPM e, por mais que outros possam “criticar” Deno por essa decisão, acredito que eles não têm escolha de qualquer maneira. Os pacotes JavaScript do NPM não devem ser suportados de qualquer maneira:

  1. Em primeiro lugar, porque eles são JavaScript – e o Deno precisa do TypeScript
  2. Em seguida, muitos desses módulos npm exigiriam permissões de sistema de arquivos / rede / outras – que Deno restringe por padrão. Então você precisa mexer com alguns novos campos de “permissões” no package.json. Ops, o Deno não funciona com o npm, portanto, sem o package.json, vamos ver como ele lida com o sistema de módulos.
  3. Os módulos NPM estão inchados e existem muitos, mas, ao mesmo tempo, essa é a potência do ecossistema do Node. Deseja um pacote para extrair arquivos tar em um fluxo? Você conseguiu (tar-stream). Deseja um pacote de validação de dados? Você entendeu (joi). Quer trabalhar com a JWT? Você entendeu (jsonwebtoken). Gostaria de saber quanto tempo levaria para os desenvolvedores portarem seus pacotes para um sistema compatível com o Deno.

O Deno tem uma abordagem diferente para os sistemas de módulos e, de qualquer forma, tenta “instalar” os módulos NPM existentes de alguma forma, eu não veria o ponto de usar o Deno além de apenas invadir um projeto TS + Node dentro de um Docker contêiner de qualquer maneira.

De acordo com o que aprendi sobre Deno até agora, veja como fica:

Deno = (principalmente)[TypeScript+Node+Contêinerdodockerconfiguradocorretamente+bináriosexecutáveis​​únicos+[TypeScript+Node+Correctlyconfigureddockercontainer+singleexecutablebinaries+[TypeScript+Node+Contêinerdodockerconfiguradocorretamente+bináriosexecutáveis​​únicos+[TypeScript+Node+Correctlyconfigureddockercontainer+singleexecutablebinaries+ – NPM]

Bem! Vamos esfriar um pouco as coisas e deixe-me concluir este artigo.

Conclusão

Estou tão empolgado com Deno quanto todos os outros, mas quando há uma reescrita completa no tempo de execução do JavaScript, estou esperando grandes mudanças. O Deno inclui vários recursos interessantes, como a documentação automática do TypeScript, que eu pulei para mencionar, porque este post visa mostrar o outro lado da moeda. Você encontrará o restante das coisas sobre Deno em quase todos os outros artigos, mas eu acreditava que isso era algo que precisava ser dito.

Para ser honesto, o Deno parece ser um grande empreendimento para um pequeno benefício, com uma enorme dívida de transferência de módulos e bases de código npm existentes. Você concorda ou discorda de mim? Eu gostaria de saber suas opiniões. Tweet / siga-me: @mehulmpt e em Instagram também!

Paz!