In 2018, Ryan Dahl gave a talk titled "10 things I regret about Node.JS" - and at the end he introduced a new runtime called Deno. Before we get into Deno, let's talk about why Ryan might have wanted a new runtime in the first place.

What Node lacked

In the talk, Ryan went over a few regrets he had with the Node ecosystem, and I love how he addressed all of it because with time, technologies change - And in the case of Node, the ecosystem around it had changed drastically. Deno solves a few important issues that Node has, and this is how.

Node has access to essential System Calls

Node Programs can write to Filesystems and related networks because in the original Node, which was built in C++ by building a wrapper (of sorts) around V8 engine, had skipped some important security functions. This, I imagine is because V8 is a secure, solid sandbox, but it is to be used inside of Chrome (or whatever other browsers implement it), but Node can be used as a CLI tool. Node files could have access to a lot of essential system calls and they could, and have resulted in malicious behavior.

crossenv malware on the npm registry
(https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry)

The devs dropping out Promises

Node was designed before JS introduced the concept of Promises or Async/Await. Node instead found a way around promises with EventEmitters, and a lot of APIs are built around this - Sockets and HTTP for example. Async/Await is amazing when you consider how ergonomically handy it is to use. Emitters caused a lack of well-defined protocols to deal with backpressures in streams. While this was okay for some streams, in other cases it causes a buildup, like when the receiving process is slower than sending - eg TCP, MQTT. File read/write (Write is slower than Read). In modern JavaScript, Promises provide the delegation in the form of abstraction, but Node did not have this for its own APIs - and much newer Async APIs are becoming less compatible over time.

Node Package Manager is clunky

Package.JSON is a handy, nifty little file that helps you install your NPM packages on a new system in a quick function - But package.JSON has its own problems.
Package.JSON aimed to create a local machine of sorts for Node in a folder, but it took a lot of time, was heavy, and usually ran into problems out the box. Package.JSON is also very cluttered with metadata.

Deno does not have a package manager! Deno relies on URLs to host and import packages, which I am assuming will be through a CDN, thus we can take advantage of caching! Some people in the Deno community are also trying to have a Go-like dependency handling: Compiling the program into an executable that you can run without external dependencies - But it's not a thing yet.

The Node Build System hasn't aged well

Node uses GYP Build System, which is very complicated and somewhat broken. You can read a comparison of GYP to CMake Here -
https://gyp.gsrc.io/docs/GypVsCMake.md

cMake is essentially a Unix system tool, and it is not cross-platform: Thus GYP made sense at the time. But even Chromium moved from GYP to GN, another build system which was 20x faster for Chromium's use case. This is one of Dahl's biggest regret. Node is one of the only remaining GYP users.

Out of the box TypeScript Support

TypeScript is amazing - Optionally static typing and Type interfaces are two of the best things about TypeScript. But setting up TS with Node is a pain: You need to install dependencies, you need to configure your tsconfig.json, you have to update package.json - It's all too much. With deno, it's out of the box, no additional tooling required.

Explicit is better than implicit

For example, no .JS tags while importing a module!
It is one of my biggest problems with Node, and Ryan mentioned that as well. It is needlessly less explicit. It is also unnatural: Browsers need you to have.JS extensions. I can understand where this came from, but we can also see how it is broken.

Is Node really dead?

No, I was being sensationalist. Node will be alive for years to come since a lot of websites are securely built in Node, it is awesome and has a strong community around it. Small-time projects might see a shift to Deno - Personally, I have a Supply Chain project where I might use Deno.
It is less clunky, lighter, more intuitive, and explicit. I also love how it uses Rust Crates and is not a monolith. I am not sure if Node was, but I think it was a monolith that directly called C++ APIs.

function hello(place: string): string { return `Hello ${place}`} console.log(hello('world'))

That is a simple 'hello world!' that runs like this

./deno hello.ts

Hello world

And a simple URL import would be

import { factorial } from "https://gist.githubusercontent.com/DanielRamosAcosta/ad514503b1c7cf8290dadb96a5fddee9/raw/4733e267f05d20110ba962c4418bab5e98abfe93/factorial.ts" 
console.log(factorial(10))

This is beautiful, don't you think?

🌺 Hey, I hope you enjoyed reading that article. I am Abhinav, editor @ The Crypto Element. It takes a lot of work to research for and write such an article, and a clap or a follow 👏 from you means the entire world 🌍 to me. It takes less than 10 seconds for you, and it helps me with reach! You can also ask me any questions, or point out anything, or just drop a "Hey" 👇 down there. I 💓making new friends!