Deno - why all the buzz?

If you follow the world of Web Development, you might have been recently hearing a lot about Deno - a new JavaScript runtime that might as well be considered a spiritual successor to Node.js. But what does it even mean, do we need “the next Node.js” and what’s all the buzz about?

What’s Deno?

To understand what’s going on, we first need to take a look at what Deno even is. Like I’ve said, it’s a new JavaScript runtime aka an environment where your JS code is meant to be executed. It was originally created by Ryan Dahl - the same nice guy, who previously brought us Node.js - hence all the comparisons.

Ryan announced Deno at his JSConf EU 2018 talk titled “10 Things I Regret About Node.js”. From that piece of information alone, you can see where this is going. Deno is created from the ground-up to be a better implementation of what Node.js currently is.

But what’s so bad about Node.js and how does Deno stack up against it’s more matured cousin?

Node.js comparison

Although Deno and Node.js are similar tools that aim to do similar things, the differences between them span far beyond just reversed names.

Architecture

Let’s start with a little insight into Deno’s internals. Just like Node.js, it’s based on Chromium’s V8 JavaScript engine and uses event-driven, non-blocking architecture. However, the two differ through the primary language they’re written in. Node.js uses mainly C++ with libuv as its asynchronous I/O library, while Deno uses Rust, together with Tokio.

For how these differences translate into real-world performance, we’ll have to wait and see. For now, according to Deno’s benchmark, the difference is indistinguishable or very subtle at best.

ES Modules

As you might know, Node.js’s current module system is the so-called CommonJS (the one with require()), even though the official standard for JS in this regard has been ESM (ECMAScript Modules, the ones with import and export) for quite a while now, dating back to the introduction of ES6 in 2015. Sure, Node.js does support ESM, but this feature is currently (v14.x.x) marked as experimental, forcing the JS community to still use either one or the other (or a bundler that is).

And that’s where Deno comes in, shining with its ESM and ESM-only module support. Finally - the one true module system across the board!

Dependency management

But beyond ESM, Deno brings even more changes to dependency management as we know it from Node.js.

Learning from the experience of a million package-sized NPM registry and black-hole-like node_modules directory, Deno takes an entirely different approach to dependencies. Instead of having an NPM-like registry and package manager, Deno imports and uses dependencies directly from URLs:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}

The downloaded modules are then stored out-of-sight, somewhere on your machine. Yup, that means no node_modules anymore!

But wait! There’s more… or should I say less, as Deno also gets rid of the now made omnipotent package.json file. There’s no full-fledged alternative to it, other than a deps.ts file, that acts more like a re-directing sort-of file for all your external modules:

export { assert } from "https://deno.land/[email protected]/testing/asserts.ts";
export { green, bold } from "https://deno.land/[email protected]/fmt/colors.ts";

As for the NPM registry, because Deno can now load dependencies from URLs, this is not as required as with Node.js. However, Deno does provide its own package hosting if you’re interested in such an option.

TypeScript and other functionalities

Yes, you’ve read that right - TypeScript is right next to JavaScript, the primary language to be used with Deno. The support is built-in and doesn’t require anything like custom registers or complex setup.

But apart from TS support, Deno also has a lot of other useful tools built-in. Most of them come in forms of different commands like fmt, bundle, or doc providing features such as code formatting, bundling and, documentation generation respectively.

API

As for the API, Deno is surely its own thing. Everything is written with TypeScript, and async API is based solely on Promises. The core functionalities are limited to the minimum, while everything else can be found in the Standard Library.

So, on paper, it all looks really good and very promising, but when you realize that all the API changes mean much harder time converting Node.js codebase to Deno, the joy immediately starts to vanish. Sadly, everything new and better must come at a price, right?

Security

Lastly, one of the most important aspects of Deno is security. When compared to Node.js, it sandboxes the executed code, allowing access only to selected parts of the system. This means that access to things like a disk, network, and sub-processes can be limited easily, by passing the proper flags.

Again, why the buzz?

So, I’ve just described to you some of the features of Deno in a very brief way, for you to grasp the idea of what’s it all about. Like I’ve said tons of articles have already been written on this topic, and you can dive deeper if you want (I’ll link some nice ones at the end of this article).

But, let’s come back to the main question of this blog post for a moment - why all the buzz? Well, mainly because Deno v1 is scheduled or has already been released (depending on when you’re reading this) on May 13 2020, exactly 2 years after its first release. Now, everyone is asking if this is going to be the “next big thing” or if it’s going to completely replace Node.js.

Personally, I think that it’s too early to say. The project, even though it’s v1 already, given its size and expectations from the community, has still a long way to become a viable Node.js replacement. Keep in mind that these technologies (even with all the differences), are still meant to do the same thing, and will have to compete with one another. And the fact that Node.js development isn’t stale either (e.g. Promise-based FS API variant or ESM experimental support), means that we’re very likely to live in this double-JS-runtime world for quite a while (like if it was anything new for JS devs 😅). And remember that I’m not even mentioning the huge NPM registry and ecosystem, which, although not perfect by any means, still adds a ton of value to Node.js - an unfair advantage that Deno simply doesn’t currently have.

Bottom line

So, to summarize, no - Node.js isn’t going anywhere, and if you’re starting any serious project that’s meant for production, you’ll most likely be better off sticking with it… at least for now. With that said, nothing and nobody (certainly not I) stops you from playing or even using Deno for serious projects. It certainly looks like the future, but one we’re simply not in yet.

Thanks for reading this piece! If you like what you see, consider following me on Twitter, Facebook, or through my newsletter for more up-to-date content. Thanks for dropping in!

Deno resources:

Sponsored links - check them out for more Web Dev content!

Codenami - Get coding questions and fundamental programming topics at your email.