Um documento surgiu hoje apontando que o Deno deixar\u00e1 de usar o TypeScript em seu c\u00f3digo interno, citando v\u00e1rios problemas com o ambiente atual. Os problemas mencionados envolvem tempos de compila\u00e7\u00e3o do TypeScript, estrutura\u00e7\u00e3o e organiza\u00e7\u00e3o do c\u00f3digo, entre outros. No futuro, o Deno usar\u00e1 JavaScript puro para seu c\u00f3digo interno.<\/p>\n
As situa\u00e7\u00f5es desfavor\u00e1veis \u200b\u200bque a equipe Deno est\u00e1 enfrentando atualmente ao usar o TypeScript<\/a> para seu c\u00f3digo interno s\u00e3o:<\/p>\n O tempo de compila\u00e7\u00e3o do TypeScript ao alterar os arquivos leva v\u00e1rios minutos, tornando a compila\u00e7\u00e3o cont\u00ednua um processo extremamente lento<\/p>\n<\/li>\n A estrutura Typescript que eles est\u00e3o usando nos arquivos de origem que criam o execut\u00e1vel real do Deno e as APIs voltadas para o usu\u00e1rio est\u00e3o criando problemas de desempenho em tempo de execu\u00e7\u00e3o<\/p>\n<\/li>\n O TypeScript n\u00e3o est\u00e1 se mostrando \u00fatil para organizar o c\u00f3digo Deno. Pelo contr\u00e1rio, a equipe Deno est\u00e1 experimentando o efeito oposto. Um dos problemas mencionados \u00e9 que eles acabaram com classes de corpo independentes duplicadas em dois locais https:\/\/github.com\/denoland\/deno\/issues\/4748<\/a><\/p>\n<\/li>\n O c\u00f3digo interno e as declara\u00e7\u00f5es TypeScript de tempo de execu\u00e7\u00e3o devem ser mantidos manualmente em sincronia, pois o compilador TypeScript n\u00e3o \u00e9 \u00fatil para gerar os arquivos d.ts<\/p>\n<\/li>\n Eles est\u00e3o mantendo dois hosts do compilador TS: um para o c\u00f3digo interno do Deno e outro para o c\u00f3digo do usu\u00e1rio externo, embora ambos tenham um objetivo semelhante<\/p>\n<\/li>\n<\/ul>\n A equipe Deno<\/a> tem como objetivo remover todas as verifica\u00e7\u00f5es de tipo TS em tempo de constru\u00e7\u00e3o e empacotamento para o c\u00f3digo interno do Deno. Eles est\u00e3o ansiosos para mover todo o c\u00f3digo de tempo de execu\u00e7\u00e3o para um \u00fanico arquivo JavaScript<\/a>. No entanto, eles ainda usar\u00e3o um arquivo d.ts complementar para manter as defini\u00e7\u00f5es de tipo e a documenta\u00e7\u00e3o.<\/p>\n Vale a pena mencionar que o Deno deixar\u00e1 de usar o TypeScript apenas para o c\u00f3digo interno do Deno: o c\u00f3digo do usu\u00e1rio do Deno ainda estar\u00e1 no TypeScript e, portanto, ser\u00e1 verificado.<\/p>\n Embora o TypeScript \u00e0s vezes seja visto como uma vers\u00e3o aprimorada do JavaScript, este caso mostra que, na verdade, n\u00e3o \u00e9. Tem falhas como qualquer outra linguagem. Um dos mais importantes \u00e9 o seu tempo de compila\u00e7\u00e3o lento. Embora pequenos projetos possam n\u00e3o ter um grande aumento no tempo de compila\u00e7\u00e3o ao alternar de JavaScript puro para TypeScript, isso ser\u00e1 percept\u00edvel em grandes projetos, como um aplicativo React complexo.<\/a> Dado o grande tamanho de seu tempo de execu\u00e7\u00e3o, n\u00e3o \u00e9 de surpreender que o Deno pare de usar o TypeScript.<\/p>\n A seguran\u00e7a da verifica\u00e7\u00e3o de tipos durante o desenvolvimento tem seu custo no momento da compila\u00e7\u00e3o. N\u00e3o \u00e9 \u00e0 toa que o projeto TypeScript possui um extenso documento sobre como abordar e melhorar o tempo de compila\u00e7\u00e3o<\/a>. Uma das abordagens mais interessantes \u00e9 usar Project References<\/a>, que permite aos desenvolvedores dividir um grande peda\u00e7o de c\u00f3digo TypeScript em peda\u00e7os menores.<\/p>\n A discuss\u00e3o completa sobre a decis\u00e3o de remover o TypeScript do c\u00f3digo interno do Deno e usar JavaScript pode ser encontrada neste documento<\/a>, onde Ryan Dahl e colaboradores discutem o problema, sua solu\u00e7\u00e3o e como ele ser\u00e1 implementado.<\/p>\n\n
Removendo TypeScript no c\u00f3digo interno do Deno<\/h2>\n
Leia mais sobre por que o Deno deixar\u00e1 de usar o TypeScript<\/h2>\n