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/std@0.50.0/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/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/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 here on Dev.to for more up-to-date content. Thanks for dropping in!
Deno resources:
Top comments (16)
The is the most unbiased and well written review of the hype around Deno. Kudos
Thanks! I really think that all the hype is a bit exaggerated. Sure, Deno is really interesting, but to call it Node.js replacement right now is a gross overstatement.
reminds me of wasm and vue hype
Somewhat true. Vue is, after all, just another UI framework (BTW, check mine if you're interested 😅), but WASM, IMHO, is something more. Sure, it's not a JavaScript replacement as some might thought it to be, but it allows developers to bring some really immersive experiences to the Web platform. The hype was, again overexaggerated, but only because WASM serves a very specific and small (even smaller back then) niche of resource-heavy web apps like games or heavy productivity apps, which are rather in the minority on the Web.
I fully agree on that. Tho, what I meant was, when it first came out (around '17 or '18), the hype level was like: it's an absolute necessity to use it for a calculator app, just to show all the 'cool kids' on the block you are familiar with it too, hahah :)
Nice article @areknawo !
I'm wondering why having the downloaded modules stored out-of-sight, somewhere on your machine is better than having the node_modules folder? To me seems like one is visible and the other an invisible black-hole-like :)
The link to Tokio is not working.
Your article sparked my curiosity. My next POC will be built in Deno! I find very funny the why of the name of this new runtime.
Thanks!
Thanks!
I've already fixed the link to Tokio.
As for external modules, Deno has a single directory on your disk to serve as a cache for all the URL-referenced dependencies. In this way, you only download them once per the specified version. This results in a single dependency of the given version being accessible right from the cache across multiple Deno projects. Also, more optimizations can be applied to the cache's structure, while keeping it away from the user.
So, to summarize the advantages of this approach:
node_modulesblack hole ever again ;)Yarn already caches download packages globally. But because of how node works these are duplicated in all of the projects that use them.
True, but this duplication is where the real difference is.
I tried to solve that problem in my projects using docker with a shared mount volume. It worked, but only when the dependencies of the projects where the same, and usually they aren't, then I needed to reinstall all the dependencies when switching from one project to another. No the best developer experience :)
When using Yarn after have downloaded the packages the first time the reinstallation was really fast because of the global cache that Yarn creates as @simonhaisz mentioned.
This world of dependencies management is really big :)
Thanks for the response!
Very nice review, thanks :)
I wonder if it's mandatory to use TypeScript
No. It's highly recommended but not necessary.
One suggestion: the link to the standard library is not correct because it contains third party modules.
This one is the official homepage of the deno standard library: deno.land/std
Fixed! I need to be more cautious with all these links next time. ;)
Can't wait deno available at react native lol.