1.2 History of Deno

We'll start with the motivation behind creating a new server-side runtime.
Node.js is in the market for more than 11 years. It is a well established, battle-tested, and hardened runtime. It got immensely popular over the years. It is used by some of the major companies like PayPal, Netflix, Trello, NASA, Twitter, Walmart, etc. Node.js helps them to run ultra-fast webapps.
If everything is good then why create a new runtime? Let's find out.

Who's behind Deno?

The Deno project is spearheaded by Ryan Dahl. Ryan is the original creator of Node.js too. After the initial release of Node.js, he moved on to head the Node.js project for the initial 3-4 years. Later on, the Node.js project got moved under NPM (Node Package Manager). Then Ryan moved on to other things. He also spent some time at Google.
In 2018, Ryan made a comeback when he gave a famous talk about his regrets on Node.js. In that talk, he went over all the things he still regretted about Node.js. He ended up the talk announcing a new runtime called Deno. The primary motivation behind Deno was to do something about the regrets. This motivated him to create a new runtime from scratch. The ultimate goal was to create a new secure runtime that is modern and address the mistakes that he did with Node.js.
Let's go over the regrets briefly.


In 2018, at the JSConf, Ryan gave a talk on what he regrets in Node.js. The talk was very popular. It's available on Youtube https://www.youtube.com/watch?v=M3BM9TB-8yA. The video is worth watching for anyone who is interested in finding the motivation behind writing a new runtime.
Let's go over some of the top regrets to understand why Deno was conceived.


Not sticking with promises
After the initial release of Node.js, Ryan had added promises in June 2009. Promises were there in the core Node.js only for some time and got removed in February 2010. At that time, the usage of promises for async/await was very new. Core Node.js code was and is still heavy on callbacks. Promises are a must to support modern code using async/await. This led to a large amount of callback-based code in Node.js. The callbacks based code is still there and it works perfectly. At this point, there is a very less chance that the callback-based code would ever get replaced by Promises or async/await.

Open access

Both Node.js and Deno uses Google's V8 JS engine to run the Javascript programs. While V8 runs in a very good sandboxed environment, Node.js is completely open. A Node.js program can access everything any user-level process can access. In other words, Node.js isn't sandboxed.

NPM or package.json

The idea behind package.json came from Node's popular package manager, NPM. In the initial days, Ryan approved the use of package.json by allowing Node.js's require() function implementation to check into the package.json file for module resolution. Later on, NPM turned into the standard and very popular repository for all the node modules. NPM is very big and perhaps the biggest package manager across all the languages. Unfortunately, NPM is privately controlled. NPM started as an independent company but recently got acquired by GitHub, which in turn got acquired by Microsoft. Node.js and NPM have become inseparable. Ryan regretted that packages for Node.js couldn't come from any repository.


Node.js's module resolution algorithm soon became very complicated. Vendored-by-default had good intentions, but $NODE_PATH would work. Also, it deviated completely from browser semantics. Ryan wanted module resolution to follow the standards, but that didn't happen in Node.js. Node.js module resolution logic is very specific to Node.js.

Conception of Deno

The regrets listed in the previous section are the major regrets. There are some more which can be found in Ryan's talk at JSConf 2018 (https://www.youtube.com/watch?v=M3BM9TB-8yA).
Ryan regretted some of the decisions he had made in the initial critical years of Node.js development. Major of his regrets are coming from allowing a private company NPM to control the third-party modules and eventually the Node.js itself.
These regrets led him to envision a new runtime that attempts to do it right in the first place. A runtime that's built on modern technologies. A runtime that's truly open. A runtime that is not controlled by anyone.