Vercel lança scriptc, compilador que transforma TypeScript em binário nativo sem motor JS

A Vercel Labs publicou o scriptc, um compilador experimental sob licença Apache 2.0 que pega TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → comum e gera executáveis nativos pequenos, sem Node.js, sem V8 e sem nenhum motor JavaScript embutido no binário final. O repositório foi criado em 22 de julho de 2026 e já acumula cerca de 4,9 mil estrelas no GitHub, segundo o InfoQ.

Como funciona: três destinos para cada linha de código

O scriptc reaproveita o compilador oficial do TypeScript para fazer parsing e checagem de tipos, depois reduz o programa a uma representação intermediária tipada (IR) que pode virar código C legível, LLVM IR, assembly, objetos, executáveis nativos ou WebAssembly via WASI Preview 1.

Cada trecho de código cai em um de três caminhos: é compilado estaticamente por padrão; roda dinamicamente dentro de um motor quickjs-ng embutido (cerca de 620KB) quando a flag --dynamic é usada, o que é obrigatório para pacotes npm e qualquer código não totalmente tipado; ou é rejeitado na compilação, com um código de erro SC e uma sugestão de reescrita. Na prática, isso significa que projetos que dependem pesadamente de bibliotecas do npm ou de tipos dinâmicos (any) acabam empurrados para dentro do QuickJS, que é exatamente o motor que o scriptc tenta evitar.

O projeto exige Node.js 24 ou superior para instalação (npm install -g scriptc), e a página de limitações documenta divergências deliberadas em relação ao Node: strings são armazenadas em UTF-8, a memória é gerenciada por contagem de referências em vez de garbage collector, Object.keys respeita a ordem de declaração, e process.argv[0] retorna "scriptc" em vez do caminho do executável Node. Há também uma flag experimental, --npm-static, que tenta compilar pacotes nomeados para fora dessa "ilha" dinâmica.

Os números: startup rápido, mas nem tudo é vantagem

Um benchmark citado pelo InfoQ comparou o scriptc 0.0.16 com Bun 1.3.12 e Node 24.18.0. O tempo mediano de startup de CLI ficou em 1,78ms para o scriptc, contra 21,29ms do Bun e 61,78ms do Node. A memória ociosa de um servidor node:http sem framework, compilado pelo scriptc, ficou em 1,9MiB.

O problema aparece quando entra uma biblioteca real: rodando o framework Hono, que exige --dynamic, 62% do servidor foi parar dentro do QuickJS, derrubando o throughput para 18,4 mil requisições por segundo, contra 70,5 mil do Bun no mesmo teste.

No Hacker News, um desenvolvedor relatou um cenário parecido rodando um benchmark de arrays de bytes: o scriptc ficou cerca de 7,5 vezes mais lento que o Node 24, mesmo depois de tentativas de otimização assistidas por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. Em compensação, o executável iniciou 12 vezes mais rápido (1,5ms contra 18,6ms), usou 72 vezes menos memória (2,5MiB contra 181MiB) e ficou em um único arquivo de 370KB, sem dependências de runtime, segundo o comentário reproduzido pelo InfoQ.

A comunidade não poupou críticas

Filip Pizlo, conhecido por seu trabalho no motor JavaScriptCore da Apple, argumentou que usar float para todos os números e adiar a inferência de inteiros "pula metade do problema de fazer JS rápido", e que depender do QuickJS é uma escolha ruim para um projeto de performance, já que o tipo any é comum o suficiente para que programas reais continuem caindo nessa ilha dinâmica.

Simon Willison, por outro lado, destacou um ângulo mais positivo: agentes de codificação somaram 918 mil linhas de código no projeto em uma única semana, e ele considera que construir binários pequenos e rápidos sem escrever C ou Rust "parece uma capacidade valiosa".

Já um terceiro desenvolvedor testou o compilador contra projetos locais reais e não escondeu a frustração: a cobertura gerou centenas de erros em cada um deles. Na avaliação dele, reproduzida pelo InfoQ, dá para escrever um projeto do zero sem bibliotecas de terceiros e compilar para binário, "mas então por que não usar Rust, Go, Zig, D, C, V, Ada, C++, Nim, Swift, Kotlin Native, Haskell... literalmente qualquer coisa projetada para ser compilada e compilada bem?"

O risco de virar mais um projeto abandonado

Uma preocupação recorrente nos comentários é a longevidade do scriptc. A comparação inevitável é com o zerolang, outro projeto da própria Vercel que parou de receber commits poucas semanas após o lançamento, segundo relatos citados pelo InfoQ.

Remo Jansen tentou um teste de estresse mais ambicioso: compilar o próprio compilador do TypeScript 6 usando o scriptc. A tentativa falhou com um erro interno do compilador. Antes de travar, ele mediu um cold start de 3,6ms contra os 48,9ms do Node, mas o tempo de computação ficou em 2,33 segundos, bem mais lento que o runtime tradicional.

O scriptc atualmente compila para macOS, Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, Windows e WASI Preview 1, e é validado por testes diferenciais que comparam stdout, stderr e código de saída byte a byte contra o Node. O próprio projeto se declara explicitamente experimental, e a documentação está em scriptc.dev.

O que muda pra quem programa no Brasil

Para quem trabalha com edge computing e funções serverless, cold start é dinheiro e latência: provedores cobram por tempo de execução e usuários em conexões mais lentas sentem cada milissegundo de startup. Um binário que sobe em 1,78ms em vez de 61,78ms é uma proposta atraente para funções de borda rodando fora dos grandes data centers, cenário comum em regiões do Brasil mal servidas por PoPs de CDN.

Mas a ressalva dos próprios benchmarks é o ponto central: assim que o projeto depende de um pacote do npm, boa parte do ganho de performance desaparece dentro do QuickJS embutido. Isso limita o scriptc, por enquanto, a nichos bem específicos: CLIs internas, scripts de automação e ferramentas de linha de comando escritas do zero, sem dependências pesadas, onde distribuir um único executável de poucas centenas de kilobytes é mais prático do que pedir para o time instalar Node.js. Para APIs e serviços que usam frameworks como Hono, Express ou qualquer coisa com dependências de terceiros, o ganho de startup vem acompanhado de uma queda de throughput que pode não valer a pena.

Dado o histórico do zerolang, também vale cautela antes de colocar o scriptc em produção: é um projeto de dois meses, ainda em versão 0.0.x, sem garantia de manutenção de longo prazo por parte da Vercel. Para times avaliando ferramentas de compilação nativa hoje, Rust, Go e Zig continuam sendo as opções com ecossistema maduro e sem essa incerteza.

Fonte: InfoQ