The goal of Deno isn’t to interchange Node.js, however, to supply an alternate. A number of variations are quite controversial and it’s arduous to predict if they will format in a correct way. I like to recommend that every Node.js programmer keep a watch on this project. I’m unsure if this project will be a successful, but it’s an excellent chance to look at how Node.js might have been implemented differently.
What is Deno, and what square measure its main features?
It was engineered with:
- Rust (Deno’s core is concept is written on Rust, were as Node’s in C++)
- Tokio (the event loop concept is written on Rust)
Deno – an example
In my opinion, the most important distinction is however modules are imported. As I discussed, Deno doesn’t use the CommonJS format and doesn’t offer a package manager like npm. All modules are loaded in code directly using an URL.
Here is a Node.js example:
And here is a Deno example:
Leading features and differences to Node.js
Typescript support out of the box
Typescript compiler is accessible with no extra configuration. In the Node.js you need to introduce extra bundles to help it. It implies that typescript is incorporated with Deno. Current (v0.20.0) supported Typescript rendition is 3.6.3
Each program written in Deno is running in sandbox without any access to filesystem and network unless we have the tendency to enable it for that with correct flag.
$deno –allow-read example.ts/etc/passwd
$deno –allow-write example.ts
$deno –allow-net=example.com example.ts
In Node.js we don’t have control like in Deno. Every program will read/write the data onto the filesystem and network and it will cause security breach when we don’t follow what dependency we incorporate to our ASCII text file, particularly if it’s a deep dependency tree. ‘What if you have got thirty NPM packages and each of them has their own dependencies, and even they have their own dependencies? You may check it to your nearest dependencies didn’t change and added malicious code, however do what you have to trust what they did for their dependencies?
In Node.js, you load CommonJS modules utilizing the need to watchword and they all, standard and third-party alike, implicitly come back from npmjs.com. In Deno, you load ES modules utilizing the import keyword and expressly states the computer address(URL). For instance:
import * as log from “https://deno.land/std/log/mod.ts“;
Deno modules can be hosted any server– there is no centralized repository required for third-party modules. Also, modules are constantly stored and aggregated locally, and aren’t refreshed except if you explicitly ask for a refresh. Subsequently, you should be able to run Deno programs that are already part of your PC, as long as all the imports have been settled once, regardless of whether you are on a plane with no availability.
Deno has an incorporated assortment of standard modules that don’t have externals dependencies and are reviewed by the Deno core team; it lives on the deno.land server. The deno_std module assortment is a free port of Go’s standard library.
The future of Deno
Deno is associate of open-source project and is being developed very actively. The project was started by Ryan Dahl. Currently, the project has over a hundred and fifty contributors. Besides the release of the 1.0 version, there is a concept to provide a command-line debugger and intrinsic code linter to boost developer experience. Deno should also serve hypertext transfer protocol(http) a lot more efficiently.
- deno is a compile method to output a standalone executable file
- debugging by using Chrome Devtools just by executing the program with “–debug” flag
- signal handlers(helps us to execute code e.g. before the application is killed)
- auto-generated docs of your project
- fs events(help us to watch file changes)