[beeandapenguin]

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