This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write.
Thus something like this would need a similar tool.
deno_bindgen exists which can be used to do this from Rust.
I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however.
There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?
JIT is a large attack surface, but it's mostly an attack surface from the perspective of migrating from "untrusted" (attacker-controlled) javascript execution, to arbitrary native code execution (e.g. malicious js on a webpage, breaking out).
If a Deno user wants to use FFI to invoke system("rm -rf /*"), they can*, and they don't need to exploit a JIT bug to do so.
FFI with JIT is almost certainly a larger attack surface than FFI without JIT, but in practice I don't think it's a big difference.
*iiuc Deno is sandboxed by default, so presumably FFI capabilities (and the attack surface implications thereof) are something the developer needs to opt into from the start.
Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?
Except node, like Java, moves along, making those that made a bet being a better Java 8, seem irrelevant with time, unless they happened to have a platform holder sponsoring their existence.
As a heavy Node user, I think it was a mistake for Deno to try to bake in a compatibility layer with Node. It's a moving target, and will detract from other valuable work.
Node compatibility is not something that will get me to switch to Deno. I will switch once I'm not restricted to the bundled TSC version, and there is a well supported bundler for client code.
Thus something like this would need a similar tool.