NewsDeveloper ToolsProgramming Languages

Perry: TypeScript Compiles to Native Binaries Without Node

Perry compiler pipeline: TypeScript source code flowing through SWC and LLVM into a native binary, with performance stats showing 1ms startup and 2-5MB binary size
Perry compiles TypeScript directly to native executables using SWC and LLVM — no Node.js runtime required

A Rust-written compiler called Perry landed on Hacker News this week with a bold claim: compile TypeScript directly to native executables using SWC and LLVM, with no Node.js, no V8, and no runtime on the target machine. One binary. 1ms startup. 2–5MB on disk. Benchmark performance that runs alongside Rust and C++. MIT licensed.

This is not a bundler. It is not a clever wrapper around Node. Perry is an ahead-of-time (AOT) compiler that emits real machine code — the same pipeline architecture that production systems languages use.

How the Pipeline Actually Works

Perry uses SWC — the Rust-based TypeScript parser — to parse source files into an AST. That AST is lowered to a High-Level Intermediate Representation (HIR), run through optimization passes, and then emitted as LLVM IR. LLVM handles the rest: platform-specific machine code for macOS ARM64/x64, Linux, Windows, iOS, Android, and more.

There is no JavaScript at any stage. No JIT. The result is a standalone binary that does not require anything installed on the target system.

Benchmarks from Perry v0.5.908 on an M1 Max (May 14, 2026) tell an interesting story:

TestPerryRust (-O)C++ (-O3)Node.js
Fibonacci (recursive i64)309ms316ms309ms987ms
Object create (1M allocs)2ms0ms0ms8ms
Nested loops (cache-bound)18ms8ms8ms17ms

Perry is competitive on integer-heavy work and object allocation. It lags on memory-bound loops — Rust is still faster there. But the headline number for most developers is startup: 1ms for Perry, 30ms for Node.js, 15ms for Bun. For CLI tools and edge functions, that gap is not theoretical.

Who This Is Actually For

Perry is not a general-purpose Node.js replacement. It is for three specific use cases where native compilation changes the equation:

CLI tool authors. Go developers have shipped single-binary CLIs for years — you run go build and hand someone a file that just works. TypeScript developers have had to bundle Node or force users to install a runtime. Perry changes that. Your CLI ships as a 2–5MB binary with zero runtime dependency.

Desktop application builders. Electron ships a Chromium instance — typically 200MB+. Perry’s native UI system (perry/ui) renders actual platform widgets: AppKit on macOS, UIKit on iOS, GTK4 on Linux, Win32 on Windows. Mango, a MongoDB GUI built with Perry, ships at roughly 7MB and uses under 100MB of RAM. That is a meaningful difference.

Edge and serverless deployments. Cold start matters at scale. A 1ms Perry cold start versus a 30ms Node.js start is not just a benchmark number — at high invocation rates, it translates directly to reduced cost and improved p99 latency.

Real Apps, Not Vaporware

The “it only works for hello world” criticism is the first thing skeptics will reach for. Perry has shipped answers:

  • Pry — a native JSON viewer, available on the iOS App Store and Google Play
  • Mango — a native MongoDB GUI (~7MB, <100MB RAM)
  • Bloom Engine — a native game engine targeting Metal, DirectX 12, and Vulkan
  • Hone — an AI-powered code editor at hone.codes

These are small-to-medium applications, not enterprise software. But they are real and shipping. Perry has 3,400+ GitHub stars, 139 releases, and an MIT license — this is active development, not an abandoned proof of concept.

What’s Missing and the “Why Not Go?” Question

Perry does not support decorators yet. Debug source maps are on the roadmap but unshipped. Full Node.js stream module compatibility requires the optional V8 bridge, which bloats the binary to 15–20MB and adds startup time. Hot reload for native UI is not here yet.

The obvious question: if you want native binaries, why not just use Go or Rust? The honest answer is that Perry is not trying to convert Go developers. It is for teams already in TypeScript — existing codebases, existing skills, existing types — who want to ship native without a full language rewrite. If you are starting from scratch with no TypeScript investment, Go is probably the simpler path.

But if your team writes TypeScript daily and you want to distribute a CLI that does not require Node.js installed, Perry is the first real option that does not involve compromises like bundling an 80MB runtime.

Try It

npm install -g @perryts/perry
perry build hello.ts
./hello

The GitHub repo has a starter project and the full benchmark suite. The HN discussion thread has the sharpest technical critiques if you want to stress-test the claims before adopting. The official documentation covers the roadmap and current platform support matrix.

TypeScript was designed as a superset of JavaScript — not a systems language. Perry is betting that the compiler toolchain has matured enough to change that, at least for use cases where native distribution and startup time actually matter. The benchmarks suggest it is not far off.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:News