3 ms·

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?

dgellow 2mo ago
> 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
andai 2mo ago
[flagged]
allthetime 2mo ago
Compiling to a single binary for prod is the killer feature imo.
afavour 2mo ago
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?
- holysantamaria 2mo ago
  Spawning a process and piping the input? This does require having a node available at runtime though. Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?
  - afavour 2mo ago
    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 https://developer.apple.com/documentation/javascriptcore
    - tredre3 2mo ago
      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 2mo ago
        > 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.

dgellow 2mo ago

> 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

andai 2mo ago

[flagged]

allthetime 2mo ago

Compiling to a single binary for prod is the killer feature imo.

afavour 2mo ago

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?

holysantamaria 2mo ago
Spawning a process and piping the input? This does require having a node available at runtime though. Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?
- afavour 2mo ago
  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 https://developer.apple.com/documentation/javascriptcore
  - tredre3 2mo ago
    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 2mo ago
      > 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.