An Introduction to Deno for Node.js Developers

Hi, everybody. Thanks for coming to my talk. I'm going to be talking about getting started with deno if you are a node.js developer. So a little bit of personal background on myself. I've been using node for about 10 years and just recently started working at deno. So it's been, you know, a learning experience trying to switch between these two environments. So I was hoping that this talk could help somebody else who was in my shoes with moving over to deno.

A little bit of background on both run times. They're both JavaScript run times. They're both built on the V8 engine. Node.js has been around significantly longer since around 2009, and then deno came out around 10 years after that. The interesting thing about node.js is that it predates a lot of what we consider to be modern JavaScript. So for example, it still supports CommonJS, even though it has ES modules. It still has its legacy callback APIs, even though it now has support for a lot of promise-based APIs. Node has also historically, although it has changed a lot in recent years, taken a kind of defer everything to user land approach. So the idea was that core would be very minimal, and that user land would implement NPM modules for a lot of other functionality. I would say that Dno has taken a different approach, where it's much more batteries included. It has an integrated tool chain and a number of other things, which I'll talk about later in these slides. Another thing is that Node.js has a huge ecosystem with a lot of legacy code. This can be good and bad, so having a huge ecosystem is nice. But having to support so much legacy code can actually slow down a lot of progress and actually kind of hinder Node's ability to have standards compliance, which is something else I'll get into later in the slides.

So the timeline for Dno is roughly shown here. So in June of 2018, Dno was first introduced at JS Conf EU. Later that year in August, Dno 0.1.0 was released, and it was rewritten in Rust. So initially, the native parts of Dno were written in Golang. And they were kind of moved over to Rust because there was kind of concern about having multiple with garbage collectors running in the same process.

So then in May of 2020, Dno 1.0.0 was was finally released. So then in March of 2021, the Dno company was announced. So this is nice, because having a company backing a project can can really help because you can lay out a roadmap. You can allocate workers to work on specific things, and just generally have better control of how the project is going to be developed. On the other hand, Node.js is run by almost all volunteers. So you know, we can't really, on the Node side, control who's going to work on what. We can't tell volunteers to spend their time on certain features. And we've even had initiatives like Node's Benchmarking Working Group, which is doing a lot of useful work, have to be wound down because there just was nobody that was working on them at the time. So having a company backing the project is huge, in my opinion.

So then in June of 2021, DenoDeploy was announced. So DenoDeploy is a very similar runtime to the open source Deno project, except it's meant to be deployed in the cloud. It's more or less a globally distributed JavaScript VM that lets you run JavaScript programs at the edge all over the world. So there's currently 32 different edge locations that are supported and we're constantly adding more. It's nice because you can write your code and have it deployed in less than 10 seconds globally. And then in Q3 of this year, we are aiming to get DenoDeploy to general availability. And right now it's still in a public beta.

So I wanted to talk quickly about the growth here. So this graph shows GitHub stars for the Deno CLI as well as Node.js. The graph would only generate back to around 2015, even though Node actually goes back to 2009. So that arrow shown there should actually be wider. GitHub stars are kind of a proxy metric for adoption. Anyone can star a GitHub repository without actually using the project. But we do have some internal metrics that indicate that this growth is real and not just fluff on GitHub. So I think based on the 10-year age difference in the two projects, the difference in stars is really something that is worth kind of noting. Next, I want to talk about the core technologies that are under the two projects.

So as I said earlier, both of these projects are JavaScript runtimes that are built on top of V8, but that is kind of where the architectural similarities stop. So Deno, their native language is written in Rust, whereas Node.js is written in C++, which makes for an easy wrapping around V8 since V8 is also a C++ project. Rust is the new hotness, and it provides things like memory safety and things like that that languages like C++ don't. So it's really nice to be able to work in Rust, but it also dictates what some of the other dependencies are going to look like in the project.

So for example, Node.js uses LibUV for its asynchronous IO and event loop, whereas Deno uses Tokyo. Node.js also uses OpenSSL, whereas Deno uses a project called RustTLS. On the HTTP side, Node.js uses a project called LLHTTP, whereas Deno uses a couple of projects, Typer and Requests, depending on if you're on the client or server side. And then at the DNS level, it's TrustDNS and Deno versus C-ARIES and Node.js.

