[Suggestion] Decoupling Deno from V8 Engine
Closed this issue · 5 comments
Hi,
There has to be an abstraction layer or a messaging interface between Deno and V8 if there's none already. It'll save us from writing and managing ChakraShim like shims.
Mozilla is making really impressive changes at the core architectural level; adding AR/VR and WebAssembly support, and writing everything in Rust to safely and efficiently utilize memory and modern multicore CPUs and GPUs. Servo's high-performance is an example.
Electron heavily depends on Chromium and its nearly impossible to switch to Gecko in the future. Even the idea of it seems impossible. Node.js depends on V8 so its also going to suffer at some point as we're seeing rapid improvements in Chakra and SpiderMonkey.
It'll be interesting to see Node.js/Deno apps run natively on desktop environments, SpiderMonkey on GNOME or Chakra/JsRT on Windows.
MongoDB has already moved from V8 to SpiderMonkey.
It would be wise to consider this at an early stage.
There has to be an abstraction layer or a messaging interface between Deno and V8 if there's none already. It'll save us from writing and managing ChakraShim like shims.
That seems like abstractions for abstractions sake. What is more important, IMO, is to keep them as loosely coupled as possible, being very careful to expose any APIs that are not part of the accepted browser standards, which means potentially not supporting some things that V8 (or whatever) races ahead to support. Abstractions are one way of loose coupling, but they still take a lot of "prediction" of what abstractions you do need.
@HannanAkbar I agree that v8.h API should not be exposed to users. I would like to use N-API for extension modules. But generally this is all up in the air.
I'm currently working on a C library libdeno which does wraps V8, does snapshotting and message passing. (Similar to v8worker2 but not tied to golang). This will be the core infrastructure of Deno. You can see the work in progress API here:
https://github.com/ry/deno/blob/041e503838d1f030faca08d93de4aaadf0bc4b98/deno2/include/deno.h (If that URL dies I've copied the source here: https://gist.github.com/ry/abcb87bd58e7cb1f08cd94a56b8d4a80)
That said, Deno is strongly tied to V8 and I have no plans to support engines.
@kitsonk I think if we're going to use N-API for extension modules and wrapping V8 with libdeno and its not scattered everywhere in the codebase then we're reducing tight coupling. 👍
@ry I know right now focus is on V8 and its difficult to maintain Deno with two engines, but are we open to experiments to lay out a PoC? This will give community members a direction.
@ry N-API support would be awesome! 👍
@ry if you do decide to expose the engine via N-API and find any V8 API for which there is no N-API equivalent and which you believe would fit the N-API pattern, please open an issue on https://github.com/nodejs/abi-stable-node/issues/new.
We are also working on separating out the Node.js-specific portions of N-API into their own header file. The followings would go into the Node.js-specific portion (just a personal draft of the list for now):
napi_module_register()napi_*_buffer_*()napi_*async_work()napi_async_*()napi_get_node_version()napi_get_uv_event_loop()napi_*_threadsafe_*()
The rest would be considered engine-related APIs.