Kat Marchán (they/she) (Jul 15 2025 at 18:12): Kat Marchán (they/she) (Jul 15 2025 at 18:12):Hi,
Just to let y'all know that I have time allocated for mid-August to do "full" Node.js compatibility for StartlingMonkey.
I'm happy to collaborate with others, jump on existing efforts, etc, but I do intend to work on this full time for whatever period of time is required for that compatibility to be in place.
Ref: https://github.com/bytecodealliance/StarlingMonkey/issues/188
I don't intend to use any kind of shim or "compat layer", but to literally implement this directly into StarlingMonkey, but we can figure out if that's the right approach. See https://github.com/bytecodealliance/StarlingMonkey/pull/103 for the current PR for doing that.
If this is going to be implemented natively, we'll want to have finalized whether the Rust port is happening or not. I would like to only do this in one language, instead of having to port it over to Rust in some unknown future.
Yosh Wuyts (Jul 15 2025 at 18:17):cc/ @Tomasz Andrzejak
Kat Marchán (they/she) (Jul 15 2025 at 18:17):also /cc @Till Schneidereit
Tomasz Andrzejak (Jul 16 2025 at 09:04):Hey Kat! Great to hear you're planning to work on this!
My strong preference would be to implement this in Rust. Beyond the obvious benefits like memory safety and better DX, I believe a significant portion of the API surface will involve streams — which currently, at least for me, has been the most common source of errors when running compatibility layers like unenv on top of StarlingMonkey.
My instinct is that implementing streams in Rust will be much more straightforward than in C++. Till mentioned that we'll eventually need to reimplement Web Streams in StarlingMonkey, and we should do that in Rust.
So yeah, having a Rust framework in place before this effort begins would be extremely valuable!
Ralph (Jul 16 2025 at 09:05):love this!
Last updated: Dec 06 2025 at 07:03 UTC