rquickjs

rquickjs provides safe, high-level Rust bindings to QuickJS-NG (a maintained fork of Fabrice Bellard’s QuickJS), a small, fast, embeddable JavaScript engine supporting nearly the full ES2020 specification including modules, async generators, proxies, and BigInt. Modeled after the ergonomics of the rlua crate, rquickjs wraps QuickJS’s C API behind a Runtime/Context model, giving Rust applications the ability to embed and execute untrusted or plugin JavaScript with a small footprint and low startup latency.

The crate provides bidirectional value conversion between Rust and JavaScript via IntoJs/FromJs traits, full ES6 class support so Rust types can be exposed as JS classes with getters/setters and static members, and — when the futures feature is enabled — first-class integration with async Rust, letting JS Promises be awaited as Rust futures and vice versa. It ships prebuilt bindings for a wide range of target platforms (Linux, Windows, macOS, WASM) so most consumers don’t need the slower bindgen fallback path. Community projects layer Node/WinterCG-style APIs (e.g. AWS’s LLRT modules) on top of rquickjs for use cases needing more than a bare engine.

What You Get

• A Runtime/Context model for creating and managing isolated JavaScript execution environments
• IntoJs/FromJs/IntoAtom traits for converting Rust values to and from JavaScript values
• Full ES6 class support, letting Rust types be exposed as JS classes with properties, getters/setters, and static members
• Optional futures-feature integration exposing AsyncRuntime/AsyncContext, with Promises usable as Rust futures and vice versa
• Support for custom module resolvers/loaders and pluggable allocators (including Rust’s global allocator)
• Prebuilt bindings for Linux, Windows, macOS, and WASM targets, with a bindgen fallback for unsupported platforms

Common Use Cases

• Embedding a sandboxed JavaScript plugin/scripting layer inside a Rust application or service
• Building serverless/edge runtimes that need a fast-starting, low-memory JS engine (in the spirit of AWS LLRT)
• Executing user-authored JS logic (rules engines, templating, extensions) with fine-grained control over available APIs
• Bridging async Rust code and JavaScript Promises in hybrid Rust/JS execution pipelines

Under The Hood

Architecture - The workspace splits into sys (raw FFI bindings generated from the vendored QuickJS-NG C sources, either prebuilt per-platform or via bindgen), core (the safe high-level Rust API — Runtime, Context, Value, Class, Loader, Persistent, and async variants under core/src/runtime, core/src/context, core/src/class, core/src/value, core/src/loader), macro (procedural macros for the #[embed], class-derive, and module-binding attributes), and the top-level rquickjs crate that re-exports core and, when the macro feature is enabled, the procedural macros — giving consumers a single crate to depend on despite the internal split. The futures feature layer wraps the base (non-thread-safe) Runtime/Context behind a future-aware lock so async code doesn’t block an OS thread while waiting for JS execution.

Tech Stack - Rust workspace (edition 2021, MSRV 1.87) wrapping the QuickJS-NG C engine; the sys crate vendors the C sources and either links prebuilt bindings for common targets or regenerates them via bindgen for other platforms. Optional features (rust-alloc, loader, dyn-load, futures, macro) are additive and let consumers opt into only the surface area they need, keeping the minimal build close to the underlying C engine’s small footprint (quoted at roughly 210 KiB of x86 code for a bare hello-world in the upstream QuickJS project).

Code Quality - The repository has a dedicated tests/ directory including compile-fail tests (compile_fail, async_compile_fail, async_parallel_compile_fail) that assert certain unsafe usage patterns fail to compile — a strong signal of deliberate API-safety design around a fundamentally unsafe C engine — plus a macros test suite and a documented platform support matrix distinguishing shipped-bindings vs. tested vs. quickjs-supported per target. The README explicitly flags experimental features (e.g. parallel) as not fully reliable, giving honest signal about which parts of the surface are production-ready versus still maturing.

API Design - The public API centers on constructing a Runtime, deriving one or more Contexts from it, and running code inside a context via closures that receive a Ctx handle for creating/converting values; IntoJs/FromJs implementations for common Rust types (and derivable for user types) mean most Rust↔JS data crossing doesn’t require manual serialization. The async/futures-feature API mirrors the sync API almost exactly (AsyncRuntime/AsyncContext) so consumers adopting async execution don’t need to learn a substantially different mental model, and ES6 class support lets Rust structs be exposed to JS with near-native ergonomics rather than opaque handles.