so right now, in order to call a roc function from TypeScript on NodeJS, every time we roc build we also have to run clang (or zig, as it happens, for cross-compilation) to combine the roc output with the NodeJS C glue in order to end up with a binary that can be called from Node
I just realized that it doesn't have to be this way
and that it's achievable to do roc build and then it Just Works, no need for clang/zig/etc
this is because Node defines its modules at runtime; there's a C function we call at runtime that basically says "register this (Roc) function in this module"
which in turn means we can have roc glue generate some sort of config file which says "here are all the roc functions in the binary that roc build will have created, and their types"
at which point when Node boots up, it can do the following at runtime:
dlopen the binary created by roc build (which does require that surgical linking is able to support dynamic libraries)so it moves a bit of work from build time to server initialization time, but that's basically a non-issue
and then what you get is that nobody doing development needs to be running clang or zig - that can be done once for a generic "run roc functions on Node via a config file you generate with roc glue" and that's it
although to be fair, I'm not sure how the cost of clang/zig compares to the cost of generating and loading this config file, since each step in the feedback loop requires doing either all of the former or all of the latter before you have a running server :thinking:
Oh interesting!
It sounds like your loader would be doing strictly less work, never more, since it's not compiling. And maybe simpler dependency management?
Interesting. You should be able to test all of that by just building a shared library of the roc app. That should be way faster than call zig or c or a regular link process.
Last updated: Jun 16 2026 at 16:19 UTC