So looking a little closer at the Deno architecture, you can see here we have the V8 project wrapped in something called Rusty V8. So Rusty V8 are the Rust bindings to V8. This is what kind of isolates the C++ code of V8 from all of the other Rust code that's inside of Deno. Everything outside of V8 is gonna be in Rust. Rusty V8 also allows you to ship precompiled V8s so that you don't have to compile it on your machine from source, which can take a significant amount of time. And then there is something else inside of the Deno core library called DenoOps, which kind of provide an API for interacting with the isolate and the underlying runtime. So all of this is wrapped up in the Deno core crate. All of these crates are available so that you can actually take and mix and match and create your own runtime if you really wanted to. I mentioned Deno deploy earlier. It actually builds off of all the open source crates, but it does so in a way that the runtime is slightly different because when you're running your local CLI versus running something in the cloud, there are going to be different requirements. And so having a modular approach like this allows you to kind of take advantage of code reuse while still having the different runtimes.

So, the core project is kind of a minimal JS runtime, but probably not something that you would want to actually use. The core is then wrapped into another crate called the Deno runtime. So the Deno runtime is a much more complete JavaScript runtime. It's more fun to interact with. It includes the core, it includes the Tokyo for the asynchronous IO. It also includes a number of other crates that implement various APIs. So, some of them are shown here. DenoFetch is used to implement Fetch API, DenoCrypto does crypto stuff, DenoWeb is for a lot of web platform compatibility, and so on and so forth.

And so then, once you have the Deno runtime, it goes one step further and that is to the actual CLI itself. So this is the executable that you're going to download and run. Deno is distributed as a single executable. You can go get the crates from the Rust package manager if you really wanted to, but most people are just going to download and install this executable, and you can always rely on that executable being the preferred way to download and install Deno.

So the CLI includes the runtime, which I talked about in the previous slide, but it also includes an integrated toolchain. So Deno, as I said earlier, is much more batteries included than Node.js, so you're going to get things out of the box like a linter, a formatter, a test runner, a whole bunch of other things which I'll talk about later in the slides. The idea is that the CLI will have everything that you need to develop and run Deno applications. And this runs on Linux, macOS, and Windows, and I have a link here to the getting started docs if you wanted to step through and download and install Deno on your machine.

So Deno also has a standard library. So these are going to be JavaScript and TypeScript modules that are built and maintained by the core team. So they're audited and guaranteed to not be stale, not be malware, be maintained, and just generally audited to make sure that they work well with Deno.

I would say that these are on the Node.js side similar to Node's core modules such as FS, HTTP, et cetera. The only difference is that these live outside of the core repository, so they can be versioned independently, released independently, although currently they are released when the core runtime is released as well.

There's a lot of different modules there, things like FS, HTTP streams, things you'd be used to having in Node, UUIDs, WASI, a whole bunch of other stuff. There's not really a package manager for Deno, but these modules are hosted on the internet, so if you go to this deno.land.std, you'll get the latest version of the standard library, and then you can also version these, which is recommended as shown in the example at the bottom here. So if I wanted to import the copy function from the FS library, this is an example of I would do that while also ensuring that I'm getting version 0.141.0, so if there is a breaking change or anything else as the library evolves, you're guaranteed to get a version that you know works with your code.

And so talking about general dependency management, it works a lot like a browser. So there is no NPM. We only support ESM, there's no support for CommonJS. There are CDNs like ESM.sh where you can upload CommonJS modules and they will be transpiled for you, so that you can import them from there. You're not going to have a package.json file, there's not going to be a node modules, there index.js file. So when you do a require, you have to actually specify the file name and not the kind of magical index behavior.

So if you ever use something like Rust, I feel like Deno is kind of similar in the fact that it, when you run your code, it will actually fetch the code. It'll cache it locally so that you don't have to keep installing it. You can even do some work from an airplane if you need to. And it will compile those things automatically for you. So, you know, especially if you're downloading TypeScript, it has to be transpiled and whatnot. But Deno does all of these things for you kind of behind the scenes. And then for production apps, we recommend that you use a command called deno-vendor, which will basically download all of your dependencies locally. And then you can add them to source control or manage them however you want rather than trying to install things at deploy time in production. And as I said, there's no NPM, but there is package hosting at a site called deno.land slash x. So here I'm still showing the example from the previous slide. But if you replace that std at portion of the URL with x, then you would be kind of using, I guess, the Deno equivalent of NPM. And there's a web interface as well. So you can browse there and see all of the different third-party modules that people have created and uploaded. So there is a release schedule. Patch releases come out every week. Semver minor releases come out monthly.

These releases usually happen on Thursday. There's not a Semver major release cadence yet like Node.js has, and there's also not an LTS schedule yet like Node.js has, but I do think that those things will come in as the project gets more and more mature.

