I've looked into what is known about Bun's AOT experiments on a code level. Here's what they are actually doing, and how it differs from Perry and the other native-TS/JS projects. 🧵 What Bun AOT does At build time your JS goes: bytecode → SSA graph → whole-program type inference → inlining, escape analysis, scalar replacement, range analysis, loop opts → B3 (the backend behind JSC's top FTL tier) → position-independent machine code. At runtime the JIT is OFF. Code is mapped read-only straight from the executable. Nothing is ever patched. Even inline caches, normally self-modifying code, become plain data slots that stubs read. Three ideas make it work: 1. Closed world. The compiler assumes it sees the entire program, so it knows every call target, every captured variable, every escape. eval/new Function still work; they just drop to the interpreter. Perry either compiles all of it, or does not run it - no escape hatch. Some other compilers have built-in JS engines to provide escape hatches here. Notice, though, that all AOT is hitting the same wall here? 2. Frozen built-ins. Math.floor and Array.prototype.push can't be reassigned anymore, so arr.push(x) compiles to an actual push instead of lookup + guard. A small, deliberate spec deviation. 3. "Sound types." TS annotations get lowered into real runtime checks and tags. Lie to the type system, and you get a TypeError instead of a wrong answer. With a type table, objects get fixed field layouts, closer to a struct than a hash map. 📊 The numbers tsc type-checking effect (688 files): - Wall time: 5.97s JIT vs 6.01s AOT. Basically identical. - CPU time: 15.7s → 6.9s (-57%) - Instructions: -47% The JIT run kept ~2.6 cores busy. The AOT run, ~1.1. Same output. Read that carefully: AOT here isn't faster at peak. It's dramatically cheaper. Less CPU, less memory, faster startup. That's the part that matters on servers and CLIs. Status: draft, verified on macOS arm64 only, CI hasn't run, and the Bun-side `bun build --compile --compile-aot` isn't public yet. You can read it. You can't use it yet. ⚔️ Perry vs Bun AOT Same destination. Opposite directions. Bun goes top-down: take one of the best JS engines in the world and remove the JIT. Everything else stays. JSC's GC, hidden classes, megamorphic caches, the interpreter as a safety net. Full JS semantics, and you ship a whole engine. And this, by design, will not change. Some people might look at it as "this will be optimized away", but the reality is that you can't do it without replacing JSC here. Perry goes bottom-up: no engine at all. TypeScript/JavaScript parsed with SWC, compiled through LLVM, linked against a runtime and GC written from scratch (moving, generational, precise roots). No V8. No JSC. No interpreter waiting behind you. If something can't be resolved statically, that's a compiler problem to fix, not a slow path at runtime. What that means in practice: - Safety net: Bun's is the interpreter. Perry doesn't have one. That's the price, and it's also what lets Perry target places a JS engine doesn't go (WebAssembly today, RISC-V/ESP32 experiments). - Compatibility: Bun AOT can run more or less anything Bun runs. Perry targets statically resolvable JS/TS (~96–98% of test262 in that scope) and closes the gap compiler-side. Getting Claude Code's 13MB minified CLI to compile natively took 160 compiler fixes. - Backend: B3 was built to compile JS fast inside a JIT. LLVM is slower to compile but gives you every target and optimization LLVM has. - Runtime: Bun keeps a JS object model and bolts whole-program knowledge on top ("known shapes", a program-wide dispatch table). Perry's runtime only has to support what the compiler emits, so it's more tailored towards the target app. 🎯 The takeaway Everyone is converging on the same three ideas: 1. Closed world 2. Immutable intrinsics 3. Types you can actually trust Bun arriving there independently, from inside JavaScriptCore, is the strongest validation yet that TypeScript as a systems language is real. The open question is the engine. Do you keep it, or throw it away? Bun bets you keep it. I'm betting you don't need it. I also think you actually don't want it (safety-related). Honestly, we're probably both right, for different workloads. And either way, TypeScript wins. PR: github.com/oven-sh/WebKit/pu… Perry: perryts.com