Zipp compared with other JavaScript engines
There is no best JavaScript engine, only the right one for a binary-size budget, a trust boundary and a workload. This page compares Zipp with the engines people ask about most and says plainly where each of them beats Zipp. Facts about other engines are stated at the level their own documentation supports; Zipp's are measured.
At a glance
| Zipp | QuickJS / QuickJS-NG | Boa | Hermes | V8 (Node, Deno) / JSC (Bun) | |
|---|---|---|---|---|---|
| Language | Rust | C | Rust | C++ | C++ |
| Execution | Register bytecode interpreter + x86-64 tiered JIT + ARM64 baseline | Bytecode interpreter | Bytecode interpreter | Ahead-of-time bytecode; optional native compilation in Static Hermes | Multi-tier optimizing JITs |
| Memory management | Non-moving generational nursery + mark-sweep | Reference counting + cycle collection | Tracing GC | Generational GC | Generational, moving, concurrent |
| Test262 | 95,680 / 95,680 corrected core, 95,671 unmodified, on a pinned corpus | High; QuickJS-NG publishes its own results | Publishes a conformance dashboard | Targets ES6 plus selected later features | Effectively complete |
| WebAssembly build | Yes, 1.24 MB on the wire (JavaScript-only) | Yes, about 0.42 MB on the wire (QuickJS-NG reactor) | Yes | Yes (Hermes in the browser is a niche path) | No (V8 is the host, not a module) |
| Second language | Python 3 frontend on the same VM | No | No | No | No |
| Sandbox profile | No-unsafe, no-JIT build; hardened native runner | Interrupt handler and memory limit | Rust memory safety; limits by host | Runtime limits by host | Isolates; process sandbox is the host's job |
| Where it shines | Fast native runs, honest limits, two languages, embedding | Tiny footprint, mature, simple C embedding | Pure-Rust dependency, safety-first | React Native startup and memory | Peak throughput, ecosystem |
Zipp versus QuickJS
QuickJS is the engine to beat for footprint. Its WebAssembly reactor is 1,528,293 bytes raw and 417,087 after Brotli; Zipp's JavaScript-only module is 3.59× that raw and 2.96× on the wire. If your budget is under a megabyte on the wire, QuickJS wins, full stop. QuickJS also has years of production use, a C API that embeds in an afternoon, and QuickJS-NG as an actively maintained fork.
Where Zipp is different: on native x86-64 it has a JIT and QuickJS does not, and the only interpreter-to-interpreter comparison in the repository, in WebAssembly, is marked not publishable because only five hostile rows were comparable; QuickJS-NG led four of those five. Zipp also carries a Python frontend, spec-strict call ordering with an audited host boundary, and a conformance result reported per execution with zero skips. Choose QuickJS for size and maturity; choose Zipp for native speed, two languages, or a Rust-native embedding.
Zipp versus Boa
Boa is the other JavaScript engine written in Rust, and the more established one: older, with more contributors, published on crates.io, and a good choice when you want a pure-Rust dependency with a conservative safety story. It is interpreter-only, and it publishes its own Test262 dashboard rather than a single number, which is the right way to do it.
Zipp's differences are the native JIT tiers, the explicit-frame register VM design, the Python frontend, and the measured performance discipline documented on the benchmarks page. Zipp's repository does include a Boa 0.22.0 comparison series from an early version (v0.0.5), measured with and without --optimize to avoid selection bias, but it is old enough that this page will not quote it. If you need crates.io packaging today, Boa has it and Zipp does not yet.
Zipp versus Hermes
Hermes solves a different problem: fast startup and low memory for React Native apps, by compiling JavaScript to bytecode ahead of time on the developer's machine, with Static Hermes adding native compilation for typed code. It deliberately trims parts of the language that matter less to apps, and its conformance target is set accordingly. If you are shipping a mobile app, Hermes is the purpose-built answer and Zipp is not competing for it.
Zipp's design is the opposite trade: a complete ES2025 language with a JIT that compiles at runtime, a 7.4 ms native process launch, and a browser sandbox rather than a mobile runtime.
Zipp versus V8 and JavaScriptCore
V8 and JavaScriptCore are the fastest general-purpose engines that exist, with decades of optimizing-compiler work. On the September 2026 capture Zipp's geometric mean across thirty rows is 0.728× Node and 0.594× Bun, and it launches in 7.4 ms against 30.4 and 43.3, but it loses to Node on nine rows, most clearly on long-lived allocation (1.56×), React-style reconciliation (1.58×) and megamorphic property access (1.24×), and Bun is the outright fastest engine on JSON, markdown rendering and tokenizing. A capture taken nine days later, after a correctness change to call ordering, brought the headline ten rows back to parity with Node.
The honest framing is this: Zipp is competitive with V8 on cold, short-lived workloads and on startup, and V8 is still ahead when a program runs long enough for its top tier and its moving collector to pay off. Zipp is also not a Node replacement: there is no fs, http or npm resolution; hosts supply capabilities explicitly.
Choosing
- Smallest possible footprint: QuickJS.
- Pure-Rust dependency on crates.io today: Boa.
- Mobile app runtime: Hermes.
- Maximum throughput for long-running servers, and the npm ecosystem: Node, Bun or Deno.
- Native speed on scripts and short jobs, a JIT in Rust, a browser sandbox with hard limits, or Python and JavaScript on one engine: Zipp.