Roll your own JavaScript runtime (2022)(deno.com)
deno.com
Roll your own JavaScript runtime (2022)
https://deno.com/blog/roll-your-own-javascript-runtime
17 comments
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
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
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
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
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
[0] https://doc.rust-lang.org/book/ [1] https://www.youtube.com/watch?v=8aGhZQkoFbQ
Thank you!
The actual runtime is
deno_core::JsRuntime
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!