support bun as an alternative to nodejs for the server runtime environment

[williamstein]

Currently we use node.js for tooling and running python-wasm on the command line.

However, there is a new project https://bun.sh/ that is similar to Node.js, but written using Zig instead of C/C++. Since (1) we're also using Zig and typescript extensively for python-wasm, and (2) bun is very fast and modern with native typescript support, it would be natural to use bun for python-wasm, at least optionally. It might me faster startup times, faster execution, etc., and also easier to read code if we want to dive into the runtime itself. A blocker prerequisite for this is WebWorker support, which bun.sh does NOT have. It's on the roadmap here:

oven-sh/bun#159

[williamstein]

WebWorker support might not be a blocker at all. I can instead write a native extension module and use that to get input from stdin. I don't see any reason why that wouldn't work...

[williamstein]

WebWorker support is definitely not a blocker, though of course there will be limitations (only a single webassembly process can possibly run at once for subprocess.Popen). Regarding the native extension module, it looks like I should instead have a version of our posix-node package that instead is written using Bun FFI, which fully supports using Zig.

[williamstein]

Here's the webworker thread: nodejs/node#43583

Also, it would be interesting to see how's bun's event loop, etc., deals with just forking/execing via bun ffi (and stopping it). Maybe it behaves differently than node.js, which randomly crashes!? If os, we might not need webworkers for our use case, and can rewrite to use them later when they are implemented.

[williamstein]

The first step would be to port the debug package

https://www.npmjs.com/package/debug

to work with bun, since we use it everywhere and it is very helpful with debugging. Currently it doesn't import because process.stderr doesn't exist with bun, but it is assumed to exist by debug.

[williamstein]

I may revisit this in a year or so, but for now the focus will be 100% on node.js, due to wide support and integration with electron.js, and no compelling advantage for cowasm to use something else.