Brimstone, a JavaScript engine in Rust that borrows V8's ideas but not V8's code

A from-scratch engine with a small dependency budget

Brimstone is described as a JavaScript engine written from scratch in Rust with full support for the JavaScript language, and the architectural stance is stated up front. It implements the ECMAScript specification, takes heavy inspiration from the design of V8 and from SerenityOS's LibJS, and chooses to implement almost all components of the engine itself with minimal dependencies. The two named exceptions are ICU4X for Unicode data and temporal_rs for the Temporal API, and the Cargo manifest makes the coupling visible: every ICU4X crate is pinned to the same 2.2.0 version because the ICU4X crates must all match, and the two Temporal crates are pinned together at 0.2.4 with default features disabled. That is a small, deliberate surface for an engine of this size, and it is the clearest statement in the repository about what the author wanted to own.

The feature list, and the two holes in it

The stated features are a complete JavaScript language and standard library apart from two exceptions, being up to date with the latest features through ES2026, a bytecode VM, a compacting garbage collector, a custom RegExp engine and a custom parser. The two exceptions are named precisely in the missing features section: SharedArrayBuffer and Atomics. That is the whole gap list, and every feature up to ES2026 is claimed as implemented otherwise, including Temporal. The two omissions are not arbitrary. Both exist to support shared memory between threads, and both are hard to implement correctly, which is a reasonable place for a from-scratch engine to draw its first line. The comparison point is the test262 suite, the official ECMAScript conformance suite, against which the project claims more than 97 percent of the language passing. The VM is described as heavily inspired by the design of V8's Ignition, and the garbage collector is described with unusual candour as written in very unsafe Rust, which tells you something about the trade-off the author was willing to make for compaction performance.

Building and running a JavaScript file

The build is plain cargo, and the executable is called `bs`. `cargo build` produces it and `cargo run` runs from source, and once built you point the binary at a JavaScript file. The documentation shows the whole loop, including the expected output, which is a nice touch for a project where the runtime is still a work in progress.

# Build brimstone
cargo build

# Execute a JavaScript file
./target/debug/bs ./hello.js
Hello world!

The binary is the debug build by default, so the path in the example points into `target/debug`. A reader who wants the release behaviour has to build it in release mode, and nothing in the documentation discusses performance numbers, which is consistent with the project not claiming to be a fast engine yet.

Testing is the centre of the project

The testing setup is more elaborate than the user-facing documentation, and it is where most of the effort is visible. Brimstone relies heavily on first and third party integration test suites, most notably the official test262 suite, and a custom integration test runner is included, invoked with `cargo btest`. Unit and snapshot tests run with `cargo test`, and fuzz testing has its own script at `./tests/fuzz/run.sh`. The repository also has a `tests/` directory with subdirectories for the harness and for performance work, and the workspace manifest lists `tests`, `tests/fuzz`, `tests/harness` and `tests/perf` as separate members, so the test infrastructure is a first-class part of the build rather than a script sitting outside it. There is also a `tools/` directory that holds the custom formatter, which the project exposes as a cargo alias along with the test runner, both configured in `.cargo/config.toml`.

The workspace layout, crate by crate

The Cargo manifest is a workspace with the resolver set to version 2 and the edition set to 2024, at workspace version 0.1.0, authored by hanshalverson. The members give the architecture away. The root package is `src`, holding the engine binary and its runtime, and `src/js` is `brimstone_core`, the JavaScript core library. Then there are three focused internal crates: `brimstone_macros` for procedural macros, `brimstone_icu_collections` for the project's own ICU data handling, and `brimstone_serialized_heap`, which is the serialized heap used by the collector. The external dependency list is a mix of infrastructure and specific choices: clap for the command line, serde and serde_json for serialization, indexmap and hashbrown for ordered and fast maps, num-bigint and num-traits for arbitrary precision numbers, regex for the custom RegExp engine, and tikv-jemallocator for the allocator, plus criterion for benchmarking, ryu-js for double formatting, and half for half-precision floats.

Where this engine stands

The status is stated in one line and it is worth repeating exactly: Brimstone is a work in progress that already supports almost all of the JavaScript language, more than 97 percent of ECMAScript in test262, and is not ready for use in production. The repository is not archived, with the last push on 2026-10-09, and there are no GitHub releases, so the version to track is the commit. The licence is MIT. The honest reading is that this is a serious engineering project at an early stage, with the test infrastructure, the fuzzing and the conformance percentage suggesting the work is measured rather than asserted, and the absence of any performance claim, benchmark table or release cadence telling you it is not aimed at production use yet. For a reader, the value today is in the code: an engine whose every layer, from parser to collector, is readable in one repository.

Editorial conclusion

Adopt Brimstone if you want to read a complete JavaScript engine implementation, or if you are working on WebAssembly hosts, embedded runtimes or Rust tooling that needs its own engine, and skip it if you need something to run JavaScript in production, because the project says it is not ready for that. Verify three things before you build on it: whether SharedArrayBuffer and Atomics matter to you, since those are the only named gaps up to ES2026; that your toolchain matches the pinned Rust version in rust-toolchain.toml; and that the ICU4X and temporal_rs dependencies are acceptable to you, since they are the two places where the engine does not implement everything itself and they are version-coupled by the manifest.

Frequently asked questions

Official sources

1. Hans-Halverson/brimstone on GitHub
2. Issues
3. License: MIT
4. README