I dati tecnici e le note di misurazione sono mantenuti in inglese per evitare discrepanze tra le traduzioni.

Compile TypeScript to a Binary

Perry turns supported TypeScript into target-specific machine code. Native output needs no external Node.js installation or JavaScript engine, but it does statically link the Perry runtime and garbage collector.

$ perry compile main.ts

✓ Example executable written: main (size varies)

$ ./main

Hello, World!

Three different meanings of “compile”

Transpile

TypeScript compilers and bundlers can emit JavaScript. That output still runs in Node.js, Bun, Deno, or a browser.

Bundle a runtime

Bun, Deno, and Node SEA can produce one file by packaging the program with their runtime or executable machinery. Consult each tool's documentation for its exact format.

Ahead-of-time compile

Perry parses with SWC and uses LLVM to emit machine code for supported behavior, then links the Perry runtime and GC.

What is actually in a Perry binary?

The file contains compiled application code plus the Perry runtime pieces required by the program. It is therefore accurate to say that no external JavaScript runtime installation is needed; it is not accurate to say that Perry has no runtime at all. Native builds use a garbage collector, object and string support, async machinery, and other linked helpers. The optional V8 fallback adds an embedded JavaScript engine when enabled.

The public examples show a hello-world binary around ~330 KB and the Mango application around ~7 MB. Those are examples, not a promised range. Output size changes with the target, imports, build profile, standard-library surface, debug information, and optional V8 fallback.

Compatibility and targets

Perry documents 11 targets plus a separate HarmonyOS preview. Web and WASM are aliases for one backend. Platform SDKs, host tools, signing credentials, and UI/API depth differ by target, so cross-compilation is not an unconditional “build any target from any host” promise.

Perry reports ~97% of its tracked Node suite across 53 modules and roughly ~50 package/API implementations. That does not mean every npm package or JavaScript feature works. Run perry check and test the real application against the published limitations.

Primary sources

Published measurements

Current public results include wins, mixed results, and losses. Treat microbenchmarks as workload-specific measurements, not a universal speed claim.

MetricaPerryNode.jsBun
Dimensione binario~330 KB hello world; ~7 MB MangoApplication plus an installed Node.js runtimeStandalone executable embeds the Bun runtime
Tempo di avvio~3.2 ms*Engine boot and warmup; workload-dependentEngine boot and warmup; workload-dependent
Dipendenze runtimeStatically linked Perry runtime + GCExternal Node.js runtimeEmbedded Bun / JavaScriptCore runtime
Overhead memoriaWorkload-dependentWorkload-dependentWorkload-dependent

* Measured runtime-only macOS hello world on an Apple M-series host (5.0 → 3.2 ms after removing unused dynamic-library links). Application startup varies.

Full public suite: wins and losses

Perry 0.5.1355 · Node.js 22.23.1 · Bun 1.3.14 · Apple M1, 8 GB · 2026-08-08

Lower wall-clock median is better. Five complete process samples; correctness checks passed. Benchmark names and descriptions remain English technical identifiers.

BenchmarkPerryNode.jsBunResult
factorial
Modular accumulation
94 ms95 ms95 msWin vs both
method calls
Class method dispatch
9 ms10 ms8 msMixed
closure
Closure creation and invocation
47 ms49 ms49 msWin vs both
binary trees
Tree allocation and traversal
4 ms6 ms6 msWin vs both
string concat
String append loop
2 ms4 ms1 msMixed
prime sieve
Sieve of Eratosthenes
28 ms6 ms5 msLoss vs both
mandelbrot
Complex-number iteration
22 ms24 ms28 msWin vs both
matrix multiply
Matrix multiplication
85 ms33 ms33 msLoss vs both
JSON roundtrip
Parse and stringify ~1 MB JSON
184 ms380 ms220 msWin vs both

Validate your application

Install Perry, run its compatibility check, and measure the actual output you plan to ship.

Get started