I apricate the time that the deno team has spent having a separation between deno/deno_core/deno_runtime. The deno codebase is well organized and overall high quality.

One issue I've run into as someone who has embedded these libraries into another other project is that there are a lot of really nice features are only available in deno proper (everything under their cli/ directory https://github.com/denoland/deno/tree/main/cli) vice deno_runtime and deno_core. Specifically, typescript is implemented in cli/

A user of runtime or core could just reimplement those features piece meal, however I ended up just forking deno and adding a lib.rs that just exposes the code in cli/ as a library, and it has worked out pretty well for my needs.

Edit: Elsewhere in the thread the author of this blogpost linked another blog post where they describe getting TS without having to use cli - something I will look into!

Agreed, I felt the same when toying with this concept for the first time. I initially thought I could just build directly off of deno_core, but quickly learned there's a lot you'll have to implement. Much of what I perceived as deno is really just the cli crate and other dependencies that feel somewhat "internal". Some examples of things you'll need to implement and reference from the cli I ran into were:

1. module loader: https://github.com/denoland/deno/blob/main/cli/module_loader...

2. runtime interfaces (workers): https://github.com/denoland/deno/blob/main/cli/worker.rs

3. invocation of the runtime: https://github.com/denoland/deno/blob/main/cli/tools/run.rs#...

4. permissions: https://github.com/denoland/deno/blob/main/runtime/permissio...

You can wire up some of these other packages or potentially even the CLI itself to avoid re-implementing much of the runtime over again, but it's a heavy dependency for a few crucial utilities that feel like they could exist in more lightweight runtime crates.

At the end of the day, I feel like most people potentially want to offer APIs through the runtime as opposed to a package or framework (think Netlify edge functions, Shopify functions). I wonder if they are reserving this interface for Deno subhosting customers rather than making it more ergonomic for a self hosted runtime. Kind of similar to how the runtime crate injects Deno's Web Platform JS implementations: https://github.com/denoland/deno/tree/main/ext

Can you tell us a bit about a project you've embedded it in? Was it done to provide a scripting interface to an application? Something else?

It was an emacs fork that used TypeScript/Javascript alongside elisp. I am currently in the process of upgrading to deno 1.30.3 right now.

Hey, I'm the author of this blog post.

Just yesterday we posted a second part of this post [0] where we add "fetch"-like API and TypeScript transpilation.

Happy to answer your questions.

[0] https://deno.com/blog/roll-your-own-javascript-runtime-pt2

This is very interesting (and well written) but I'm trying to imagine a real-life use case for this. Are there any you can think of?

Just an FYI, the cross-post link at the bottom of part 1 is currently incorrect (pt-2 vs pt2).. leads to a 404

Thanks! This should be fixed now.

    a basic knowledge of Rust
    a basic knowledge of JavaScript event loops 

Any recommendations for these pre-requisites?

You should be good to go after reading through the Rust book [0] and watching this video [1]

[0] https://doc.rust-lang.org/book/ [1] https://www.youtube.com/watch?v=8aGhZQkoFbQ

Thank you!

The actual runtime is

    deno_core::JsRuntime

So it's not really fair to call this "your own runtime." quickjs is another alternative here, and you can use it anywhere that supports the C FFI.

Yes but it’s MIT licensed, so it really is free to be yours, if you can figure out how to change that string.

the Deno V8 wrapper doesn't have the same marketing ring