Skip to main content
← Back

wasmCloud v2 Pre-Launch, StarlingMonkey, componentize-js Rewrite & JCO P3 Streams

Watch on YouTube ↗

The March 18, 2026 wasmCloud Wednesday is a short conference-week call dominated by Victor Adossi's deep dive on the JavaScript ecosystem. Bailey Hayes is calling in from Wasm I/O in Barcelona finalizing the wasmCloud v2 release cut. Victor walks through the new StarlingMonkey 0.30 release with the Weval optimization layer re-enabled, Joel Dice's rewrite of componentize-js to Rust using wit-dylib, Tomasz's parallel componentize-qjs effort built on QuickJS-NG, JCO's freshly-landed stream support for WASI P3, and a fully vibe-coded JavaScript host for the WebAssembly component model — complete with a Go-in-the-browser demo.

Key Takeaways​

  • wasmCloud v2 release cut coming within 48 hours — Bailey is finalizing verification and documentation from Barcelona; the release is timed to coincide with Wasm I/O
  • StarlingMonkey 0.30 released with Weval re-enabled — Tomasz and Till brought the SpiderMonkey inside StarlingMonkey forward, re-enabling the Weval optimization layer for a meaningful performance bump (at the cost of slightly larger binaries)
  • componentize-js is being rewritten in Rust by Joel Dice — moving off the old C++/SpiderMonkey-binding approach to wit-dylib, an abstraction that lets you implement a single C header file and ship a fully-working P3 component for any interpreted language (wit-dylib)
  • componentize-qjs lands on top of QuickJS-NG — Tomasz has been wiring up Fabrice Bellard's QuickJS engine (via the QuickJS-NG fork) with wit-dylib, positioning componentize-js to become a true multi-engine project
  • JCO transpile now supports streams for WASI P3 — multiple JCO releases shipped today including stream lifting/lowering tests across primitive types; futures are the last piece before P3 host support is complete
  • A vibe-coded JavaScript component-model host exists and works — Jelle van den Hooff produced wcjs, a fully-TypeScript implementation of what jco transpile does, with a Go-component-in-browser demo running on JSPI; the JS host will likely be merged upstream as an alternative to the Rust js-component-bindgen
  • The conference run is in full swing — Wasm I/O (March 19-20, Barcelona), CNCF Wasmcon (March 23, Amsterdam), and KubeCon EU (March 24-26, Amsterdam) all back-to-back

Chapters​

Meeting Notes​

wasmCloud v2 Release and Conference Run​

Jeremy Fleitz opened the call with Bailey Hayes joining from Wasm I/O in Barcelona. The wasmCloud v2 release cut is imminent — Bailey is doing final verification and documentation work and aims to cut within the next two days. The release timing is intentional, coinciding with Wasm I/O so the broader WebAssembly community sees v2 in person. Once cut, the wasmCloud docs and the wasmCloud TypeScript repo will be promoted to match.

The next two weeks are heavy on conferences: Wasm I/O Barcelona (March 19-20), CNCF Wasmcon Amsterdam (March 23), and KubeCon EU Amsterdam (March 24-26). Next week's wasmCloud Wednesday will be hosted from Amsterdam.

StarlingMonkey 0.30 and the Weval Layer​

Victor Adossi walked through the JavaScript ecosystem updates. StarlingMonkey 0.30 shipped recently with a lot of upstream changes courtesy of Tomasz and Till. The headline: the Weval optimization layer is re-enabled. Weval had been disabled at the StarlingMonkey level for a while after some changes late last year. Having it back gives a meaningful performance boost in exchange for a slightly larger binary — a trade-off most consumers will gladly take.

componentize-js Rewrite to Rust with wit-dylib​

Joel Dice has been rewriting componentize-js to Rust, with a methodology change at the same time. The previous approach was C++/SpiderMonkey-binding splicing into the StarlingMonkey Wasm output. The new approach uses wit-dylib — an abstraction that lets you implement a single C header file and end up with a fully-working P3 component that wraps an interpreted language.

The pattern works for both interpreted and compiled languages (though direct bindings are usually more efficient for compiled languages). If your language has good FFI affordances with a C ABI, you can implement the header, build a Wasm shared object, and wit-dylib will turn it into a P3 component with hooks for all the necessary classes — streams, futures, the full set of P3 features.

componentize-js is moving from the old methodology to this new wit-dylib methodology, and a lot of the work is already done. Joel has examples for wasi-cli and wasi-http. The HTTP example currently looks a little ugly because some types are still waiting on a more ergonomic wrapper; right now it shows what raw WIT-interface-level code looks like on the guest side in P3 — including the u8 stream lifting/lowering for reading from the transmit/receive ends. P3 async behavior on the guest side is essentially here for JavaScript, and partially usable today.

componentize-qjs on QuickJS-NG​

