What is Deno? The Modern Node.js Alternative đ[All Method]ī¸
![What is Deno? The Modern Node.js Alternative đ[All Method]ī¸](https://howisguide.com/wp-content/uploads/2022/02/What-is-Deno-The-Modern-Nodejs-Alternative-All-Method.png)
The step-by-step guide on this page will show you What is Deno? The Modern Node.js Alternative. After completing this guide, you will know how to face these kind problem.
Question: What is the best solution for this problem? Answer: This blog code can help you solve errors What is Deno? The Modern Node.js Alternative. Question:”What should you do if you run into code errors?” Answer:”By following this blog, you can find a solution.”
Not many projects have caught my attention like Deno has.
In this article, Iâll do my best to describe simply what Deno is and what sets it apart from Node.js.
Deno? What is Deno?
Deno is a dinosaur. In particular, Deno is this dinosaur.

But wait, thereâs more!
If youâre familiar with Node.js, youâll notice that Deno is essentially Node.js with a few different rules.
Itâs supposedly a step up from Node.js.
That begs the question: what was wrong with Node.js in the first place?
Whatâs wrong with Node.js?
Node.js has been around since 2009 and has blown up to be our main source for JavaScript server-side development.
The person behind Node.js, Ryan Dahl, is also the creator of Deno.
However, as he created Node.js and made the design decisions as to how to structure everything, he realized that Node.js had many shortcomings that include but are not limited to:
- Lack of Promises: async APIs age poorly due to the lack of abstraction for async/await
- Non-Existent Security: an installed package has complete access to your computer and network
- Outdated Build System (GYP): Node is the sole GYP user while the V8 JavaScript Engine and Googleâs Chromium browser have switched to GN
- Cluttered
package.json
: there is no need for this module abstraction or bloated information such as license, repository, description, etc. - Complicated
node_modules
: the module resolution algorithm is over-complicated and deviates greatly from browser semantics - Ambiguous
require()
Statements: these statements are unnecessarily unspecific by leaving out the.js
extension, forcing the module loader to guess what the user intended - Unnecessary
index.js
: this file complicated the module loading system and was especially unnecessary afterpackage.json
came around
These are all issues we could resolve one-by-one, but with Node.js running on millions of computers right now, itâs infeasible to make all these major changes to this JavaScript runtime.
Okay, seriously. What is Deno?
Deno is essentialy Ryan Dahlâs dream of what Node.js shouldâve been.
It is a âsecure runtime for both JavaScript and TypeScriptâ that began in 2018.
It was built with V8, Rust, Tokio, with inspirations from Go and Rust in particular.
Fun Fact: Deno is an anagram for Node. It can also stand for Destroy Node.
Here is a list of new features that Deno offers.
Deno hasâĻ
- More security (no permissions by default)
- Built-in tools (test runner, file watcher, bundler, etc.)
- No package manager (
node_modules
,package.json
,npm
, etc.) - Deep modern JavaScript and TypeScript support (TypeScript is compiled automatically by Deno)
- Browser-compatibility (built-in
fetch
,setInterval
,setTimeout
, globalwindow
object, etc.) - A Promise-based API:
async/await
support (no callback hell) - Remote script execution
- Curated standard modules
- ES module support
- Sub-process execution using web workers
- Native WebAssembly support
While each of these features deserves its own article, the most notable changes to me are these ones below.
No permissions by default
Deno is secure by default.
If I run a Node.js program, it can access anything and everything.
- File system
- Network
- Environment variables
- Script execution
If I run a Deno program, it will have no permissions by default. It canât access any of those systems unless specified by a flag in the CLI.
--allow-all | -A
--allow-env
--allow-hrtime
--allow-read=<whitelist>
--allow-write=<whitelist>
--allow-net=<whitelist>
--allow-plugin
--allow-run
This is especially important because we are constantly running other peopleâs code when we install npm
packages and such. Inside Node.js, theoretically, these packages can do whatever they want on our computer.
For example, suppose we wanted to create a local HTTP server.
// server.ts
import { serve } from "https://deno.land/std/http/server.ts";
const server = serve(":8000");
This script will try to access the network and return an error. To run this script successfully, we can add a flag to our deno
command.
deno --allow-net=:8000 server.ts
We can see here that Deno sandboxes all applications by default, thereby making it more secure than Node.js.
Built-In Functionality
There are many tools built into Deno that make the development process easier.
- Dependency inspector (
deno info
): provides information about cache and source files - Bundler (
deno bundle
): bundle module and dependencies into a single JavaScript file - Installer (
deno install
): install a Deno module globally, the equivalent of npm install - Test runner (
deno test
): run tests using the Deno built-in test framework - Type info (
deno types
): get the Deno TypeScript API reference - Code formatter (
deno fmt
): format source code using Prettier - Linter (
deno lint
): linting support for source code - Debugger (
--debug
): debug support for Chrome Dev tools
This has to be my favorite feature of Deno.
We donât have to worry about setting up testing, linting and bundling frameworks for our applications. There are standard tools now that we know will integrate nicely with one another.
No package manager
As long as the code we want to use is on some server, we can import âpackagesâ or âmodulesâ directly in the import
statement through a URL.
import { serve } from "https://deno.land/std/http/server.ts";
However, whether itâs a URL or a local file, you now need to include the file extension.
In Node.js, we could run either statement below.
import { serve } from "./server";
import { serve } from "./server/index";
In both of these scenarios, Node.js unnecessarily infers what the user wants.
In Deno, thereâs no guessing since the file extension is required.
Conclusion
This guide is by no means comprehensive, but is rather a quick overview of the history and purpose of Deno with respect to Node.js.
Iâm excited to see the direction Deno takes in the coming years. With such a large Node.js ecosystem right now, it may take a while for Deno to plant itself as a competitor in this space.
Iâll be sure to do more research on Deno and stay up-to-date on its activities, and I encourage you all to do the same!
Revise the code and make it more robust with proper test case and check an error there before implementing into a production environment.
Final Note: Try to Avoid this type of mistake(error) in future!