↓ Skip to main content

Is Deno.js the new champion?

I recently read an article that said Node.js is dead, which I found quite exaggerated (which it really is).

Updated

Is Deno.js the new champion?
On this page

Updated November 2026. This was first published on 22 August 2020. The idea is the same. Any number below is what the original piece said then. It is not a new count.

Key takeaways

  • I recently read an article that said Node.js is dead, which I found quite exaggerated (which it really is).
  • Deno was created to fix the mistakes of Node.
  • Deno sure sounds like a superior runtime and in some ways it really is but Node is not going anywhere anytime soon.

I recently read an article that said Node.js is dead, which I found quite exaggerated (which it really is). Deno was created to fix the mistakes of Node. Deno sure sounds like a superior runtime and in some ways it really is but Node is not going anywhere anytime soon.

Node.js is a Javascript runtime environment created way back in 2009 to run javascript code outside of a web browser. It has been incredibly useful for web developers in the past and it will stand strong in the future too. Let me make it clear that Node.js is not perfect, it still has quite a handful of flaws but it does not mean that it is unusable.

In 2018, Ryan Dahl (The creator of Node.js) expressed his regrets on Node in the ?10 things I regret about Node.js? Deno was born as a result of the flaws that he mentioned in the conference, some of them being security, promises and dependencies. He surprised the developer community with a single executable that can handle both the runtime and the package manager instead of the existing package management system (Yep, I’m talking about npm). This comes as a huge win considering how almost all the major flaws of Node are fixed. It still needs to be transpiled to Javascript but all of it is processed internally.

Almost 2 years after its inception in 2018, Deno v1.0 was released in May 2020 and it was received well by the community. One change I personally loved was the ability to declare dependencies directly in the source code using URLs. There’s no need to install a dependency on the terminal and then require it. This is the difference between how Deno and Node handle dependencies.

DENO.JS** import { serve } from ‘https://deno.land/std/http/server.ts’;.

SECURITY #

Coming back to the importance of the creation of Deno, security was a never a strong point of Node. Ryan pointed out security to be a major regret when he created Node. I wouldn’t blame him since he never thought that Node would blow up into such a huge thing. Node.js has full access to your network and file system. Deno is the complete opposite in terms of security. It runs the code in a sandbox and the runtime does not have access to neither your file system nor your network. It requires explicit permission even to execute a subprocess or to access the environment variables. By default, the code is executed with no permissions.

To run the code with no permissions, #

In case it does not have the permission, the following error is thrown, #

??Deno requests write access to “/Users/user/folder/test.txt”. [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)].

Every time we attempt to write to a file without permission, the above error will be thrown. If there are more than one write requests in the code, we will be prompted twice by the sandbox. to avoid this, we can use the allow always option.

The deny option will throw the PermissionDenied error. If we do not have any error-handling code, the process will be terminated.

This is how we can explicitly grant the permission to allow write access.

Apart from granting write permissions, there are other permissions that can be granted like,.

allow-net –allow-run -allow-env -allow-plugin -allow-all (enables all permissions).

No more looking through NPM for third party packages. Even though npm is quite useful and people are still using it without any issues, the problem lies with the centralized registry mechanism. I’m a sucker for decentralization so this idea was an instant favorite. The package creators needn’t rely on NPM to host their packages and can rather host it themselves. (no need to use gitignore anymore to ignore your node_modules).

If you’re confused about the compatibility of node modules in Deno, yes! it is possible to use the packages in Deno but it is not straightforward. Deno provides a Node Compatibility Layer which allows some NPM packages that don’t use non-polyfilled Node.js APIs. The alternative method is to use https://jspm.io/ which converts NPM modules to ES modules**.** Skypack also consists all the modules in NPM and are converted to work with import.

The best part here is that Deno downloads these imported modules and stores them in the cache. It will not download it again the next time we run the program. If the module was updated, it can be updated using the –reload flag which downloads the module again. This helps when the website that hosts a certain module gets taken down as we have the cache stored in the local disk. This cache is stored in the $DENO_DIR environment variable. We have to set $DENO_DIR in our local repository and and update our version control.

BROWSER COMPATIBILITY #

As of v1.0, Deno is doing great on the browser compatibility side. Since Deno uses ES modules, there is no need to use any build tools to run our application directly on the browser. But still, older browsers can support Deno with the help of tools like Babel transpiles the code to Javascipt ES5. These old browsers might not support all the latest features the language but it still runs.

Deno’s built-in tooling deserves special mention. With the headache that goes on with front-end developers who are tired of excessive tooling, this is a welcome change.

CLOSING THOUGHTS #

It is an ambitious project to overcome the shortcomings of Node. The majority of developers including me using Node aren’t complaining and its not like Node is so bad that it needs an immediate replacement. Deno is just another runtime environment that Ryan wished it was when he first created Node. Nevertheless, it might be an alternative to Node in the future (not a replacement) but as of now it is still in its infancy and there’s a long way to go to reach Node’s popularity level. Deno can be used in small projects for now and some of the new features can prove to be more beneficial to certain Node developers to make the jump. Node has strongly established itself and the ecosystem is strong and massive. As Ryan asserted, “Node is not going anywhere”.

Questions and answers #

What is the main point? #

I recently read an article that said Node.js is dead, which I found quite exaggerated (which it really is).

What else did the original piece say? #

Deno was created to fix the mistakes of Node.

Keep reading #