Is node js Dead - Long Live Deno
Tags: deno, node, javascript, webdev
Published: 2020-05-25 10:19:00

**Node.js** is certainly not dead, but the hype is over. As of 2019, all of Node’s innovations (non-blocking I/O, same language on front-end and backend) are copied and even made better by other languages. It is hard to find any use cases where there are no better alternatives
**Deno** is a new platform for writing applications using JavaScript and TypeScript.

Both platforms share the same philosophy – event-driven architecture and asynchronous non-blocking tools to build web servers and services. The author of Deno is Ryan Dahl, original creator of Node.js. In 2018, he gave the famous talk “10 Things I Regret About Node.js“ and announced his new project – Deno. Deno aims to fix Node.js design mistakes and offers a new modern development environment
#What’s wrong with Node.js?
The most important thing first: Nothing is wrong with Node.js. You can use it and you should not switch to Deno just because it’s there.
![Deno](https://miro.medium.com/max/1160/1*KiEL6bx56Uvg5kXIU_SzMA.png)

Node.js is getting used by thousands of (very large) companies, it has huge ecosystem and a highly active community - Node.js isn’t going anywhere!

You don’t have to take this from me by the way - you can also listen to Ryan.

*"But there are a couple of weaknesses in Node.js which could potentially be improved (side-note: Those weaknesses of course don’t necessarily have to matter to you)."*

- Node.js is focused on JavaScript and doesn’t (natively) use static types
The import syntax is very specific to Node.js and not what we know from the browser (ES modules, URL imports)
- Node.js does not embrace modern JavaScript features like Promises
- Node.js is not “secure by default”
The last point is a tricky one though. “not secury by default” sounds horrible and it’s easy to get this point wrong.

**Node.js absolutely allows you to build secure applications. Period!**

**BUT:** A Node script doesn’t have a built-in security model. To be precise, by default, every Node script has full access to your file system, your network and your entire environment.

This is by design and makes Node.js very flexible. But it also means that tools like ESLint, which are just “big Node.js scripts” under the hood, theoretically could do anything with your files on your system.

# How does Deno fix those problems?
Deno generally can be used for the same things as Node.js. You can use it to build web servers, you can use it to build utility scripts etc.

But Deno:

- By default supports TypeScript - hence it’s a JavaScript and TypeScript runtime
- Uses ES modules (with URL support) imports instead of its own module system
- Embraces modern JavaScript features like Promises or async iterables
- Is “secure by default”

Let’s take a closer look at those points then.

# TypeScript Support
You can absolutely write normal JavaScript code with Deno - but if you want, you can also switch to TypeScript at any point as the TypeScript compiler is built right into Deno.

For example, this code would fail when executed with Node.js but works with Deno:
![Deno code](https://i.ibb.co/McXhN8k/deno-1.png)

The usage of TypeScript of course gives you extra type safety and might help you avoid a lot of unnecessary bugs.

As mentioned, it’s optional but if you want to use it, you don’t have to set up your own custom TypeScript project and compilation flow first.

# ES Modules Imports
Node.js brings its own modules system:
![Node](https://i.ibb.co/YT5SmcN/1.png)

We got used to it but it’s very different from what we know in the browser:
![Node](https://i.ibb.co/GsZSZJz/2.png)

or - directly in HTML of course:
![Node](https://i.ibb.co/f8SHkwD/3.png)

In the browser, we use relative or absolute URLs. We don’t sometimes use module names and sometimes file paths (both is done in Node).

In addition, in Node projects, we use npm to manage our local packages. This tool downloads them and stores them (as well as their dependencies) in the node_modules folder.

This folder can easily become very big and it’s actually an important part of Node’s module resolution system. Indeed, the following code relies on express existing as a package in node_modules - it would fail if it would be a simple express.js file or anything like that.
![Node](https://i.ibb.co/VBk5Jw6/4.png)

Deno simplifies this. You simply work with ES Module imports (i.e. the syntax you know from browser-side JavaScript) and it doesn’t need a package managing tool or folder like npm/node_modules.

Instead, your Deno code looks like this:
![Deno](https://i.ibb.co/Pc7Z10w/5.png)

This imports the serve function from the server.ts package which is stored on some web server.

Deno automatically downloads and caches this package (and its dependencies) when your code runs for the first time.

# Modern JavaScript Features
Node.js works a lot with callback functions - simply because at the point of time it was created, modern JS functionalities like Promises weren’t as important and big (and common) as they are today.

Deno, being very new, of course is able to work around that and leverage all those modern features.

Hence you can for example spin up a very simple web server with the following code snippet that leverages “async iterables” [What is that](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of)
![Deno](https://i.ibb.co/Zd03D0Z/6.png)

Just as a comparison, here’s pretty much the same server, built with Node.js:
![Node](https://i.ibb.co/n8bSnR6/7.png)

# Security
As mentioned, Deno has “security built in”.

And this does not mean that your Deno applications are always secure, no matter what you do!

This just means that Deno scripts can’t do everything on your computer by default.

For example, if you run the above server script, you’ll get an error message:
![cmd](https://i.ibb.co/Y2Bfywj/8.png)
![Error](https://academind.com/static/035caa97d731ece48ee465ea394e060d/4b190/deno-error.jpg)
The script only executes successfuly once you use the right permissions:
![Script](https://i.ibb.co/Z2Xt2MM/9.png)

In this case, --allow-net provides network access to the script. Similar permission flags exist for writing (--allow-write) and reading (--allow-read) files for example.

# So … should you switch?
This doesn’t sound too bad, does it?

But it’s also very possible, that you have a look at this list of new features and you think: “This is nice but I don’t hate those things about Node.js”.

And that would be understandable, too.

Either way: Deno is extremely new. Version 1.0 was released on May 13th 2020. And just because it’s v1.0 does not mean that it’s finished and you should use it for your production apps.

It’s still very new and under active development. And it’s also way too early to tell whether it’ll ever be a “big thing”.

You can of course play around with it, dive into it and its ecosystem of packages and use it in your side projects or in demos and smaller apps.

The goal of Deno is not to replace Node.js, but to offer an alternative. Some of the differences are quite controversial and it’s hard to predict if they will format in a correct way. I recommend that all Node.js programmers keep an eye on this project. I’m not sure if this project will be a success, but it’s a great opportunity to observe how Node.js could have been implemented differently.

But only time will tell if it’ll be adopted by bigger companies and projects and if the problems, which it fixes, are really problems with Node.js for the majority of other developers as well.

What are your Thoughts About Deno