6 ms·
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 runti
by 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 agoThat’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 agoBut 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.