Resumo rápido
- O scriptc é um projeto real e open source da Vercel Labs, disponível no GitHub sob licença Apache 2.0, que compila TypeScript comum diretamente para binário nativo.
- Ele não é o único nessa linha: Bun já tem o
bun build --compilee o Deno tem odeno compile, mas ambos embutem o runtime completo dentro do executável. O scriptc tenta eliminar esse runtime quando o código é estaticamente analisável.- É um projeto experimental. Código que usa recursos muito dinâmicos do JavaScript cai num modo com engine embutida (quickjs-ng) ou simplesmente não compila, então não é algo para colocar em produção crítica ainda.
Você já deve ter visto alguma variação dessa frase: “compilar TypeScript direto para binário nativo, sem runtime JavaScript embutido”. A Vercel Labs, braço experimental da empresa por trás do Next.js, publicou recentemente o scriptc, um compilador open source que se propõe a fazer exatamente isso. Para quem está acostumado com Node.js, Deno ou Bun, vale entender o que muda de verdade.
O código está no repositório oficial no GitHub, com documentação em scriptc.dev, e o projeto já acumulou milhares de estrelas e virou destaque no Hacker News dias depois do lançamento.
O que o scriptc faz de diferente
A ideia central do scriptc é evitar embarcar um engine JavaScript completo (V8, JavaScriptCore ou similar) dentro do executável final. Em vez disso, ele usa o próprio tsc (o compilador oficial do TypeScript) para checar tipos, converte o código para uma representação intermediária tipada e depois gera código C, que é compilado por um compilador C como o clang até virar binário nativo.
Segundo a documentação oficial, o resultado é um executável que se comporta “byte a byte como no Node” para o código que consegue compilar estaticamente, mas sem carregar o peso de um interpretador JavaScript junto.
O modelo de três níveis: estático, dinâmico ou rejeitado
Um ponto importante que costuma passar batido em resumos rápidos do projeto: o scriptc não tenta compilar 100% do TypeScript de forma estática a qualquer custo. Ele classifica cada trecho de código em um de três grupos:
- Compila estaticamente: vira instrução nativa de máquina, sem overhead de runtime.
- Executa dinamicamente: quando você habilita a flag
--dynamic, um engine JavaScript leve (o quickjs-ng) é embutido no binário para rodar dependências do npm ou código que depende de avaliação dinâmica.
- É rejeitado na compilação: se o código usa um padrão que o compilador não consegue resolver e você não habilitou o modo dinâmico, o build falha com uma mensagem específica sobre o que está bloqueando.
O comando scriptc coverage mostra, linha por linha, o que compilou de forma estática e o que ainda depende do modo dinâmico, o que ajuda a decidir se vale a pena adaptar o código para ganhar mais performance.
Comparação com Bun e Deno
Vale a pena separar isso de outras ferramentas que também prometem “TypeScript virando executável”, porque a abordagem não é idêntica:
O bun build --compile empacota seu código, todas as dependências e uma cópia do runtime do Bun dentro de um único arquivo. Funciona muito bem para distribuir CLIs sem exigir que o usuário instale o Bun, mas o binário carrega o runtime inteiro.
O deno compile faz algo parecido: ele embute seu script dentro de um binário do runtime do Deno (chamado denort), incluindo dependências e recursos necessários.
O scriptc tenta ir um passo além: quando o código é estaticamente analisável, ele não embute runtime nenhum, só código nativo. Isso tende a gerar binários bem menores e com startup mais rápido, mas em troca você perde parte da flexibilidade dinâmica que o Node, o Bun e o Deno oferecem por padrão.
Limitações reais do projeto
Como é esperado de uma ferramenta focada em compilação estática, o scriptc não suporta o universo completo do TypeScript/JavaScript sem ativar o modo dinâmico. Recursos como eval(), reflexão complexa ou manipulação muito dinâmica de propriedades de objetos exigem o fallback com o engine embutido, ou simplesmente não compilam.
Isso muda a forma como você escreve o código: para aproveitar o ganho de performance e tamanho, vale pensar em análise estática desde o início, evitando padrões excessivamente dinâmicos que são comuns no ecossistema JavaScript. Esse tipo de trade-off entre flexibilidade e desempenho não é exclusivo do scriptc: você vê algo parecido em projetos como o Incremental, da Jane Street, que também exige repensar como o código é estruturado para ganhar performance em troca de menos flexibilidade dinâmica.
Vale a pena testar agora?
O próprio projeto se posiciona como experimental. Não é recomendado para produção crítica ainda, mas para quem gosta de acompanhar tooling novo, é uma boa oportunidade de ver uma abordagem diferente de compilação chegando ao ecossistema TypeScript. Já vimos esse padrão antes: projetos experimentais e promissores que ainda não estão prontos pra produção, como o codec Misa77, que promete descompressão mais rápida que o LZ4 mas também recomenda cautela antes de usar em produção.
Se você constrói CLIs, ferramentas internas ou utilitários que se beneficiariam de binários menores e startup quase instantâneo, especialmente em cenários sensíveis a cold start como serverless functions, vale acompanhar o repositório e testar em projetos não críticos primeiro. Se o seu caso de uso já envolve processar grandes volumes de dados em vez de só startup rápido, pode fazer mais sentido olhar para ferramentas de análise como o ClickHouse, que resolve um problema de performance diferente.
Perguntas frequentes
O scriptc é um projeto real da Vercel?
Sim. É um projeto open source publicado pela Vercel Labs, disponível no GitHub em vercel-labs/scriptc, sob licença Apache 2.0.
O scriptc substitui o Node.js, o Bun ou o Deno?
Não. Ele resolve um problema específico (gerar binário nativo sem runtime embutido para código estaticamente analisável), enquanto Node, Bun e Deno continuam sendo runtimes completos, com suporte total a JavaScript dinâmico, módulos carregados em tempo de execução e REPL.
Dá para usar bibliotecas do npm com o scriptc?
Depende. Código muito dinâmico ou dependências do npm que não sejam estaticamente analisáveis exigem o modo --dynamic, que embute um engine JavaScript leve (quickjs-ng) no binário.
O scriptc está pronto para produção?
O próprio projeto se descreve como experimental. Para produção, avalie com cautela e teste bastante antes, principalmente em código que dependa de padrões dinâmicos.
Quais são as alternativas mais maduras para compilar TypeScript em executável?
O bun build --compile (Bun) e o deno compile (Deno) já existem há mais tempo e embutem o runtime completo no binário final, o que os torna mais previsíveis, embora gerem executáveis maiores.
Conclusão
O scriptc mostra que ainda há espaço para repensar como distribuímos código TypeScript, mesmo num ecossistema que já tem Node, Bun e Deno maduros. A proposta de eliminar o runtime embutido quando o código permite é interessante, mas o projeto ainda é jovem e experimental. Se você depende de startup rápido e binários pequenos, vale colocar na lista de coisas para testar, sem pressa de trocar sua stack de produção por ele ainda.
Recomendação relacionada
Manual do Hacker: Aprenda a Proteger Aplicações Web
Um manual prático sobre técnicas de pentest e proteção de aplicações web, relevante pro tipo de vulnerabilidade discutida neste artigo.
Ver na Amazon →Como Associado Amazon, Visão Binária pode ganhar uma comissão sobre compras qualificadas feitas através deste link, sem custo adicional pra você.