Curious if Deno's adoption of the N-API ABI interfaces could make a Deno mode practical?

[josh-hemphill]

Somehow google never showed me this project when I tied searching for Java <-> Node.js, I had started working on using the new Project Panama preview (w/jextract) to bind to the early example libnode package. I kind of wanted to go the route of Deno, but at the time it didn't have a ABI, and that would have been too much work.

So I've been following the PRs in Node and Deno on the ABI and embedding APIs and it sounds like the intention is for both to use the same ABI for interaction, and the ABI embedding API to be separate but still standardized such that there's limited differences between runtimes.

So I'm curious if once the embedding ABI APIs land in both, if this project is structured such that additional runtimes could be added without too much additional work?

[caoccao]

Good question. Here are my thoughts based on the facts till now (Oct, 2022) for your reference.

Javet doesn't fully rely on the so-called ABI to interact with libnode. Instead, Javet directly references a few source files from both V8 and Node.js to get some advanced features. So, I hold concern on this embedding ABI alignment. The additional work might be beyond the imagination.

For now, I wouldn't consider Deno as its performance is way below the public expectation. Also, the major Javet users use it in multi-tenancy applications where non-technical tenant users are allowed to execute custom scripts. I believe one of the crucial facts is those users will never understand Static Typing which means Deno mode is useless.

By the way, Google is not friendly to new projects like Javet. Duckduckgo does the work in a better way. Stackoverflow treats me in a hostile way, so I won't answer any questions there. Actually, Github search seems to be the best.

[josh-hemphill]

those users will never understand Static Typing which means Deno mode is useless

The deno_runtime rust crate that exposes things for using it as a lib does not include the typescript crate (though if they implement the embedding abi they might start shipping a dylib themselves that has everything the cli does).

I'd been looking at it for its webby, literal module system; I was experimenting with rewriting the Minecraft <-> javascript mod Grakkit to use Node instead of the really limiting GraalJS; since GraalJS doesn't have a standard module system, moving to Node or Deno would have been a similar experience for people who'd written stuff for Grakkit. The Grakkit community has been talking about trying to use GraalVM native binaries to make minecraft faster but lean on a fuller JS runtime to still let people dynamically load JS files to continue extending it and doing web servers/apis and stuff without directly affecting the minecraft main thread, and not having to deal with all the tooling for setting stuff up for Node would have made things pretty clean.

[caoccao]

Many Javet users develop Minecraft mods with Javet.

Javet allows both ESM and CommonJS in the Node.js mode, and Javet even allows intercepting the module load API to inject arbitrary Java or JS code. I don't think GraalJS is able to do that.

Regarding the performance, GraalJS JVM mode performs 5-10x slower in the warm-up phase than V8 does. I don't think the mod users will accept 10,000 rounds of warm-up per input to gain 1s faster in the 10,001 round. According to you reply, you might have been struggling in the poor performance already. The GraalJS AOT mode performs well (still slightly below V8) but it doesn't allow dynamically loading JS + Java for the interop. The mod owners will never know how many dynamic stuff are required by the arbitrary scripts fed by the mod users. Packing everything up in the AOT image could partially resolve that, but might not be a good idea, as it sounds like packing 300,000+ Node.js modules up as a whole. Javet well keeps the balance between the performance and dynamic part.

In fact, the Javet Node.js mode was proposed by a group of Minecraft mod developers. Many features came from they requests.

[josh-hemphill]

Yeah, the people I've been talking to on in the Grakkit community were looking at Javet or Panama bindings to get away from GraalJS.
None of the use cases circulating in our discussions explicitly included running untrusted code. There was talk of compiling using GraalVM Native Image without using GraalJS, though no one has actually checked if the GraalVM Native Image builds support JNI or Panama.
Though on the topic of untrusted code, Deno does let you set patters for allowed import sources, so you could have a set vetted packages under some path or domain to provide libs that are too big or specific to just keep in the global scope all the time.

[caoccao]

Javet is more powerful than Deno is in terms of the security.

Javet allows intercepting calls at module load, function call, property access, proxy... etc. level. Java applications can take complete control of every step. In Deno, I think there are 2 typical ways (1) Write a native extension; (2) Hook at JS/TS level. (1) is not possible in your use case. (2) is still insecure and ineffective. Javet allows the Java applications to extend Node.js without writing native extensions which brings much better flexibility and development efficiency.