Skip to main content
← Back

JCO, Hono on WebAssembly & the wasmCloud v2 Component Model

The November 12, 2025 wasmCloud community call — broadcast live from the project pavilion at KubeCon — focuses on the Wasm component model and the JavaScript tooling reaching it. Victor Adossi gives a tour of JCO, the toolchain for building and running WebAssembly components in JavaScript, including new standalone jco transpile releases, the first stable release of jco-stl with a Hono WebAssembly integration, and ongoing JCO async work for the WASI P3 component model. Bailey Hayes shares that wash 2.0.0 RC3 is out, previewing the simpler new wasmCloud v2 runtime and its plugin-based custom-host story.

Key Takeaways​

  • JCO is the JavaScript side of the WebAssembly ecosystem — it wraps StarlingMonkey (a SpiderMonkey fork that runs in Wasm) and ComponentizeJS (which runs your JavaScript inside a component), adds TypeScript type generation from WIT, and acts as a host so a component can run anywhere there's a JS engine
  • jco transpile — which turns a WebAssembly component into a runnable JavaScript project — is now available standalone, including a new transpile-from-bytes interface that landed in response to a community feature request
  • jco-stl shipped its first stable release: a standard library of easy adapters that bridge popular JavaScript projects to the WebAssembly ecosystem, with Hono as the banner integration
  • Because Hono is built on web-standard request/response objects (the WinterTC interoperability standards) rather than tied to Node, it runs cleanly on a WebAssembly platform — jco-stl supplies the fire adapter and the incoming-handler export so a familiar Hono server compiles to a Wasm component
  • A new "Run Hono on WebAssembly" guide landed on the JCO website, sitting alongside the Cloudflare Workers, Deno, Bun, Fastly, AWS Lambda, and Supabase guides, walking through project setup, bundling, and building for the Wasm platform
  • JCO async is the second host implementation for WASI P3 — the component-model version that adds streams, futures, and native async — and large parts of JCO have been migrated to TypeScript to lower the bar for contributors
  • wash 2.0.0 RC3 is out and the final 2.0.0 release is just weeks away; it represents the new vision for wash and ships a much simpler runtime underneath while the old workflow continues to work
  • The new wasmCloud runtime lets you build your own custom host with plugins — a few declarative lines replace the old NATS-client setup, and feature flags let you slim the host down to only the capabilities (HTTP, blob store, key-value) you need

Chapters​

Meeting Notes​

JCO: The JavaScript Side of the WebAssembly Ecosystem​

Victor Adossi opened with a primer for anyone new to JCO, the tooling for the JavaScript side of WebAssembly. He framed three projects that together make WebAssembly components work in JavaScript: StarlingMonkey, an engine that is a fork of SpiderMonkey compiled to Wasm; ComponentizeJS, which takes StarlingMonkey and runs your JavaScript inside a component; and JCO, which wraps it all together — adding TypeScript type generation from your WIT and acting as a host so a component can run anywhere there is a JS engine (V8, the browser, or Node).

Under the hood, JCO takes a WebAssembly component, breaks it into core modules, adds the shim and glue code that implements the component-model machinery, and emits a full JavaScript module — a folder of files that performs the component's functionality as long as the runtime exposes the built-in WebAssembly object. The piece that does this is jco transpile. Historically it was invoked through the JCO CLI or its SDK, but some users only wanted the transpile functionality without the rest of JCO. In response to a community feature request — including transpiling raw bytes as an interface — new standalone versions of jco transpile shipped the prior week.

jco-stl and Running Hono on WebAssembly​

The other major landing was the first stable release of jco-stl, a standard library of easy adapters for interoperability between popular JavaScript projects and the WebAssembly ecosystem. The banner example is Hono, a lightweight web framework comparable to Express or Fastify. Victor explained the key difference: Hono is built against web-standard request and response objects (the WinterTC interoperability standards) rather than Node-specific APIs, so it can run on a WebAssembly platform with the right translation layer.

In Victor's code walkthrough, most of a jco-stl Hono app looks like an ordinary Hono server. The special parts are importing Hono's fire function from jco-stl (rather than from Hono directly) and adding an exported incoming handler that processes incoming web requests. The handler implementation is generated for you — you only export it — so with just those lines you get a working server that mostly resembles a regular Hono app, and Hono's middlewares and plugins (built against the same interoperable web-request layer) work out of the box. jco-stl is open source and lives in the JCO repository.

A New Guide, JCO Async, and the TypeScript Migration​

