Kat Marchán (they/she) (May 27 2025 at 18:54): Kat Marchán (they/she) (May 27 2025 at 18:54):Hi!
I'm pretty invested in seeing https://github.com/bytecodealliance/StarlingMonkey/pull/103 land and in general making it so we can do more StarlingMonkey work directly in Rust. I'm wondering what I can do to support getting this moving forward. My current priority is getting Node.js and WinterTC stuff landed, and I would much rather we build all those bits of new code on top of Rust instead of having to go back later and rewrite everything.
/cc @Till Schneidereit
Kat Marchán (they/she) (Feb 13 2026 at 22:10):Resurrecting this a bit: I was told someone had actually picked this up recently? Is that right?
Victor Adossi (Feb 14 2026 at 00:49):Yup! @Till Schneidereit is working on it :)
I might be a bit out of date but you can see the work here, under the working name starlingshell:
https://github.com/tschneidereit/StarlingMonkey/tree/better-rust-builtins/runtime/crates/starlingshell
Till took the time to integrate and reuse a bunch of upstream implementations which has been great, but IIRC at the last JS meeting he was mentioning how there's a lot more to be done, I'm sure he could use a hand!
(please feel free to correct me Till!)
Ralph (Feb 17 2026 at 10:12):Victor Adossi said:
Yup! Till Schneidereit is working on it :)
I might be a bit out of date but you can see the work here, under the working name
starlingshell:
https://github.com/tschneidereit/StarlingMonkey/tree/better-rust-builtins/runtime/crates/starlingshellTill took the time to integrate and reuse a bunch of upstream implementations which has been great, but IIRC at the last JS meeting he was mentioning how there's a lot more to be done, I'm sure he could use a hand!
(please feel free to correct me Till!)
Hey, this would be great to get @Kat Marchán (they/she) 's help, and @Tomasz Andrzejak as I understand it is also available to make this work.
Ralph (Feb 17 2026 at 10:13):@Till Schneidereit is there a way to break this work up and have all three be productive in parallel? From what i understand, this would be the BOMB to make work properly and would advance quite a bit in several dimensions......
Kat Marchán (they/she) (Feb 17 2026 at 21:02):I'm happy to find ways to help as long as I'm not stepping on toes or duplicating work.
Till Schneidereit (Feb 18 2026 at 16:01):hey all, I'm very sorry for not giving an update on this in such a long time!
The tl;dr of the current situation is that I took on more than I should've in trying to port much of Servo to WASI without threads at the same time as trying to understand WASIp3 async, and at some point got too lost to make meaningful progress anymore.
The idea still seems right to me: instead of reinventing much of what Servo had to invent for good JS bindings support, we'd reuse theirs—and in the process get access to their implementation of many/most of the builtins relevant to WinterTC compatibility. And I think we can still get there—but we can't block progress on, well, anything on it further.
So, I sort of hit reset on this a couple of weeks ago by asking @Joel Dice to look into the WASIp3 part along with a replacement for ComponentizeJS to support custom WIT interfaces. This work to some degree naturally introduces some amount of Rust support, because it depends on wit-dylib.
In parallel to this, I'm working on porting the WIT bindings the current C++ implementation relies on to Rust as step one of then porting them from WASIp2 to WASIp3. In doing so, I'm doing the minimal amount of work needed to support both the existing C++ builtins as well as new Rust builtins. We can then iterate on providing better abstractions for writing Rust builtins, but will have the basis for starting to write any at all
Till Schneidereit (Feb 18 2026 at 16:02):oh, and based on all this I'll return to integrating Servo builtins, with the goal of ultimately replacing the C++ builtins we currently have entirely. But that can be a gradual process, instead of the all-at-once one I took before
Joel Dice (Feb 18 2026 at 16:17):This is what I've done so far: https://github.com/dicej/componentize-js. One test passes :partying_face:
I had to pause that work temporarily last week to work on a few more urgent things, but hope to come back to it by the end of this week. I don't know that it will benefit from more people working on it quite yet, but I expect that will change after a couple of weeks of focused work.
Ralph (Feb 19 2026 at 17:08):as we have plenty of interest, when @Joel Dice you find a thing to fork off for someone else, do ping!!!! And thanks a ton Till, for all the hard work -- it teaches everyone.
Till Schneidereit (Feb 20 2026 at 11:39):I'm getting closer to that point: I have a version of StarlingMonkey working locally that passes the test suite using WASIp3. There are some bugs around concurrent reuse to be worked out and lots of cleanup to be done, but it's progressing well. That port is using Rust for the WIT bindings, instead of going through wit-bindgen's C backend, as described before.
Once that fully works, I'll port the core of the current runtime over to Rust (which is a smaller task than it'd seem), while still supporting the current C++ builtins.
And then, I'll provide a recipe for creating new Rust builtins with reasonable abstractions—at which point I think we should be in good shape for others to start writing builtins.
Till Schneidereit (Feb 20 2026 at 11:39):I'll provide another update on all this early next week
Till Schneidereit (Feb 24 2026 at 23:00):It's almost midnight on Tuesday my time, so in a few minutes "early next week" will have passed. So: an update. I don't yet have code to share, but I have a thing working that has a core Rust runtime with a clean build system without CMake, built on mozjs.
It has the wiring to set up to compile and install existing C++ builtins, with the console one integrated and fully working. I.e., it can print "Hello, world" and things.
It can also load JS files as either legacy scripts or modules, and for the latter it uses Oxc Resolver to do Node-compatible resolution—a significant improvement over the previous state of affairs!
It does not yet have any HTTP support, and async stuff is rudimentary. But I have separate PoCs for both of those pieces that I'm now working on integrating to enable more builtins.
Currently all of this compiles natively and to WASIp2. I would like to keep it that way by introducing a native implementation for all APIs that on Wasm will use WASIp3 imports, but I'm not yet certain that will work out.
So far for getting back to parity(++). But this thread is ultimately about how to add new builtins. And do I ever have a story for that!
I put together a bunch of proc macros that make it very easy to define builtin classes and modules, with inheritance, instances of one class holding references to other classes as automatically managed GC pointers and all that good stuff. The code using these can be very clean and idiomatic, but still has full flexibility WRT how to interpret and create JS values, etc.
Till Schneidereit (Feb 24 2026 at 23:04):Here's a class definition:
#[jsclass]
struct MyClass {
data: String,
}
#[jsmethods(rename_all = "camelCase")]
impl MyClass {
#[constructor]
fn new(data: String) -> Self {
Self { data }
}
#[getter]
fn data(&self) -> String {
self.data.clone()
}
}
The result is usable from both JS
let my = new MyClass("foo");
let data = my.data; // "foo"
... and Rust:
let my = MyClass::new(cx, "foo".to_string());
let data = my.data; // String("foo"), which can and should probably be improved
And here's a module:
#[jsmodule(rename_all = "camelCase")]
mod math_utils {
pub const PI: f64 = std::f64::consts::PI;
pub const MAX_VALUE: f64 = 1000.0;
pub fn add(a: f64, b: f64) -> f64 {
a + b
}
pub fn multiply(a: f64, b: f64) -> f64 {
a * b
}
pub fn safe_divide(a: f64, b: f64) -> Result<f64, String> {
if b == 0.0 {
Err("Division by zero".to_string())
} else {
Ok(a / b)
}
}
}
Use in JS:
import {safeDivide} from "MathUtils";
safeDivide(1, 0); // Throws an exception. Proper exn types still to be done
that's it for now, next update soon, but probably after the Plumbers Summit
Kat Marchán (they/she) (Feb 24 2026 at 23:36):this is super cool! Thanks for the update (and the awesome work)!
Tomasz Andrzejak (Feb 25 2026 at 07:32):This looks amazing :star_struck:
Till Schneidereit (Feb 25 2026 at 11:22):Thank you both! It's been way way way too long a time coming, which I apologize for
Ralph (Feb 28 2026 at 11:33):all in on the complements here, @Till Schneidereit - great stuff. :-)
Joel Dice (Mar 05 2026 at 17:18):I made great progress this week on the new wit-dylib-based componentize-js. It's "feature complete" in the sense that it can handle arbitrary WIT worlds, including async imports and exports, futures, and streams, but still needs some work to make it usable and idiomatic. See the README.md for the current TODO list.
Till is going to post an update on his StarlingMonkey+Servo work soon, and we're going to do some planning early next week to determine how to integrate these projects together.
Last updated: Mar 23 2026 at 19:19 UTC