4 ms·

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

by Jarred 2y ago

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

candleknight 2y ago
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.
- NoahKAndrews 2y ago
  NAPI and WASM let you use optimizing compilers, so they're suitable for use with larger C and C++ codebases
jll29 2y ago
Cool - if this was an unplanned "accident" then I want to see how your planned projects look like.
hiccuphippo 2y ago
This is very cool. Is the code compiled on every run or does it get cached?
0x000000000 2y ago
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?
- hiccuphippo 2y ago
  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.

by Jarred 2y ago

candleknight 2y ago

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.

NoahKAndrews 2y ago
NAPI and WASM let you use optimizing compilers, so they're suitable for use with larger C and C++ codebases

jll29 2y ago

Cool - if this was an unplanned "accident" then I want to see how your planned projects look like.

hiccuphippo 2y ago

This is very cool. Is the code compiled on every run or does it get cached?

0x000000000 2y ago

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?

hiccuphippo 2y ago
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.