[afavour]

That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime.

Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”:

https://developer.apple.com/documentation/javascriptcore

[tredre3]

But what does bun bring to the table in that scenario? Why not interface with javascriptcore directly and skip the (unmaintained) middle man?

Bun provides the node standard library, I suppose, but you likely don't want it in a plugin system. Because the bulk of it is to deal with web requests, or to allow system-wide file/network/process access. So you're going to re-implement your own safe library anyway.

[afavour]

> But what does bun bring to the table in that scenario?

There's a middle ground between "raw C API" and "full Node-compatible runtime". It sounds like this project is attempting to use that middle ground: the Zig wrapper around JavaScriptCore, rather than the whole abandonware project.

As per another comment here:

> This is not continuing the development on the original Bun (Zig) codebase. It is extracting a subset of that codebase for deployment purposes.