What makes Bun Bun is all the things that got removed from this project. Node is already powerful enough and well maintained. Why would anyone use this?
The developer is quite clear about not wanting to make Bun. They want to make a reusable JavaScript runtime for Zig. How would you execute a Node runtime in Zig?
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”:
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.
> 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.
> The main design decision is to treat this as a runtime, not a general-purpose Bun replacement. A minimal launcher loads a pre-built entrypoint; features that require package installation, bundling, TypeScript transformation, or bun test are intentionally outside the scope.
The author is saying explicitly they don’t want to make a Bun replacement