Like the COVID-19 took the world by storm, the same did the “Deno” but with the Developers’ community. I guess you are here after a long debate with your cool developer buddy over NodeJS vs DenoJS and want to come at a conclusion that if “God Forbid! Is NodeJS dead?“

Well, folks, you have come to the right place. The most astonishing fact is that Deno is developed by the same developer (Ryan Dahl) that developed Node about 11 years ago in 2009. Deno was released about 2 years ago in May 2018.

The History and the Biology

Node JS and Deno JS are both Javascript runtime environments and both use the chrome’s V8 engine but Deno has Rust built-in. Node was created at the time when most of today’s modern javascript syntax was not supported. So Node can only run JavaScript but no typescript.

There is a workaround for it though using third party packages. We can use TypeScript but we need to compile the .ts files to .js each time we want to execute our code. To simply convert, we can run tsc in the Terminal/Powershell.

This is not simply the case with Deno as it supports TypeScript out of the box. It can run .ts natively. Behind the scenes, it automatically compiles .ts to .js and caches it.

The major difference we can spot out right away between both is hidden in their respective tagline. NodeJS says “Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine.” Whereas DenoJS says “A secure runtime for JavaScript and TypeScript.” Yes! that secure word is the elephant in the room.

But does that mean Node is insecure? We will discuss that in a minute.

So the question is why Deno?

We have NodeJS and it has matured and aged well over time. It has proven its worth in its long history of 12 years, be it the stability, scalability, simplicity or community support. Then if the Node is so good then why did Ryan create Deno?

The most obvious reason is to avoid some of the shortcomings of the Node. Let’s take a somewhat deep look at what Ryan said in the Launch of Deno.

Well, the most important thing he said in the disclaimer of his JS Conference was,

Ignore this talk – use Node. Node isn’t going anywhere!

And yes he is right, Node isn’t going anywhere. But from Deno’s tagline, it says that it is a secure runtime.

Let us take an example. In a node app let us assume that we parse the incoming requests and write it into a file. NodeJS provides ‘filesystem’ as one of its core modules. Also, any file/module in a Node application has full authority and access. It can create, read, update, delete, has network access.

The point here being is that when installing a third-party module or we write our own code, we really have to trust the code that it is not something fishy. So in terms of security, we are in uncharted territory.

Though in the case of Deno, we write code in Typescript which eventually leads to a cleaner and bug-free code. Also, any file which requires special access like performing CRUD operations or network access, we need to provide manual permission while running the app.

A typical permission in Deno looks like this.

deno run --allow-write=message.txt app.ts

Also, Deno supports Http imports which looks like this.

import { emptyDir, emptyDirSync } from "https://deno.land/std/fs/mod.ts";

Compared with Node where its typical import looks like this.

const fileSystem = require('filesystem');

The point that sets both apart in NodeJS vs DenoJS is that in case of Node we have to install any package prior to using it in our node application with npm install --save <package-name>.

This is not the case with Deno as we directly import the module and during compilation, the required module packages and dependencies are downloaded on the fly and cached on the local system to be used later.

So, there is no need to install any package locally on the development machine in the case of Deno but vice-versa in the case of Node.

Also, there is no package.json file in Deno because it does not have a centralised location for managing packages and modules.

Is Deno really secure?

Let’s take an example where we require an app that for certain functionalities heavily depends on third party packages.

In case we build this app with NodeJS, the typical workflow would be that we install all the packages that we require and build the app accordingly.

But in the case of DenoJS, the workflow would be like we use Http imports for any standard library or third-party modules and will write the app with no prior installation on our local machine.

Deno will pick all the required packages on the fly during compilation and will manage all the heavy lifting for us behind the scenes.

Also, during running/compiling the Deno app we have to provide all the permissions manually that are required by any third party packages or the code that we write.

In case of our code that requires permissions, we can make sure that we write bug-free code. But in the case of third party modules, we cannot say that the package won’t abuse the permissions.

So if we use third party packages that are not directly maintained by Deno Team we are again in the Node territory in case of security.

What I want to say here is that security is not a thing if we use third party modules in Deno.

Advantages of Deno

The major advantage of Deno is that it uses Typescript and supports it natively. No pre-configuration is required as Deno supports it out of the box. Using typescript instead of javascript greatly improves the development experience. Writing bug-free code has never been easier.

The next thing Deno does best is Package Management. There is no need to preinstall any packages on the development machine locally. Deno adds them on the fly during compilation, hence no package.json file and no node_modules folder. Thus better overall development experience.

Also it manages security better because **by default all the permissions are blocked**. We have to enable them manually during compilation. This will be secure only if we trust the code provided by the third-party/ community and we are sure that the code doesn’t abuse the permissions.

Final Verdict on NodeJS vs DenoJS

As of today when I am writing this post in July 2020, Deno is still in its early stages. Version 1.0 has just been released a few weeks ago as of now. **Many of its features are still experimental**.

Deno has many cool features but as of now, NodeJS can do everything that DenoJS can. Surely, Deno will be much better in the upcoming future. But that future is nowhere near and Node is here to stay.

NodeJS is long-established and has matured well. It has awesome community support. Many tech giants now use Node and it's harder as well as meaningless to switch to Deno without a feel of absolute requirement. so apparently there are more jobs for Node as compared to Deno.

I tried Deno for a good couple of days. It is good for playing around and experimenting with and using in demo projects. But as of now, I prefer Node and its vast collection of packages for literally anything and everything.

For Enterprise/ production level apps I would not recommend Deno as you would encounter a lot of problems for even basic tasks. For example, we don’t have mongoose library for Deno yet which makes working with MongoDB much easier.

From my experience in both NodeJS vs DenoJS, I think it’s pretty easy to switch between both as the code and execution logic are almost similar. Deno is worth having a look at and for playing around with.

So just play around with Deno, have fun but don’t use it in production-ready apps as of now.

Conclusion

So now you know which one to choose for production and which one to play with. As of now, Node is the champ and also the elephant in the room but one-day maybe one day in the far future Deno may seem like a replacement.

Thanks for bearing with me to this point and I am sure that I made my point really clear to you.

I hope you enjoyed this post on NodeJS vs DenoJS! Which one and Why?

I also recommend you also read my other posts. Thanks for reading, Kudos!!