Jco (@bytecodealliance/jco on NPM)is a “multi-tool for the JS WebAssembly ecosystem.” At the 2026 Bytecode Alliance Plumbers Summit, Technical Steering Committee member Bailey Hayes put it another way: Jco is “like five projects in one.”

It’s certainly a project with many facets—five big ones, arguably! Recognizing what those facets are, and how they fit together, is the key to understanding why Jco matters beyond the JavaScript ecosystem.

In this blog series, we’ll draw on Victor Adossi’s Plumbers Summit presentation to take an in-depth look at Jco from five different perspectives, in order to better grasp how you can use (and contribute to!) Jco today. There’s a lot to unpack here, so in this first post, we’ll try to get to grips with Jco as a layered architecture that brings together many pieces of the Wasm and JS ecosystem.

1. Wasm and JS ecosystem

To understand Jco, it helps to understand its layers.

jco-architecture.svg

Building JS components

Here are the projects that are involved when using JavaScript to build new WebAssembly components:

StarlingMonkey

At the base is StarlingMonkey: a JavaScript runtime built on SpiderMonkey (the same engine that powers Firefox) that compiles to WebAssembly. StarlingMonkey adds the Component Model wiring that SpiderMonkey itself doesn’t include, handling the communication that occurs when a JS component calls an import or exposes an export.

componentize-js

componentize-js takes your JavaScript source code and bundles it into StarlingMonkey to produce a proper WebAssembly component.

Componentize-js runs the binary through Wizer, a pre-initialization tool. At build time, Wizer executes the component’s startup code (and your JS code at global scope) and snapshots the resulting state. The initialization cost is paid once, at build time, not on every instantiation.

Componentize-js is also in the process of being rewritten to use wit-dylib — a relatively new tool Alex Crichton added to wasm-tools that significantly simplifies the process of targeting the Component Model from an interpreted language. This rewrite will eliminate a somewhat circular dependency that currently exists in the build (js-component-bindgen, written in Rust, is currently consumed by componentize-js via transpilation, and is also depended on by componentize-js).

The jco CLI

The jco CLI is the amalgamation of JS WebAssembly ecosystem tools into one user-facing layer. jco componentize calls down to componentize-js. But jco’s other major capability jco transpileoperates differently.

jco transpile

jco transpile (@bytecodealliance/jco-transpile on NPM or via the jco transpile CLI) takes any WebAssembly component (written in any language: Rust, Go, Python, C, JavaScript, anything) and converts it into core Wasm modules plus JavaScript glue code that runs in Node.js or any browser with core Wasm support. No native Component Model support required.

Under the hood, this involves “unbundling” the component—decomposing it into its constituent core Wasm modules with the imports and exports they need, then generating the glue code that implements Component Model semantics on top of those.

jco-transpile.svg

js-component-bindgen

The Rust crate that makes this possible, js-component-bindgen (js-component-bindgen on crates.io), handles the heavy lifting of generating correct “lifting and lowering” glue code for every Component Model type and intrinsic based on the WIT contract that you’ve specified for your component—that is to say, the translation layer that converts between Wasm’s binary value representation (a string is a memory pointer plus a byte length) and idiomatic JavaScript types that your code works with.

WASI P2 shims

Jco ships WASI P2 shim packages (@bytecodealliance/preview2-shim on NPM): JavaScript implementations of WASI (the WebAssembly System Interface, the standard set of I/O APIs for Wasm covering filesystem access, HTTP, clocks, randomness, and more) interfaces that let transpiled components call things like wasi:http and wasi:io from a browser or Node.js environment.

WASI P3 shims

P3 shim support is in active development, with full WASI P3 support for Node.js environments imminent in Jco. Browser-side P3 shims are explicitly deferred until the Node.js shims stabilize.

Looking ahead

In the next blog, we’ll take a look at four more ways of thinking about Jco, and break down how you can get involved. In the meantime, if you have questions or want to jump in right away, make sure to join the community on the Bytecode Alliance Zulip jco channel.