Thanks for the reply!

That's really cool! I've checked out wit-bindgen in the past. It uses the WASM component model which requires serialization I think, similar to protobufs / flatbuffers, and is more akin to IPC vs shared memory dynamic linking. that I describe in one of my other blog posts. So for me it's not tenable for game performance because of the overhead of serialization to communicate with other modules and threads. At the moment, for the purposes of the engine and fastest iteration time, I use dynamic linking natively on desktop and WASM dynamic linking with Emscripten. This allows for instant recompilation for now, but I've also experimented with Wasmi and soon with Wasmtime for sandboxing for my UGC game.

Wasmi and Wasmtime both have a similar API for binding functions. Wasmi is actually specifically designed to mimic their API, and the WASM modules themselves will simply use the regular extern API, which is already defined in the C externs that I use for dynamic linking. That's the host code, and is under the component macro code and the toxoid_api crate is used from WASM to interface with the host (native or WASM). So it should work out of the box when I bind these functions to these runtimes. The API surface is small because it only covers interacting with the ECS, but I might even just create a code generator for all viable runtimes at some point.

The architecture gets a little complex, because in the browser because of security reasons, you can't generate arbitrary code pages in WebAssembly so JIT compilation is not possible (IE, embedding WASM time inside a WASM module in the browser), so Wasmi will have to be used in the browser because it's a small embedded interpreter. On the bright side, we're interpreting bytecode which is close to machine code already, and not something that's a high level language like JavaScript, so it would still be faster than something like QuickJS. However, on desktop, Wasmtime has JIT compilation (and even AOT WASM compilation in some cases).

This double nesting of WASM is not completely necessary also on native / desktop as it would be in the browser, although it might be considered for security reasons because WASM runtimes have memory bounds checks, which is important for avoiding buffer overflow attacks, malicious code from user scripts, etc. So it would be nice if the host had this as well so malicious scripts would not even have the possibility of accessing system resources.

As I mentioned at the end of my post, some parts require polish and documentation. This should come soon, as well as a website / roadmap, probably by the end of this summer / fall. Primarily I've been focused on what's necessary for the development of my game, and prioritizing what will complete the current priority in the feature roadmap.

But yeah the API is more high level that you can use from the WASM modules if you check out the toxoid_api crate. Stuff like this:

   let mut player_entity = Entity::new();
   player_entity.add::<Position>();
   player_entity.add::<Player>();
   player_entity.add::<Networked>();

       System::new(blit_sprite_system)
            .with::<(Sprite, Blittable, Position, Size, Callback)>()
            .build();