Okay, I see, you define JS functions that pass the objects around like black boxes, turning x.f(y) to f_(x, y) and then you load f_ via the FFI. Does that mean the Hoot FFI is limited in how it can deal with JS objects?
Hoot isn't any more limited than what the WebAssembly security model allows. In Wasm, a heap object coming from the host is typed as (ref extern). External references are opaque, if that's what you mean by "black box". You cannot inspect their contents from Wasm. The reverse is also true for heap objects coming from Wasm; they cannot be inspected from the host (JS in this case). Having used Wasm for awhile now, it feels similar to using a C FFI where the library you are linking against uses pointers as handles to objects, only more secure. Like in SDL when you create a surface you get a pointer to it and most operations require passing that pointer to some other SDL function. The transformation of x.f(y) to f_(x, y) is a fairly common pattern when writing bindings because JS is object-oriented but Wasm only speaks in terms of statically typed functions.
Thank you for the explanation. The way you've written Strigoform, it looks to me that all drawing operations are being delegated to Javascript (with HTML5 canvas?) Wouldn't another codeflow be to have WASM for backend, JS for drawing the bitmap on screen and SharedArrayBuffer for the bitmap (shared between WASM and JS)? Is this possible?
edit: I'm reading the Hoot manual now, trying it out.
All the drawing operations have to be delegated as a wasm module cannot perform any i/o without support from the host system. It's not currently possible to write to a SharedArrayBuffer from wasm (should get resolved some day), but if it was then you could write a purely software renderer in Scheme and just send the final bitmap over to JS to render in a canvas. You could do this without SharedArrayBuffer right now but it requires a byte-by-byte copy from wasm to JS which isn't great. I wouldn't recommend this approach anyway because your game wouldn't be utilizing the GPU at all. HTML5 canvas uses hardware acceleration, which is why I think it is a good option for the time being.
In the future, when we can efficiently share blobs of binary data without copying, WebGL/WebGPU will be the way to go. This will open up the path for existing Guile game libraries like Chickadee to run on Hoot.