QuickJS WASI
https://github.com/vercel-labs/quickjs-wasi- Category
- Developer Tools
- Rank
- No. 1389Tools index
- Pricing
- Open Source
- Type
- TOOL
- Builder
- vercel-labs
- GitHub
- 115 stars
- Latest release
- quickjs-wasi@3.6.0
- Date
About
Snapshotable JavaScript runtime via WebAssembly. Runs QuickJS-NG compiled to WASM and lets you snapshot the entire VM state including pending promises.
What it does
QuickJS WASI embeds a separate JavaScript engine inside a WebAssembly host. Applications supply the compiled module, evaluate guest code, exchange values through managed handles, expose host callbacks, load ES modules, and restore captured execution state in another instance.
Why it's ranked here
The design gives hosts unusually direct control over embedded JavaScript execution. Memory ceilings, interruption, deterministic clock and randomness overrides, selective built-ins, extension loading, and explicit resource disposal make it credible for constrained runtimes. The main cost is integration work around binary loading, handle ownership, job queues, and synchronous module resolution.
What's good
The host controls every external capability because the package performs no implicit filesystem or network access. Compiled WebAssembly modules can be reused across instances. Guest exceptions retain useful names, messages, and stacks. Memory limits surface allocation failures, interrupted virtual machines remain usable, and native extensions share memory and symbols with the main runtime.
Tradeoffs
Callers must load and distribute the WebAssembly binary themselves. Value handles require disciplined disposal, although scoped cleanup helps. Promise work requires explicitly draining the guest job queue. Module loading callbacks cannot await network operations, so remote dependencies need prefetching or repeated evaluation after cache misses. Snapshot restoration also requires the same extensions in the same order.
How to use it well
Use it when an application needs controlled, repeatable JavaScript execution with host-defined capabilities, resource limits, resumable state, or native WebAssembly extensions. Compile the module once, reuse it, scope handles tightly, and keep module sources cached. It does not provide fetching, filesystem access, or automatic module distribution, so supply those policies in the host application.
Technical notes+
src/index.ts defines the TypeScript library surface, including value handles, evaluation flags, selective intrinsics, memory accounting, module loading, interruption, extension descriptors, and snapshot-related APIs. c/interface.c is the WASI reactor bridge around QuickJS, heap-allocating JSValue objects across the boundary and importing host callbacks for functions, modules, interrupts, promise rejection tracking, and timezone offsets. src/wasi-shim.ts supplies minimal clock, output, descriptor, seek, and randomness imports with user overrides. src/extensions.ts parses dylink.0 metadata, allocates shared memory and table regions, resolves symbols against the main module, and layers WASI implementations. Makefile targets wasm32-wasip1, links a reactor, exports dynamic symbols, and builds URL, encoding, headers, structured-clone, and crypto shared libraries. package.json exposes the npm library, core WebAssembly binary, and extension binaries.
Observed
- License
- MIT
- Primary languages
- TypeScript and C
- Install surface
- Public npm package installed as quickjs-wasi
- Interface
- JavaScript and TypeScript library API
- Platform support
- Documented loading workflows for Node.js, browsers, and Vite-style bundlers
- Packaging
- Ships the core WebAssembly binary plus URL, encoding, headers, crypto, and structured-clone extension binaries
- Build target
- WASI reactor compiled for wasm32-wasip1
Read from README.md, Makefile, package.json, src/index.ts, src/version.ts, src/wasi-shim.ts, src/extensions.ts, c/interface.c, bench/url-benchmark.ts, bench/headers-benchmark.ts, bench/encoding-benchmark.ts.
What it can do
Execute JavaScript code in WebAssembly environment
JavaScript code → Execution results
Create snapshot of JavaScript runtime state
Running JavaScript VM with active state → Serialized VM snapshot
Restore JavaScript runtime from snapshot
Previously saved VM snapshot → Running JavaScript VM with restored state
Preserve pending promises in snapshots
JavaScript VM with unresolved promises → Snapshot containing promise state
Run JavaScript in sandboxed WASI environment
JavaScript code → Secure execution results
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.