4 ms·
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 tha
by afavour 3mo 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 3mo 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 3mo 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.