Is Deno replacement of NodeJs ?

A humble beginning of something extraordinary.

So, another day and another Javascript framework ? No, not at all.
Introducing Deno .

Deno is a `A secure runtime for JavaScript and TypeScript.` by Ryan Dahl.

Ryan Dahl was also the creator of NodeJs. Incase you are wondering, here is a video of him retrospecting NodeJS and the ten things that he regrets.

https://www.youtube.com/watch?v=M3BM9TB-8yA

It is a very nice video that gives an insight about the thought process that went into building one of the most popular runtimes, NodeJS and the how things shaped up as the community grew.

So, Deno essentially is a result of that retrospection. As a matter of fact Deno is an anagram of Node .

As of today, Deno is at 1.0.0 🎊.

But don’t get too excited, it is still in it’s early stages and is only suited for enthusiasts. I would not go ahead and build a production system just yet.

A hint in the tagline.

There are some key differences between the run and the most important one is hinted in the tagline.

NodeJS calls itself a JavaScript runtime built on Chrome’s V8 JavaScript engine but Deno is a secure runtime for JavaScript and TypeScript.

So, Deno out of the box supports Javascript and Typescript. We can now finally write statically typed code without the need of additional compilers.
As rightly said by Ryan Dahl, there is a time and place for dynamic languages and if we are writing a server application and want complete control of everything that is happening in our code, statically typed code is our best friend. This is one of the main reasons why many companies still prefer .NET core or Spring applications.

Statically typed languages are peaceful.

Permissions are important.

When we are writing code in NodeJs and installing packages from npm we are giving all the permissions to the the script to do whatever it intends to do.
As developer we are at the mercy of the package owner to make sure that nothing malicious is present in the package or worse the owner isn’t putting any malicious code in the package.

Trust me it has happened.

So, what does that mean for Deno .

Let’s take an example to understand that.
In NodeJs if we want to start a server at 8080 , we would probably do something like this :

var http = require('http');
http.createServer(function (req, res) {
  res.write('Hello World!'); // respond with Hello, world!
  res.end(); //end the response
}).listen(8080); // runs on 8080

Or using external libraries like this:

const express = require('express')
const app = express()
const port = 3000
app.get('/', (req, res) => res.send('Hello World!'))
app.listen(port, () => console.log(`App running on ${port}`))

There is nothing fancy in the code and neither is it wrong. The things is when we do node index.js the application starts and so does all the packages. Global packages such as linters start without us explicitly giving it any permissions.
This is also something that is hinted in the tagline.
Deno equivalent code would be something like this:

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
const s = serve({ port: 8000 });
console.log("App running on 8080");
for await (const req of s) {
   req.respond({ body: "Hello World\n" });
}

The same code in IDE

Now, there are couple of things that are happening.
— Deno embraces Promises and await at the top level without the need of async.
— The for loop is running on an infinite array of incoming events.
— IDE complains about the await but deno compiles it perfectly.
— The import is different, we will get to it next.

The fun begins when we try to run it. After an initial download of packages, this happens:

Does not run without the permission

So, Deno just does not go ahead with running the code block, rather demands an explicit permission so that the developer is always in control of what is happening in the code.
Once we do this the app run without any issues.

deno run --allow-net deno-test.ts

Heaviest objects in the universe

Few of the heaviest objects in the universe.

You must have seen this picture. This depicts the issue very accurately.
node_modules grows exponentially with every package we add. Also EACH project houses node_modules separately. Somewhat like this:

.
├── app_one
│   ├── index.js
│   ├── node_modules
│   └── package.json
├── app_three
│   ├── index.js
│   ├── node_modules
│   └── package.json
└── app_two
    ├── index.js
    ├── node_modules
    └── package.json

The same packages exist in the node_modules and are replicated thrice, taking up a lot of disk space.
Those of you who are familiar with the jvm world, would know that maven , for example, uses local.repository way of maintaining the dependencies in the system. NOT in the project.
Deno aims at doing the same thing. Deno uses a built-in cache system so we don’t need to download a bunch of things, (that we already downloaded for our other projects).

Package management, what ?

Now, this is something that is drastic.
If you look at how serve is imported in the project:

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

Yep, it is a url import. Directly point to the hosted file. Personally I think sooner or later a package manager will pop up for Deno as well. It is much easier to manage packages at one central place rather than importing urls into files.

But, why was this done?

Think about Javascript in web.

<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.5.0/js/bootstrap.min.js">
</script>

If you look at we have been providing direct urls to hosted files since ages and it worked out fine in the web . The above script tag will not raise any eyebrows, whatsoever.
And we definitely did not use any package_manager to get that script tag. Deno aims at doing the same. Remove the need of any package_manager as we can directly point to the resource.
In Deno’s case we will have to wait and see how that plays out.

Is Deno the way forward?

There are lot of features being added in Deno, mostly as a result of the retrospection of “How NodeJs should have been ?”. As of today, it is in active development but definitely not to be used for building production systems. It is good for prototyping and building small pet projects.

But one thing is for sure that we will definitely see the rise of Deno's popularity very soon.
And do not worry, NodeJs isn’t going anywhere.

Give it a try, you will definitely enjoy it.