Yuku, a JavaScript/TypeScript Compiler Toolchain in Zig

yuku

A high-performance JavaScript/TypeScript compiler toolchain written in Zig, bringing modern JavaScript tooling infrastructure to the Zig ecosystem.

Why Yuku

Yuku is a JavaScript/TypeScript toolchain built from the ground up in Zig. It is designed for correctness, performance, and clarity.

Correctness first. Yuku is 100% ECMAScript spec compliant. It passes all 55,000+ tests from Test262, Babel, TypeScript, etc., with full AST matching, covering every edge case in the specification. Zero failures, zero AST mismatches. See the test results.

Fast by design. The parser is built using data-oriented design principles and generous performance engineering.

Pure Zig, zero dependencies. The entire toolchain is written in Zig with no external C libraries or runtime dependencies. This makes it easy to build, embed, and cross-compile.

Modern JavaScript. Full support for modern and experimental features including decorators, source phase imports, deferred imports, using/await using declarations, and more.

Current Status

The .js(x)/.ts(x) parser is stable and ready for production use in both Node.js and Zig. The API is stable, the implementation is 100% spec-compliant, and the AST output is fully validated against Test262, Babel, and TypeScript fixtures. The Traverser is usable today and powers Yuku’s semantic checker, but its API surface may still evolve as we build more tools on top of it.

The rest of the toolchain (minifier, resolver, transpiler including .d.ts generation, and more) is planned and being built incrementally, one component at a time. Contributions are welcome and will help accelerate development.

Performance

On native (Zig/Rust) parsing, Yuku is competitive with Oxc and roughly 2× faster than SWC:

Parsing speed for the typescript.js file (7.8 MB) · macOS (ARM) | Apple M4 Pro · Source

On the JavaScript side (npm), Yuku is 4-16x faster than alternatives:

Parsing speed for the react.js file (72 KB) via npm packages · macOS (ARM) | Apple M4 Pro · Source

But does it scale? yes:

Parsing speed for the typescript.js file (7.8 MB) via npm packages · macOS (ARM) | Apple M4 Pro · Source

A note on Oxc’s npm performance

You may wonder why Oxc is slower in this npm benchmark, even slower than Babel. This is because Oxc’s npm package has the overhead of passing the AST from Rust to JavaScript. What it does is serialize the AST to a JSON string on the Rust side and then call JSON.parse on the JavaScript side. This overhead makes it slower, even though Oxc is very fast at raw parsing speed.

If you benchmark Babel and Oxc by just calling their parse functions, Oxc will appear faster than Babel. This is because the program field returned by Oxc’s parse call is a getter that only runs JSON.parse when you actually access it. That deserialization is the main bottleneck, and it grows as the AST gets larger (i.e., as the source file gets longer). The npm benchmarks above measure the time to actually obtain the full AST for all parsers.

Oxc also has an experimentalRawTransfer option that makes oxc-parser roughly 2-3x faster than the results shown above. However, it is currently experimental and comes with significant limitations: it only works in Node.js (not Bun, Deno, etc.), and it allocates gigabytes of memory upfront for a single parse, leading to out-of-memory errors and failures when parsing files in parallel.

Yuku takes a different approach. Its AST is designed from the ground up to be transfer-friendly: flat, compact, and near-binary. This makes passing the AST from Zig to JavaScript fast, lightweight, and simple, without modifying the core parser. Zig’s comptime makes this safe by design. There are no multi-gigabyte allocations, only the memory the source being parsed actually needs. It works reliably on any platform and is already fully validated, passing all 55,000+ Test262 cases with exact AST matching between Zig and JavaScript. This is still an early version, with further AST transfer performance improvements already planned.