This was an unplanned feature I worked on mostly a month ago on a Saturday for fun. Happy to answer any questions
To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice
Awesome work on this, it looks like a game changer!
From my (admittedly limited) knowledge on this space, it seems like this is a straight upgrade over WASM, with the only limiting factor being that your stack is limited to Bun + C. Are there any downsides of this feature when compared with the alternatives mentioned at the start of the article? There are some tradeoffs listed at the bottom but I'm not sure how napi/WASM perform in those aspects either.
There is something I don't understand about something. Why are individual solutions sought instead of nodes with an existing and large community? Why don't you pass bun's properties to Node?
You mean why not implement these things directly in node instead of a separate runtime? There's significant differences between runtimes. Node uses V8 while Bun uses JavascriptCore. Node uses C++ and Bun uses Zig. I'd guess it would be very difficult to land these changes in Node.
But Node now will have some catch up to do. It is already adding support for running Typescript without transpiling it to js first and that's because Bun and Deno provided it first and people saw it was a good idea. Maybe Node will add these things in the future.
To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen and include paths. Also added support for parsing the deprecated attribute used in lots of Darwin headers. C parsers seem a lot simpler than JavaScript which is nice