The story ages to the time of dinosaurs. The gigantic reptiles that flourish on Earth millions of years ago. After completing their time, they extinct. As Justin Timberlake said, “what goes around, Comes back around”. The same happens to dinosaurs, in this digital age they return with a slang name DENO. Again a bad analogy to start with, please pardon me with this.


So according to,,  Deno is a simple, modern, and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust, and Tokio. Sounding like Node it is made by the developer, Ryan Dahl, of its anagram. As a first time user for deno, it felt like a node in a new package there is a substantial difference between the two on which we will be coming in the latter part. 

Deno aims to be a productive and secure scripting environment for the modern programmer.  Deno is a great replacement for utility scripts that may have been historically written with bash or python. Let’s check out some features of deno.


  • The major update in Deno.js is that it is inherently secure. No network or filesystem access by default unless explicitly declared in run command deno run --allow-write file.ts
  • Simple installation only a single command needed to curl -fsSL | sh .and set the path in .bashrc
  • It has a single executable (deno) that runs the complete project.
  • The uncentralized dependency store. The first time we run the program dependencies are downloaded to the deno caches until the reload command is added to the deno run command.
  • Dependencies are directly downloaded using URLs, therefore, no need to maintain package.json and node modules as in node. This helps us in focussing on business logic rather than package imports.e.g., import * as log from "";
  • Support for both javascript and typescript. Deno compiles both without the need for any external library.
  • Inherently browser compatible. Deno does not use Webpack or Babel which transpiles the typescript then makes it usable for browser.

Comparison With Node

As Deno is designed by Ryan, a node company developer, Therefore it becomes intuitive to compare it with node. Here are a few points that  I felt while working with deno after coding in node:

  • No npm in Deno
  • Means no package.json. direct access to libraries and dependencies using URL.
  • Explicitly need to provide permissions for file read, write, or network or environment access. Node does not require explicit declaration
  • Deno needs to handle all exceptions as Deno dies with an uncaught exception while node just eats up the exception and proceed to serve another request 
  • Async actions in Deno inherently return a promise, therefore request structure becomes different from other js frameworks. 

Challenges Ahead

Though Deno is designed to overcome the architectural flaws of node js. It still has a long path to complete before being adopted. Some of them I found while code is:

  • No package JSON means dependencies are resolved by the program itself which re imports the same package again. Though we can create an import map to manage this.
  • Package versioning is another roadblock that I faced while creating a basic project. Though we can set the version number in the URL
  • Large ecosystem of Node js and support for enterprise applications make it difficult for developers to switch to Deno.


Deno is a very promising server-side Javascript language. While comparing with Node Deno should always be taken as an option/alternative and not as a replacement of Node. Refer to this article, Deno JS – CRUD and MySQL Connection, to get started with CRUD and MySQL connection using Deno.

Source link

Write A Comment