Bun AOT: TypeScript Nears Go Speed, Zero Changes, Memory Cut 50%

Bun AOT Compilation: TypeScript Performance Approaches Go

Last month the community debated whether Bun's ahead-of-time (AOT) compilation would turn TypeScript into a separate "BunScript" dialect. Bun creator Jarred Sumner has now published concrete benchmarks showing that existing TypeScript code — without any modifications — can reach performance levels close to Go.

Benchmark Results: Claude Code CLI, OpenClaw, OpenCode

On macOS arm64, the Claude Code CLI was tested over five conversation rounds. With JIT disabled and Bun AOT enabled, time-to-first-interaction dropped from 216 ms to 165 ms, memory usage fell 48%, and CPU usage decreased 46%. This directly translates to quieter fans when running multiple terminal agents.

On Linux x64, OpenClaw (using its original build script unchanged) started 3.1× faster than Node v26 and used 38% less memory. OpenCode also saw a 41% memory reduction. Jarred noted that OpenClaw's input scripts are plain JavaScript without type annotations, leaving further optimization headroom.

How AOT Compilation Works: Fixed Memory Offsets and Native Instructions

Traditional Node.js or bun run first strips type annotations, compiles to JavaScript, and relies on the engine to guess types at runtime via JIT. Bun AOT compiles TypeScript directly to native machine code before execution, using explicit type annotations to lay out memory like Go or Rust structs — fixed offsets, no hidden-class lookups. Numeric operations emit 64-bit native arithmetic instructions, eliminating repeated boxing/unboxing and tag checks.

# Check which code paths would fall back to slow paths without generating a binary
bun check --aot --explain

# Compile directly to a single native executable that does not depend on JIT
bun compile ./index.ts

Compatibility and Fallback Behavior

The compiler remains compatible with existing Node.js and Bun codebases. Dynamic features such as eval and node:vm continue to work. When static analysis cannot resolve a dynamic code path, the compiler automatically falls back to the conventional JIT mode instead of breaking the application.

Comparison with LuaJIT: Bun AOT Wins 6 of 8 Benchmarks

Jarred posted an M4 Max benchmark chart covering eight classic tests (including binary trees and mandelbrot). Bun AOT won six, averaging 1.8× faster overall. The memory-intensive binary trees benchmark showed a 6.2× speedup. While Go head-to-head numbers were not published, outperforming LuaJIT — long regarded as extremely fast — strongly suggests Go-level performance is within reach.

Limitations vs Rust and C: JavaScript Semantic Constraints

Jarred acknowledges that closing the remaining gap to Rust or C requires more than compiler improvements. JavaScript's semantics impose hard limits: all numbers are IEEE‑754 doubles, there are no explicit integer types like u32 or i64, and the language lacks value-type structs or fine-grained memory layout control. The compiler cannot infer which data should live on the stack or which structs need compact packing.

Naming Controversy: Why Not a New Language?

When ast-grep author Herrington Darkholme suggested designing a brand-new language with a rich standard library, Jarred replied that Clang and GCC have added countless extensions to C/C++ without claiming to have created new languages. Forking the ecosystem would only increase complexity and adoption friction.

Conclusion: Strict TypeScript Types Yield Near-Go Performance

For developers who previously rewrote CLI tools or high-concurrency services in Go to avoid Node.js startup latency and memory overhead, the new option is clear: write rigorous TypeScript types, adopt Bun AOT, and gain native execution efficiency approaching Go — without learning a new language.