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.
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 https://deno.land/x/install/install.sh | 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 "https://deno.land/std/log/mod.ts";
- 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.
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.