> To gain access to the Deno (and Node.js compat) standard library used by Deno requires forking deno_cli as they have largely coupled these additions to the main executable.
This is no longer the case. While it does not currently provide a stable API, that functionality exists in the deno_runtime crate and is relatively easy to reuse.
The deno_runtime crate is indeed easy to use however the exts that provide compat for web apis and Nodejs compat still require forking deno_cli. You can use some of their ext crates https://github.com/denoland/deno/tree/main/ext but not everything.
Also using ops within Workers is challenging, particularly if they share state.
The async example in the readme is weird. It appears to be an example of tokio::sleep, where you synchronously call into your library before you sleep. Nothing about your library usage is async. In fact, the whole usage of the library is blocking, so I can't even call it from my existing async code. I'm expecting: I can call my async Rust function from JavaScript, and I can await a JavaScript async method. The example should at the very least be using `async fn main`.
You're right. I've actually removed it because it doesn't make sense.
There's now `call_blocking` and `call_async` to call a JavaScript function from Rust from normal and async call sites
Still built on v8, but it claims to present a more Rust-friendly API than competitors
It's more that it's an abstraction that models JavaScript rather than v8. I'm actually planning to have a swappable engine with an implementation for QuickJS. It will be enabled with `JsRuntimeOptions { backend: JsRuntimeBackend::QuickJS }`.
The public API should remain the same, as will the extensions, so swapping out backends is an interesting idea to explore
> To gain access to the Deno (and Node.js compat) standard library used by Deno requires forking deno_cli as they have largely coupled these additions to the main executable.
This is no longer the case. While it does not currently provide a stable API, that functionality exists in the deno_runtime crate and is relatively easy to reuse.
The deno_runtime crate is indeed easy to use however the exts that provide compat for web apis and Nodejs compat still require forking deno_cli. You can use some of their ext crates https://github.com/denoland/deno/tree/main/ext but not everything.
Also using ops within Workers is challenging, particularly if they share state.
The async example in the readme is weird. It appears to be an example of tokio::sleep, where you synchronously call into your library before you sleep. Nothing about your library usage is async. In fact, the whole usage of the library is blocking, so I can't even call it from my existing async code. I'm expecting: I can call my async Rust function from JavaScript, and I can await a JavaScript async method. The example should at the very least be using `async fn main`.
You're right. I've actually removed it because it doesn't make sense.
There's now `call_blocking` and `call_async` to call a JavaScript function from Rust from normal and async call sites
Still built on v8, but it claims to present a more Rust-friendly API than competitors
It's more that it's an abstraction that models JavaScript rather than v8. I'm actually planning to have a swappable engine with an implementation for QuickJS. It will be enabled with `JsRuntimeOptions { backend: JsRuntimeBackend::QuickJS }`.
The public API should remain the same, as will the extensions, so swapping out backends is an interesting idea to explore
[dead]