Deno’s Big Shift: QuickJS Replaces V8, Cutting Compile Size by Almost 45%

Deno is preparing a lighter replacement for the V8 engine it has used for years. Founder Ryan Dahl shared striking data: on an ARM64 macOS Release build, the denort binary built with V8 is about 64 MiB, and a compiled Hello World is roughly 65 MiB; using QuickJS those numbers drop to 35 MiB and about 35.6 MiB respectively.

A change in JavaScript engine reduces the simplest Deno compile artifact by roughly 29 MiB, a size reduction close to 45 %.

For front‑end developers accustomed to Electron bundle sizes, this reduction is eye‑catching.

However, Deno is not discarding V8 entirely. The ongoing PR #36194 adds an experimental QuickJS backend . V8 remains the default engine, and developers can explicitly choose QuickJS when compiling a standalone executable.

65 MiB Hello World, code is only a tiny part

The deno compile command bundles JavaScript/TypeScript code and its dependencies into a single executable, allowing users to run the file without pre‑installing Deno—convenient for CLI tools and internal utilities.

The trade‑off is evident.

The compiled result includes not only the application code but also a trimmed Deno runtime ( denort). Official documentation cites a typical size of about 70 MiB, because the entire JavaScript runtime is packed into the file.

This means that even a few‑line CLI ends up dominated by the runtime binary.

V8’s strengths are maturity, strong performance, and deep compatibility; it powers Chrome, Node.js, and Deno, and the ecosystem has embraced this heavyweight solution. Yet for tiny tools that execute only a small amount of logic after launch, the size and complexity of V8 may not be justified.

QuickJS follows a different philosophy. Initiated by Fabrice Bellard, its official description emphasizes being small, easy to embed, low startup time, while still supporting modern ECMAScript specifications.

If V8 is like a high‑performance engine built for long‑distance highways, QuickJS is more like a lightweight engine that fits into small devices. The former targets sustained performance for complex applications; the latter cares more about size, embedding cost, and startup speed.

The deno compile command gives QuickJS a niche where its strengths shine.

Deno does not rewrite the runtime

The most interesting aspect of this change is not merely “adding another engine” but that Deno is loosening its binding to V8.

The PR introduces an interface layer named deno_v8. Upper‑level code still sees a V8‑style API, while the lower layer can bind either to the original rusty_v8 or to the QuickJS‑based v8x.

At the same time, deno_core, deno, denort, and denort_desktop gain mutually exclusive build options v8 and quickjs. The default build remains unchanged; selecting QuickJS requires an explicit flag.

The PR also adds a new engine parameter for deno compile: deno compile --engine quickjs main.ts When enabled, Deno fetches the QuickJS version of the denort runtime and embeds the application code. The default command and the --engine v8 flag continue to use V8.

This approach is far safer than a full V8 replacement. Deno can first let size‑sensitive compile scenarios reap the benefits, then gradually verify compatibility of the Node.js layer, Web APIs, snapshots, garbage collection, and multi‑platform builds.

Once this abstraction stabilises, its significance goes beyond a single flag: Deno’s upper‑level capabilities will no longer be tied to a single JavaScript engine, allowing future choices of different size‑performance combinations for servers, desktop apps, or CLI tools.

Size wins, but compatibility still needs work

A 35.6 MiB Hello World is attractive, yet it is currently an experimental result—not a production‑ready guarantee.

The PR is still open and not merged. Discussions have reported runtime errors when building Fresh and Vite with QuickJS, and differences in Intl.DateTimeFormat timezone and formatting behavior. QuickJS builds even show V8 version information in deno --version, indicating that adaptation work is far from complete.

Engine swapping is hardest at the compatibility layer. Getting a Hello World to run is not the end goal; the real test includes:

Node.js compatibility layer : many npm packages rely on V8‑specific behavior, error stacks, and garbage‑collection details.

Web API and internationalisation : timezone, locale formatting, and underlying system libraries can diverge.

Sustained performance : QuickJS saves size, but long‑running compute‑heavy tasks may not outperform V8.

Cross‑platform publishing : QuickJS runtimes for Linux, macOS, and Windows must be integrated into Deno’s release pipeline.

Thus, the current assessment is that QuickJS has the opportunity to become a lightweight option for deno compile, but it is not yet a universal replacement for V8.