A new "Run Hono on WebAssembly" guide landed on the JCO website, joining the existing guides for Cloudflare Workers, Deno, Bun, Fastly, AWS Lambda, and Supabase. It walks through setting up JCO, ComponentizeJS, and jco-stl; bundling code; and building a Hono app for the WebAssembly platform — which you can then run in Wasmtime (the bigger, more actively maintained runtime) or, experimentally, via jco serve. As the JavaScript ecosystem evolves toward Node-compatible bindings that "just work," jco-stl should become less necessary, but for now it saves writing a lot of bridging code by hand.

Beyond Hono, the active work in JCO is JCO async, the second host implementation for WASI P3 — the version of the component model that adds streams, futures, and native async. Victor also noted that large parts of JCO have been migrated to TypeScript, so anyone who held off contributing because of the previous codebase should find it much easier to jump in.

wash 2.0.0 RC3 and the New wasmCloud Runtime​

Picking up the items Bailey had queued in chat before her conference network gave out, Victor announced that wash 2.0.0 RC3 is out, with the final 2.0.0 release "really close." He cautioned that the name is a little misleading: the new version of wash comes with a new runtime underneath that is a lot simpler than the old stack, while the old workflow continues to work. He pointed to the WasmCon NA live blog — where the team was posting talks from Bailey, Luke, Elizabeth, and others as they happened — and called out the doc change of the week, PR #1018, which adds an introduction to the new runtime section of the docs.

Walking the new runtime architecture docs page, Victor described a more flexible host: you can add plugins the team has written or your own, and build a custom host to run your workloads. Where the old approach required standing up a NATS client and server, the new host gets running in just a few declarative lines with reasonable names for workloads (rather than juggling components and providers) and a clear engine-plus-plugins model. For Rust embedders, the functionality is gated behind feature flags so you can slim the host down — skip HTTP, blob store, or key-value if you don't need them — making it easy to build a custom host, add functionality, and run WebAssembly workloads wired to those plugins. He closed by thanking Mike for kicking the tires on v2 and asking the community to file bugs and documentation requests for anything that feels painful: the goal, he said, is "no pain."

WebAssembly News and Updates​

This call is a snapshot of the JavaScript-to-WebAssembly toolchain maturing around the component model. On the JS side, JCO, ComponentizeJS, and StarlingMonkey continue to converge — with jco transpile now usable standalone and jco-stl shipping its first stable release so frameworks like Hono run as WebAssembly components with minimal glue. JCO async is being built as a second host implementation for WASI P3, the component-model revision that brings native async, streams, and futures. On the host side, wash 2.0.0 RC3 previews a simpler wasmCloud v2 runtime, and the team posted live coverage from WasmCon NA. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and JavaScript) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and the new wasmCloud v2 runtime — previewed in this call — makes it easy to embed that host in your own application and extend it with plugins. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Nearly every thread in this meeting traces back to the Wasm component model. JCO exists to make components first-class in JavaScript: ComponentizeJS turns JavaScript into a component, jco transpile turns any component back into runnable JavaScript, and JCO acts as a component host on top of a JS engine. jco-stl layers familiar framework ergonomics — like Hono's fire and the incoming-handler export — on top of the component model's typed interfaces, so a developer writes ordinary-looking JavaScript and gets a portable, sandboxed WebAssembly component. JCO async pushes this forward into WASI P3, the component-model revision that adds streams, futures, and native async, building a second host implementation alongside Wasmtime. And on the wasmCloud side, the new v2 runtime is built to schedule and run those components through a clean engine-plus-plugins host model. As more of the ecosystem implements the component model, the promise of "write a component once, run it in any language's host" gets closer to reality.

Who Should Watch This​

This call is especially valuable for JavaScript and TypeScript developers who want to compile familiar frameworks like Hono to WebAssembly components (start with Victor's JCO and jco-stl walkthrough at 4:38), framework and tooling authors tracking how jco transpile, ComponentizeJS, and JCO async fit together on the road to WASI P3 (16:50), and platform engineers evaluating the new wasmCloud v2 runtime and how to build and slim down a custom host with plugins (Victor's runtime-architecture tour at 22:25).

Up Next​

The next community calls lead into the wasmCloud 2.0.0 general-availability release, expected within a couple of weeks of this RC3 candidate. Watch for the final v2 runtime, more on building custom hosts with plugins, continued JCO async progress toward WASI P3, and additional jco-stl adapters beyond Hono. In the meantime, the team is asking everyone to test wasmCloud v2 and file bugs and documentation requests for anything that feels painful.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →