TypeScript 10 vezes mais rápido
(devblogs.microsoft.com)- A Microsoft anunciou uma melhoria de desempenho de 10x no TypeScript por meio da portabilidade nativa do compilador e das ferramentas
- Grande melhora no tempo de inicialização do editor, redução de 10x no tempo de build e forte queda no uso de memória
- Até meados de 2025, será lançada uma versão prévia do
tsc, e no fim de 2025 está prevista a oferta de build completo de projetos e serviço de linguagem
Contexto da melhoria de desempenho do TypeScript
- O valor central do TypeScript é a excelente experiência para desenvolvedores
- Quanto maior a base de código, maior o valor do TypeScript, mas em projetos de grande escala surgem problemas de desempenho
- Ocorrem problemas de carregamento e verificação demorados
- É necessário equilibrar inicialização rápida do editor e análise de toda a base de código
- Recursos baseados em IA precisam fornecer informações semânticas rápidas e precisas
- Aumenta a demanda por validação do estado da base de código por meio de builds via linha de comando
Plano de avanço da portabilidade nativa
- Início do trabalho de portabilidade nativa do compilador e das ferramentas do TypeScript
- Metas de melhoria de desempenho:
- Redução drástica no tempo de inicialização do editor
- Redução de até 10x no tempo de build
- Redução no uso de memória
- Meados de 2025: previsão de lançamento de uma versão prévia do
tsccom verificação de tipos pela linha de comando - Fim de 2025: previsão de suporte a build completo de projetos e serviços de linguagem
Execução de código e testes
- É possível compilar e executar o código no repositório do código TypeScript em Go
- O repositório fornece instruções para compilar e executar o
tsce o servidor de linguagem - Estão previstos updates regulares sobre os novos recursos
Quanto ficou mais rápido?
- Ao testar o tempo de build do projeto TypeScript em várias bases de código populares, surgiram os seguintes ganhos de desempenho:
- O projeto VS Code, com cerca de 1,5 milhão de linhas de código, passou de 77,8 segundos para 7,5 segundos, ficando cerca de 10,4x mais rápido
- O projeto Playwright, com cerca de 350 mil linhas de código, passou de 11,1 segundos para 1,1 segundo, com melhora de cerca de 10,1x
- O projeto TypeORM, com cerca de 270 mil linhas de código, passou de 17,5 segundos para 1,3 segundo, com melhora de cerca de 13,5x
- O projeto date-fns, com cerca de 100 mil linhas de código, passou de 6,5 segundos para 0,7 segundo, com melhora de cerca de 9,5x
- O projeto tRPC, com cerca de 18 mil linhas de código, passou de 5,5 segundos para 0,6 segundo, com melhora de cerca de 9,1x
- O projeto rxjs, com cerca de 2 mil linhas de código, passou de 1,1 segundo para 0,1 segundo, com melhora de cerca de 11x
- Embora os recursos ainda não estejam completos, espera-se uma melhoria de desempenho superior a 10x na maioria das bases de código
- Isso permite verificação de tipos e navegação de código mais rápidas
- Também pode viabilizar integração com ferramentas de IA e suporte a refatorações avançadas
Melhoria de desempenho no editor
- Melhora na velocidade de carregamento e resposta do editor
- Tempo de carregamento com base no codebase do Visual Studio Code:
- Atual: 9,6 segundos → versão nativa: 1,2 segundo (cerca de 8x melhor)
- O uso de memória também caiu cerca de 50%
- Espera-se melhora no desempenho de tarefas do serviço de linguagem, como autocomplete, quick info e ir para a definição
- O trabalho de migração está em andamento com base no Language Server Protocol (LSP)
Roteiro de versões
- O TypeScript 5.8 já foi lançado, e o TypeScript 5.9 deve sair em breve
- A base de código do TypeScript em JS continuará em desenvolvimento na linha 6.x
- Quando a base de código nativa estiver estabilizada, o lançamento está previsto como TypeScript 7.0
- TypeScript 6 → versão baseada em JS
- TypeScript 7 → versão baseada em código nativo
- Mesmo após o lançamento do TypeScript 7, a linha 6.x será mantida por um período
Próximos passos
- Está prevista a divulgação de mais informações sobre desempenho, API do compilador e LSP
- É possível conferir perguntas frequentes no FAQ do GitHub
- Está previsto um AMA em 13 de março de 2025 no Discord da comunidade TypeScript (10h PDT | 17h UTC)
24 comentários
Achei que muita gente estava fazendo isso sem nem pensar em
structural typing.Para reescrever em uma linguagem de
nominal typingcomo C# ou Rust, seria preciso mudar demais a estrutura fundamental do projeto, então certamente não seria fácil.Entre as linguagens que adotam
structural typing, as únicas que provavelmente conseguiriam entregar desempenho superior ao ecossistema JavaScript existente seriam C++ ou Go, mas, considerando também a produtividade, não há alternativa.Em algum momento, comecei a mexer menos com TS, mas ao ver uma notícia dessas, fico curioso de novo.
No
ts, se você sair usandoanyà vontade, exceto nos casos realmente inevitáveis, no fim não é muito diferente de usar vanilla... rsParece que a polêmica está bem quente, tanto que o próprio Anders Hejlsberg deixou um comentário
https://github.com/microsoft/typescript-go/…
Alguém que gostaria que, ao compilar com TypeScript, o resultado saísse direto como binário
Sou leigo em front-end... isso é diferente do swc?
O SWC se concentra em gerar código JavaScript compatível, como o Babel, e até em fazer bundling; já isto se concentra em transformar código TypeScript em JavaScript ou verificar erros de tipo.
Dizem que é preciso comer a própria comida, ou seja, usar diretamente aquilo que você mesmo criou. Mas, no caso de uma linguagem, isso realmente faz pensar um pouco.
Na minha opinião pessoal, como os runtimes de JS que servem de base para o ts (por exemplo, spidermonkey, v8) em sua maioria são escritos em C++ e não existe runtime implementado em JS,
sem falar que até a compilação de js -> js fica lenta demais usando pure JS, então quando você vê todo mundo migrando para coisas como esbuild e afins,
acabo achando que, no ts também, talvez não faça tanto sentido insistir em comer a própria comida de cachorro.
Fico preocupado que, mais tarde, a manutenção do codebase TypeScript existente acabe sendo negligenciada.
Que boa notícia! Curiosamente, a linguagem TypeScript da MS parece fazer muitas escolhas realmente inesperadas, ao contrário do que se imaginava. Do ponto de vista da MS, sendo praticamente o seu primeiro projeto open source, também pareceu uma decisão muito sensata tentar complementar o JS, ao contrário do Dart do Google, que buscava substituí-lo; e nesta nova linguagem para port nativo, embora devesse ter várias linguagens próprias à disposição, também surpreende o fato de terem escolhido o Go, do Google.
Ué, acho que já existe algo do lado do Deno que criou um toolchain baseado em Rust... por que de repente Go?
Parece que você está falando de um runtime como o Node, mas o que está sendo mencionado aqui é o compilador da própria linguagem TS.
Ah, lendo um pouco mais o texto, acho que fiquei confuso porque havia uma parte falando que o editor ficaria mais rápido.
tscficou 10 vezes mais rápido. Ou seja, o tempo de transpilaçāo dets -> jsfoi muito reduzido.ts, como o VSCode, a velocidade fica muito maior. Ou seja, significa que a lógica que compartilha recursos dotsc, como a verificação de sintaxe dots, ficou mais rápida.Já tive a experiência de usar tipos genéricos compostos por recursão e, por causa da lentidão, recorrer a alternativas. Se for 10 vezes mais rápido, fico na expectativa de que esse tipo de ponto também melhore.
A discussão sobre por que Go é interessante.
https://github.com/microsoft/typescript-go/discussions/411
Também há muitas coisas a considerar...
Pois é, mas também dá pra entender como os desenvolvedores de .NET se sentem...
Os desenvolvedores de .NET e Rust ficaram bem irritados.
Entendo o .NET, mas acho que Rust está mais na mesma posição que Go. De qualquer forma, imagino que os projetos e bibliotecas de JS relacionados a Go que já existiam também tenham influenciado a decisão.
O desenvolvimento da linguagem C# não parou, mas dá muito a sensação de que os frameworks que usam C# estão sendo deixados de lado.
Escreva em Go~
Estou muito animado.
Comentários do Hacker News
tscrápido em Ruststc: descontinuadoezno: em desenvolvimento ativo e sem o objetivo de ter correspondência 1:1 com otsc