So I wanted to quickly look at a Hello World application. So this is only a few lines of code and you can run a full-fledged HTTP server. So what I'm doing is I'm importing the serve function from Deno's HTTP standard library module, and then creating a handler that the serve function uses every time it receives a request. So you can see here we have the request as an input parameter, it's prefixed with an underscore because we're not actually using it. And then this function will return a response. And then all we're returning is a very basic Hello World, and then we call the serve function. When we call serve, it'll actually print to the console what port it's listening on. I believe that's 8000 by default. And then the command here, denorun, allow net server.ts is all you need to actually run this. And I'll talk about what that allow net is in a second.

So some notable features from Deno, focus on web platform compatibility, integrated tool chain, as I already mentioned, TypeScript support is provided out of the box. There's a permission system and there is an actual compatibility mode for Node.js code, which I'll get into in a few slides here. So as far as web platform compatibility goes, Deno almost always, I would say, prefers web platform APIs when possible over rolling their own. So I have a list of some of the web platform APIs that Deno supports here. There are actually even more than this, but they wouldn't fit nicely on a slide. And then on the right side, here, I have a screenshot of the MDN web compatibility tables. So this one in particular is for set timeout. And you can kind of see on the far right here, the last two columns are Deno and Node.js. You can see Deno has supported this since version 1. Node.js supports set timeout, obviously, but it's not really SPEC compliant. So it returns a timeout object instead of a timeout ID. It doesn't support passing in a code string and just different things like that. So web platform compatibility is one of the primary design tenants of Deno and somewhere it really shines.

Tooling comparisons. So there are a lot of tools built into Deno. You can run deno help to see a list of all of the subcommands. Here I have a comparison of some of the very common ones. So for example, the linter, there's Deno lint as opposed to installing ES lint."

Same with Prettier, NVM, all of these things are just built into Deno. With the exception of the test runner, which Node does have a built in one. But it's only in the latest version of Node. I think Node is starting to come around more to more batteries included. But as of right now, this is kind of what the tooling landscape looks like.

TypeScript, as I mentioned is supported out of the box. The TypeScript compiler is actually snapshotted into the Deno binary. And then SWC, which is the speedy web compiler. It's a JS and TypeScript tool written in Rust. That's supposed to be 20 times faster for single-threaded applications than Babel is. And I think it's like 70 times faster for multi-threaded. But yeah, all of this stuff is built into the executable. We use that to transpile and bundle and everything like that.

You can configure the TypeScript compiler by passing a config file from the CLI. That's typically not needed. So we don't really recommend it. It's just nice to have an out of the box experience that just works. Deno's permission system is by default Deno is kind of locked down. It can't really access any of the outside world. So we have a list of CLI flags here on the right, which you can use to grant permissions. So if you want to access environment variables, HR time. So high resolution time is behind a CLI flag because it can kind of subject you to timing attacks and things like that. Net for the accessing the network, FFI if you want to load dynamic libraries. Read and write or for reading and writing the file system. Run allows you to run child processes. And if you're just testing and you want to grant all of the permissions, then you have the --allow-all, which is aliased as -a. So you have to explicitly grant these permissions as needed. If something is not granted, Deno will actually prompt you for it and ask at runtime if you want to allow it. One thing to note is if you're running sub processes or FFI, these things are not going to be restricted using the same sandboxing.

If something is not granted, Dino will actually prompt you for it and ask at runtime if you want to allow it. One thing to note is if you're running sub processes or FFI, these things are not going to be restricted using the same sandboxing. So do that with caution. And then some of these flags can actually be further configured. So if I want to read from the file system, but I only want to allow access to a specific directory, I can do that. Or if I want to run a sub process, but only allow running a specific sub process, I can do that as well. And these permissions apply to the whole process and not to individual modules.

So node compatibility. I took a snippet from the docs here. Basically shows how you can create your own require function and then use that require function just like you would in Node.js. So there is no require in Dino by default, but you can do this using the dash dash compat flag. You also have to specify dash dash unstable because this is still considered an unstable feature. And if you want to use common JS, which is what require is then you have to actually specify allow read as well.

Then I have a bunch of what I think are important links or things that people can go as references and look at. The first link is to the primary documentation site the second link is for Deno standard library if you want to browse those third party modules the Deno Land slash x that I had mentioned earlier is there. The source code for the standard library and the CLI are included at Deno Land slash Deno STD and Deno Land slash Deno. There is a community discord that's pretty active so I have the link here if you want to join that and then Deno Deploy the product which is also a different runtime and the globally distributed VM all the things I mentioned earlier. Currently in beta there's a link here if you want to try it out. It does have a pretty generous free tier so I would encourage playing around with it I think it's a pretty nice project but yeah that's everything I had so if you have any questions feel free to reach out to me on Twitter, GitHub or whatever.