Deno
O ambiente de desenvolvimento do Deno e o próprio Deno são rudimentares e não devem ser usados em ambiente de produção.
Considerando o tempo de desenvolvimento do Deno, a equipe do Deno teve um desempenho insatisfatório,
a ponto de o Node.js ter gradualmente alcançado as funcionalidades do Deno, e surgiram concorrentes como o Bun no mesmo nicho.
É difícil ter confiança no futuro do Deno.
a ponto de o Node.js ter gradualmente alcançado as funcionalidades do Deno, e surgiram concorrentes como o Bun no mesmo nicho.
É difícil ter confiança no futuro do Deno.
- Desenvolvido em Rust.
- API o mais compatível possível com o ambiente Web.
- Ferramentas opinativas
deno fmt,deno lint,deno test,deno bench. - Seguro por padrão, com um sistema de permissões granular, suportando solicitações dinâmicas de permissão.
Atualmente, devido a muitos campos internos usados pelo Deno, as permissões granulares podem ser muito inconvenientes de usar, e o desenvolvedor acabará sendo forçado a usar permissões de granularidade grossa. - Suporte nativo ao TypeScript, o que está se tornando cada vez mais importante à medida que a comunidade JavaScript migra para o TypeScript.
- Compatibilidade com Node.js.
As funcionalidades integradas do Deno geralmente carecem de testes rigorosos, dependendo do feedback da comunidade para correção de erros.
Embora o LTS esteja mostrando sinais de se tornar mais curto em vários projetos, a declaração de 6 meses como LTS para o Deno 2 no lançamento ainda é risível.
A Deno Land Inc. está interessada em desenvolver clones/alternativas de outros produtos do ecossistema.
Esses produtos claramente carecem de consideração cuidadosa, e sua manutenibilidade é questionável.
Esses produtos claramente carecem de consideração cuidadosa, e sua manutenibilidade é questionável.
Essa tendência também afeta o próprio Deno; por exemplo, a compatibilidade com Node.js é um exemplo típico de marketing exagerado que se sobrepõe à entrega real:
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
Projetos Deno um pouco maiores podem fazer com que os tempos de resposta do LSP diminuam, facilmente desmotivando desenvolvedores que desejam usar o Deno.
Em contraste, projetos baseados em Node.js e TypeScript não apresentam problemas semelhantes.
A configuração padrão do LSP do Deno é bastante conservadora; por exemplo, o valor padrão de
documentPreloadLimit é 1000, o que pode ser facilmente excedido no desenvolvimento real.O design do modelo de stream WHATWG é bastante rudimentar, muito inferior às streams do Node.js.
Por exemplo, os usuários nem conseguem saber se uma stream está fechada, ou quando ela foi fechada.
Os módulos determinam seu protocolo com base em como são importados.
Quando um módulo é importado como um módulo local, seu
Quando um módulo é importado como um módulo remoto, seu
Quando um módulo é importado como um módulo local, seu
import.meta.url é do protocolo file.Quando um módulo é importado como um módulo remoto, seu
import.meta.url é do protocolo http/https.O problema é que um número considerável de APIs suporta apenas um protocolo; por exemplo,
Essa situação leva a uma maior carga cognitiva para os desenvolvedores ao usar
Deno.readFile suporta apenas o protocolo file, não http/https.Essa situação leva a uma maior carga cognitiva para os desenvolvedores ao usar
import.meta.url. O problema fundamental é que o Deno não expõe o caminho local dos módulos importados (em cache), o que é um problema que poderia ser resolvido no nível do design.https://github.com/denoland/deno/issues/5987
De forma bastante trágica, o Deno resolve os problemas relacionados à leitura de arquivos ao fazer com que a função fetch suporte o protocolo file.
https://github.com/denoland/deno/issues/3196
O TypeScript não suporta a compilação de caminhos de módulo com extensão
e os caminhos de módulo do Deno devem ter a extensão
Portanto, o código de projetos TypeScript projetados para módulos Node.js não funcionará no Deno.
.ts para extensão .js,e os caminhos de módulo do Deno devem ter a extensão
.ts.Portanto, o código de projetos TypeScript projetados para módulos Node.js não funcionará no Deno.
O TypeScript 5 começou a suportar a opção de configuração allowImportingTsExtensions, que permite o uso da extensão
mas essa opção de configuração é limitada a ser usada apenas quando configurada como noEmit ou emitDeclarationOnly,
o que significa que, ao usar a extensão
.ts em projetos,mas essa opção de configuração é limitada a ser usada apenas quando configurada como noEmit ou emitDeclarationOnly,
o que significa que, ao usar a extensão
.ts, o código utilizável para Node.js não pode ser gerado.O registro de pacotes JavaScript promovido oficialmente pelo Deno.
Embora o JSR se apresente como um registro de pacotes JavaScript moderno, ele ainda é apenas a versão do Deno do npm.
O JSR não é um superconjunto do npm, assim como o TypeScript não é um superconjunto do JavaScript.
Embora o JSR se apresente como um registro de pacotes JavaScript moderno, ele ainda é apenas a versão do Deno do npm.
O JSR não é um superconjunto do npm, assim como o TypeScript não é um superconjunto do JavaScript.
Este registro visa em grande parte resolver os problemas existentes de gerenciamento de dependências do Deno (o bumerangue que Ryan Dahl lançou em 2018 finalmente o atingiu):
diferentes módulos importam dependências de diferentes registros, ou importam diferentes subversões da mesma dependência do registro devido à falta de SemVer.
Isso leva ao inchaço do projeto (o que aumenta a carga do LSP) e à falta de igualdade referencial entre as dependências importadas.
diferentes módulos importam dependências de diferentes registros, ou importam diferentes subversões da mesma dependência do registro devido à falta de SemVer.
Isso leva ao inchaço do projeto (o que aumenta a carga do LSP) e à falta de igualdade referencial entre as dependências importadas.
A Deno oficial afirma que o registro de pacotes original deno.land/xainda pode ser usado,
mas considerando que a biblioteca padrão oficial std parou de ser atualizada em deno.land/x, espera-se que continuar publicando pacotes em deno.land/x não faça sentido.
mas considerando que a biblioteca padrão oficial std parou de ser atualizada em deno.land/x, espera-se que continuar publicando pacotes em deno.land/x não faça sentido.
Agora é possível (assim como o suporte para módulos npm adicionado no Deno 1.28) usar o prefixo dedicado
jsr:, que simplifica a URL.https://github.com/oakserver/oak
https://fresh.deno.dev/
Framework Web full-stack lançado oficialmente pelo Deno em 2022, comparável ao Next.js.
Não é recomendado usá-lo porque:
- Quase nenhuma biblioteca React é testada para suporte ao Deno.
- Internamente usa Preact, uma variante leve do React, que é um caminho tecnológico sem futuro.
Deno pode importar JSDOM via CDN.
import { JSDOM } from 'https://esm.sh/jsdom@22.1.0'https://github.com/b-fuze/deno-dom
Este projeto é um binding para o pacote html5ever do Rust.
SQLite usando Deno FFI.
Vantagens:
- A interface é basicamente a mesma do better-sqlite3.
- Alto desempenho.
SQLite compilado para WASM.
Vantagens:
- Permissões mínimas.
- Multiplataforma.
Desvantagens:
- Limitado pela API do sistema de arquivos do Deno.
- Muito poucas opções de compilação habilitadas por padrão, provavelmente exigindo compilação própria.
Desde o Deno 1.21, a biblioteca padrão tem fornecido uma quantidade considerável de funcionalidades de teste,
o que na maioria dos casos elimina a necessidade de usar bibliotecas de terceiros.
Essa escolha técnica do Deno evita efetivamente o problema de vendor lock-in dos testes do Node.js.
o que na maioria dos casos elimina a necessidade de usar bibliotecas de terceiros.
Essa escolha técnica do Deno evita efetivamente o problema de vendor lock-in dos testes do Node.js.
A biblioteca padrão atual já suporta estilo BDD, mock/stub, correspondência de snapshots, simulação de temporizadores:
https://deno.land/std@0.181.0/testing
https://deno.land/std@0.181.0/testing
https://github.com/denoland/deno_std/issues/1779
Deno fornece um comando embutido
deno bundle para empacotar um projeto em um único arquivo de script.Ryan Dahl uma vez propôs a remoção deste comando, mas essa ideia foi posteriormente retirada.
No entanto, na v1.31, o comando ainda foi listado como obsoleto sem discussão da comunidade, e o manual oficial sugeriu o uso de esbuild em seu lugar.
No entanto, na v1.31, o comando ainda foi listado como obsoleto sem discussão da comunidade, e o manual oficial sugeriu o uso de esbuild em seu lugar.
Na v2.4, o deno bundle retornou inexplicavelmente, usando esbuild como sua tecnologia subjacente.
Na v2.5, foi adicionado suporte para arquivos HTML como pontos de entrada para o empacotamento.
Na v2.5, foi adicionado suporte para arquivos HTML como pontos de entrada para o empacotamento.
Ao executar um script com o comando
Se o script for primeiro compilado via
deno run, o verificador de tipos TypeScript é carregado, o que faz com que o processo do deno use mais memória.Se o script for primeiro compilado via
deno compile e depois executado, o uso de memória do script melhorará significativamente.