Tomasz has been working on a parallel effort, componentize-qjs, that's similar to componentize-js but built on a Wasm-ready build of QuickJS-NG (the "new generation" fork of Fabrice Bellard's QuickJS) instead of StarlingMonkey + SpiderMonkey. QuickJS-NG strikes a good balance: it passes a lot of tests, is reasonably fast (though no V8 or SpiderMonkey), and has a clean Rust binding — which makes it much easier to wrap. componentize-qjs also uses wit-dylib, so it gets async/P3 features through the same mechanism. The reason this matters strategically: componentize-js is on the path to becoming multi-engine. Future users will be able to choose StarlingMonkey, QuickJS-NG, or whatever other JS runtime fits their constraints — for example, picking QuickJS-NG when binary size matters more than throughput.

JCO Stream Support Landed Today​

JCO transpile shipped multiple releases today, with stream support landing. Victor walked through the new tests, which import an async export from a Rust component that returns a stream of a primitive type (u32, s32, f32, f64) and verify the round-trip. The test calls the export, awaits the result, and uses a helper that repeatedly awaits stream.next() to drain the values. Floating-point tests use approximately equal checks for the obvious IEEE-754 reasons.

A design call worth flagging: while readable/writable streams are the standard JS-platform pattern, JCO is shipping with a minimal async-iterator interface first (an object with next / write / writeAll). The plan is to eventually support both — minimal iterator and full readable/writable stream — so component-emitted streams can be used directly as the platform-standard ReadableStream or WritableStream.

What's left for JCO P3: more lifting/lowering tests across all the types, then futures (similar to streams but one-shot). After that, the P3 implementation is hooked up — most of it already exists, just waiting for streams + futures to land.

A Vibe-Coded JavaScript Component-Model Host​

The most surprising update of the call: wcjs, a fully-TypeScript implementation of a WebAssembly component-model host — essentially the same job that jco transpile does — coded by Jelle van den Hooff using a large language model. The code base is high quality, well-documented, and passes a large number of upstream tests. It implements a full JavaScript parser and "visitor" that walks the WebAssembly binary, reads the intrinsics and canonical built-ins, and generates the code needed for P3.

Victor's read on it: this is a great code base for understanding P3 because spec functions are implemented very closely to how the spec is written and types are everywhere — which makes it dramatically easier to read than the equivalent Rust bindings in JCO. The plan is to integrate it as a backend for JCO so users can choose between the Rust js-component-bindgen and the pure-TypeScript wcjs implementation. Performance-wise the difference is minimal — both go through Wasm at compile time — and what matters more is that the build-time choice now exists. Jelle also produced a demo of a Go component running in the browser, compiled from a Go fork that implements P3, served via JSPI, with a roughly one-to-four-second cold start that gets faster with caching. The browser-side build emits a standard component Wasm that you can pull out and run anywhere — including Wasmtime — which is the demonstration of why the multi-host story matters.

WebAssembly News and Updates​

This call captures one of the most active weeks the WebAssembly JavaScript ecosystem has had. StarlingMonkey 0.30 re-enables Weval. componentize-js is mid-rewrite to Rust with wit-dylib. componentize-qjs brings QuickJS-NG into the component model. JCO 1.17.2 lands streams. wcjs demonstrates that LLM-assisted development can produce production-quality WebAssembly host implementations. Combined with the Bytecode Alliance's wit-dylib work, the entire interpreted-language story for the WebAssembly component model — Python, Ruby, and beyond — gets dramatically easier to implement.

What is wasmCloud?​

wasmCloud is a CNCF project for building and running WebAssembly components anywhere — cloud, edge, or Kubernetes. The v2 release imminent at the time of this call is the Kubernetes-native architecture where wasmCloud hosts run as Kubernetes pods, workload deploys are managed by the runtime operator, and HTTP traffic is reverse-proxied directly to host pods via the runtime gateway. wasmCloud supports components written in Rust, Go, TypeScript, Python, and C# — and through componentize-js, componentize-qjs, JCO, and wit-dylib, the JavaScript/interpreted-language story is rapidly catching up to the compiled-language one.

Topic Deep Dive: wit-dylib and Multi-Engine componentize-js​

The technically pivotal piece of this call is wit-dylib — a single C-header abstraction that lets any language implement a *.wasm shared object and have it lifted into a fully-typed P3 component. Today, supporting a new interpreted language as a wasmCloud guest meant building a bespoke componentize toolchain (componentize-py, componentize-net, componentize-go). With wit-dylib, the architecture inverts: you implement one header file and the component model takes care of the rest, including streams, futures, and all the P3 async machinery. componentize-js becomes one of N consumers, alongside componentize-qjs and whatever community projects follow. For platform engineers evaluating WebAssembly for polyglot deployment, this is a meaningful step-change in how quickly new languages can join the ecosystem.

Who Should Watch This​

JavaScript developers considering WebAssembly components should start with the componentize-js rewrite walkthrough at 09:30 and the JCO streams demo at 17:53. Runtime contributors interested in multi-engine JS will want the componentize-qjs section at 14:00. And anyone curious about how far LLM-assisted development can go should jump to the wcjs walkthrough and Go-in-browser demo at 25:00.

Up Next​

The wasmCloud v2 release will land within 48 hours, with documentation and TypeScript repo updates following immediately. JCO's P3 host support continues: more lifting/lowering tests, then futures, then full P3. componentize-js continues its Rust rewrite; componentize-qjs continues on QuickJS-NG. Next week's wasmCloud Wednesday will be hosted from Amsterdam during KubeCon EU.

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 →