Node Congress 2023 - certificate of participation

Explore the new frontier of battle-tested backends. A two-day conference on all things Node.js, gathering Back-end and Full-stack engineers across the globe in the cloud is here to help you staying up-to-date on the latest Node.js tech.

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get free remote ticket & join me there with 5k other #nodejs devs & 35 great speakers #deno #cloudflare #awscloud

Node Congress 2023

Bartek Iwanczuk

In this talk, we’ll create a small JavaScript runtime from scratch in Rust. We’ll leverage the same ecosystem of components that Deno uses to show that rolling a bespoke runtime fitting your needs is simple and fun in 2023

Roll you own JavaScript runtime

Hi, folks. My name is Bartek, and I'm from the Deno team, and welcome to Roll Your Own JavaScript Runtime. Shortly about me, I started contributing to Deno in 2018, and then I've become the employee of the company in late 2019, and I've been with the company ever since. I'm currently leading the Deno CLI team, and should you have any questions or follow-ups, feel free to reach out with one of the links provided here. So, in this talk, we're going to talk a bit how to create or roll your own custom JavaScript runtime. We're not going to be doing this from scratch. This talk is based on a couple of blog posts we did in the past. We created a small JavaScript runtime called Run.js, and you can follow the links and the recording here if you want to learn a bit more about the history of the project. Well, it's, in our opinion, it's quite easy to get started if you wanted to create your own JavaScript runtime, thanks to the technologies we can now use, which are the engine for executing JavaScript, but also some of the infrastructure the Deno team provides. So, without further ado, let's jump right into it, but before we do that, we need to learn a bit more about Deno itself. So, Deno is a JavaScript and TypeScript runtime. It aims to be fun and productive to use. Deno supports importing source codes from a file system from remote servers using HTTP or HTTP as protocol, and we also support NPM imports using these NPM column specifiers. Deno is a TypeScript runtime in the sense that it's not needed to explicitly build your TypeScript sources to JavaScript before executing them. Deno can take care of that for you. It can transpile the sources, but it also can type check them. And Deno is built using Rust and using V8 JavaScript engine, so, in one sense, it's very similar to Node.js because we both use the same V8 JavaScript engine. However, Deno uses Rust for its native code, while Node.js uses C++. Deno comes with batteries included. We've got a lot of tooling that allows you to get up and running in seconds. You've got formatter, test runner, linter. You can even create a self-contained binaries that is you'll package all of the source code you provide and then give you a single executable file. It's kind of similar to the PKG NPM package you can use. Deno is also very heavily invested in web APIs. We've got a lot of them, most notably Fetch, TextEncoder, and TextDecoder, Blob. We've got support for WebStreams API as well as WebWorker API. There's many, many more of these APIs, and I strongly suggest you visit the MDM page for the API you're interested in and see if Deno supports the API. Deno and Rust, we need to understand a bit of history here in that the first iteration of Deno, the first prototype, was not really written in Rust. Instead, it was written in Go. However, due to the nature of Go, that is garbage collected, just like JavaScript, it was decided that we should go away from Go so we don't run into a situation where two garbage collectors are contesting against each other. So Deno was rewritten in Rust, which is a low-level language or systems language that doesn't have a garbage collector. I can say that this is probably the most influential decision ever made for the Deno project. Rust allows us to move very quickly, and it allows us to leverage a huge ecosystem of the crates available. Most of the crates are very high quality. For example, an HTTP crate that implements the HTTP protocol is very well tested, and it has great coverage, so we're very confident using it that we'll be adhering to the defined protocol. And last but not least, building Deno is really a breeze. Since Deno is fully integrated with Cargo, which is Rust's build tool or build system, it's just one command to run that will build your whole Deno binary, including V8, but not really. We don't force you to build V8 yourself. Instead, we do that in our CI pipeline so that you can use already pre-built binary archives, which saves you a lot of hassle since V8 is a huge project that takes quite a long time to compile. Another thing is that Deno is not a monolith. Rust provides you with an easy way to factor out pieces of your code to so-called crates. Crates are the equivalent of npm packages, so these are self-contained and reusable libraries that you can download and use whenever you want. And Deno, the CLI that you can download, is actually a collection of these crates that is intertwined together, and they are made to work together very well. One of the consequences is that we actually at Deno, here at Deno company, we don't actually ship just one runtime. We actually ship two different runtimes. We have the Deno CLI, but we also have Deno Deploy, which is our cloud offering. These runtimes are very similar, however they are not identical. Deno CLI is geared towards local development and deploying your code on your own server or LAMPAS, while Deno Deploy is geared towards being deployed to cloud-native containers and such. As a consequence, you as a user can choose which crates and APIs you need, and then you can mix and match them to roll your own runtime that fits your needs. Back to our run.js example runtime. What can it do right now? Well, it's just 140 lines of Rust and 37 lines of JavaScript. So that's not very much code, but it already has support for ES modules. It can transpile JavaScript to TypeScript on the fly just before execution, similar to how Deno can do it. We got an API to read a file, an API to write a file and delete a file. We got some rudimentary console APIs, so we can do console.log and console.error. We have a very basic fetch API, so it looks like fetch, but it can only really do get requests. However, with only 180 lines of both Rust and JavaScript, I think this is pretty phenomenal. So let me give you a super quick demo of the run.js runtime. I am in the repository that was already linked to you, and we can do cargo run dash dash example.ts. So we'll be executing a TypeScript file right here, and we got hello run.js as well content from fetch. So if we decide to inspect our example.ts file, we can see that it uses console.log. Then we got an interface, so that's definitely TypeScript. And then we do await run.js.fetch. So we're also using top-level await here, and sorry for the squeaky lines, but it seems my VS code setup doesn't understand it here. All right. So let's jump into some actual interesting things. So why would you want to use your own JavaScript runtime? So there are a few use cases. First of them is running untrusted code. So you might not believe us shipping Deno that it's totally safe to run untrusted code, so you might want to run it inside that container. However, now you've got a JavaScript runtime and then a container, so there's a bit of slowdown you can expect resource utilization from doing this double wrapping or double sandboxing, because remember V8, the JavaScript engine, is already a pretty good sandbox. So you might want a limited set of APIs, but on the other hand, you will use much less resources, which leads us to the second point that you might be resource constrained. So Deno ships with batteries included. We got a lot of tooling in the CLI, but sometimes that binary might be too heavy for you, or you might not need every API that we provide, and we provide many of them. You can interact with file system, you can do networking. There's a huge implementation of various web APIs, but if you don't need them, maybe you can just use a subset of them, putting in a smaller and slimmer binary. Or lastly, maybe your project could benefit from essentially shipping a self-contained single binary. You can already do this with Deno, but sometimes you maybe want to customize it a bit more, or again, remove some of the fat that is not needed in your particular use case. Right here, I linked you to a project of mine, a side project where I tried to wrap ESLint into a binary file that uses the same technologies we're going to be using in this example. Okay, so let's actually do some coding. Let's do something a bit exciting. So I think we may try to implement a set timeout API in run.js. Of course, this will not be the same set timeout API you can see in browsers, or in Deno, or in Node.js, because while this API is really easy to grasp and use, there are a lot of intricacies to it. What I want to do is essentially implement a set timeout in a way that will take a delay in many seconds, it will take a callback, and then just fire this callback, but we will skip validation, ensuring that everything is property-adhering to WebIDL, and so forth and so on. All right, so let's jump right into the code. I'm going back to my VS code. So, let's start by removing this example, and let's try to do set timeout, and I'm going to do, I'll make this bigger for you, I'll do hello world from timeout, and I want this to fire after a second, so the delay we pass is in milliseconds, so 1,000 milliseconds is a second, and now, if we try to execute this code again, and let me make this bigger for you again, so we executed our example.ts and got a reference error, set timeout is not defined. Well, this is expected. Set timeout is not built into the JavaScript engine, instead, it's a web API, or built-in API in Node.js, but we don't have it here. We need to implement it ourselves. So, let's do just that. I'm going to drop into the runtime.js file which is a file in which we implement all the APIs available in our run.js example. As you can see here, we're assigning to global this.console a console object which I don't want to see the typings, I want to see the actual object. Our console object has log and error function, and then we're assigning global this.run.js with run.js which contains the four APIs we already talked about. So, let's add another one. This time, it's going to be global this, set timeout, and our set timeout needs to accept two parameters. The first one is the callback, and the second one is the delay in milliseconds. So, how are we going to do that? Well, Copilot is jumping the gun here, but that's not exactly what we will do. We need to call into Rust to do something that will wait for the given delay, and only when we've finished waiting, we will fire out the callback. So, let's start by adding, by calling car of async, and we will call it offset timeout. Sure, thank you, Copilot. Then we will do delay as a first argument. That seems reasonable. Then we want to fire the callback, so, yes, that's pretty much it. Okay, so, what will happen if we just try to run it now? Oh, no, a typer. It says ops name is not a function. Well, that is expected, so we just try to call a random function from JavaScript, and this function is supposed to be defined in Rust, however, we haven't defined anything yet, so let's fix it right now. I'm just going to copy the name of this function, and I'm going to go to the main.rs file. This is the file that actually implements our whole run time. As I told you earlier, this whole file is just 140-something lines. So, if we scroll to the top, we can see that we got an async function that is op write file, then we got op fetch, op remove file, and op read file. These are the four functions that were also defined in our JavaScript run time code, so you've got read file here, write file here, remove file, and fetch. Let's just use one of them as an example to provide our offset timeout. I'm going to start with defining the op attribute. The op attribute is coming from Deno, so this is something we provided for you. Our offset timeouts will return our result. This will be just identity, and then we will return any error, but we don't really need this error here, but let's just keep it. So, the return value will be okay, and now let's actually do the fun part. We need to somehow sleep for given delay, which I haven't passed here yet, so we've got delay, which will be U64, and now I'm going to leverage the fantastic ecosystem of fast grades to actually asynchronously wait for the given delay. So I'm going to use Tokyo for that, which we already use in another API, so I'm going to use Tokyo, time, sleep, and now I need to pass a duration. Duration comes from STD time duration, and now I need to create it from milliseconds. Sure. Whoops, seems like my IntelliSense is acting up. So, we're going to sleep for a duration taken from the delay variable defined in milliseconds, and then we're just going to await it. So, will this actually be enough? Oh, sure, we don't need to use a question mark here. So, we defined this in JavaScript, we defined this in Rust. Will it work now? Let's try. Oh, no, it's still not working. Well, even though we created this function, we haven't really told our Deno crates to use it, so we need to register it here with our extension, and I'm just going to say opposite timeout and run it again. There we go. We just waited for a second, and we printed something out to console. That's pretty awesome for what do we have here? One, two, three, four, five, six lines of Rust code, and then we got another three lines of JavaScript. So, yes, here we got setTimeout, a very basic implementation of setTimeout working. So, let's jump right back into the presentation. Yes, so we created a minimal setTimeout. I think this knowledge, even though it's very minimal and only took us a few minutes, should be enough for you to be able to keep adding more APIs that you might need. So, maybe you would like to create a plugin system for your game server in JavaScript. You can use Deno's crates like we saw in this run JS example, and add some more ops to provide the plugin system. The thing is that Deno, even though it's a JavaScript and TypeScript runtime, we also give you a lot of infrastructure if you want to drop to a lower level and do something that is really tailored for your needs. So, you can use the same infrastructure we use to implement web APIs or file system or networking, but you can pick just some of them that fit your needs. And, to be honest, the possibilities of what you create with this infrastructure and writing out more on your own is just endless. You're limited by your own imagination here. We're going to keep doing these blog posts and recordings for how you can roll your own JavaScript runtime with more and more features in the future, so please stay tuned for the next part. And that's it from me. I'm sorry that it was so short and I had to speed-run through it, but I hope you found it interesting. All of the source code, all the nine lines that we did here will be available at this repository, so please drop by and visit it. And, again, if you have any questions, I'll be more than happy to answer them. Shoot me an email or send me a DM over Twitter, and make sure to visit our website. Thank you for having me here, and I hope you enjoyed this talk. Till the next time!


Node Congress 2022

Can Deno run apps and libraries authored for Node.js? What are the tradeoffs? How does it work? What’s next?