A Vercel Labs lançou o scriptc, um compilador experimental licenciado sob Apache 2.0 que transforma TypeScript comum em pequenos executáveis nativos sem depender de Node, V8 ou qualquer engine JavaScript no binário.
O repositório foi criado em 22 de julho de 2026 e acumula cerca de 4,9 mil estrelas. O scriptc utiliza o compilador TypeScript real para análise e verificação de tipos, reduz programas para um IR tipado, e emite C legível, LLVM IR, assembly, objetos, executáveis nativos ou WebAssembly via WASI Preview 1.
Cada construção de código cai em uma de três categorias: compilada estaticamente por padrão, executada dinamicamente dentro de um engine quickjs-ng incorporado de aproximadamente 620KB quando --dynamic é passado para pacotes npm e qualquer código tipado, ou rejeitada no tempo de compilação com um código SC e uma sugestão de reescrita.
Benchmarks Promissores
Um benchmark do scriptc 0.0.16 contra Bun 1.3.12 e Node 24.18.0 registrou uma inicialização CLI mediana de 1,78ms versus 21,29ms para Bun e 61,78ms para Node, com memória ociosa de 1,9 MiB para um servidor node:http sem framework. Os mesmos testes revelaram que Hono exigiu --dynamic, colocando 62% do servidor em QuickJS e reduzindo a taxa de transferência para 18,4 mil requisições por segundo contra 70,5k do Bun.
Na plataforma Hacker News, um desenvolvedor relatou resultados aproximadamente 7,5 vezes mais lentos que Node 24:
"Olhando para os resultados de byte-array (melhor caso): scriptc é cerca de 7,5x mais lento que Node 24, mesmo depois que Claude tentou fazer algumas otimizações específicas do scriptc. Mas o executável inicia 12x mais rápido (1,5 ms versus 18,6 ms), usa 72x menos memória (2,5 MiB versus 181 MiB) e é um único executável de 370 KB sem dependências de runtime."
Preocupações e Críticas
Filip Pizlo argumentou que usar floats para todos os números e diferir a inferência de inteiros pula "metade do problema do JavaScript rápido", e que confiar em QuickJS é um ajuste inadequado para um projeto de desempenho, já que any é comum o suficiente para que programas reais continuem caindo na exceção.
Simon Willison observou que agentes de codificação adicionaram 918 mil linhas em uma única semana e também mencionou que construir binários pequenos e rápidos sem escrever C ou Rust "parece ser uma capacidade valiosa".
Um desenvolvedor descobriu que o coverage gerou centenas de erros em cada projeto local:
"Apesar do ódio que está recebendo, pensei em testá-lo pelo menos, e tentei em cada projeto que tenho localmente. Para cada um deles, o coverage gera centenas de erros e, portanto, é basicamente inútil. Entendo que posso escrever um projeto do zero, não usar nenhuma biblioteca de terceiros, e ele será compilado 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?"
