Deno vs. Node, Trying out deno for the first time
A secure runtime for javascript and typescript is here. And if you were thinking Node.js was it, here’s a talk by the creator of Node.js, Ryan Dahl himself speaking on the design mistakes in Node.js.
So what is deno 🦕 ?
Deno is a new runtime similar to Node.js that could run javascript and typescript outside the browser, built by the creator of Node.js: Ryan Dahl. Yeah you read it right. Deno comes with a built-in typescript compiler. It is based on the V8 engine and Rust.
Being a Node.js developer for nearly 4 years now ( 2 years professionally) and trying out typescript with Node for the past 12 months, I love the fact that now I get to use typescript in my project without any additional tools. There is nothing more fun than having a little more control over your types in your projects.
We want Deno to be applicable to a wide range of problem domains: from small one-line scripts, to complex server-side business logic. As programs become more complex, having some form of type checking becomes increasingly important.
Back in 2018, when Ryan’s 🦕 was just around a month old, some main goals for deno were, security, simplifying the modules system, typescript compiler built into the executable… Two years later with deno 1.0 out, here are key features of deno that interests me.
Security 🛡
A script runs in a secure sandbox and allow no network, file system write access or environment access by default. Basically it can not perform any potentially malicious actions within the system without prior permission. The user is able to provide permission to scripts using flags like --allow-net and --allow-write.
A single executable; one bundle; 🧳
Deno is shipped as a single executable file. So there is no downloading hundreds of files to setup the development environment. Also the scripts that you write can be bundled into one javascript file.
Simplified module system 🗄
Compared to Node.js, deno does not have a separate program for package management. Rather it has its own package manager shipped in the same executable fetching all the resources for you.
Modules are loaded on to the application using URLs. Thus removing the dependancy on a centralized registry like NPM for Node.js. One the first run the modules are downloaded and cached. Deno will not download them again until specified using the --reload flag.
Leaves us with no package.json file, nor huge collections of node_modules.
Die at errors ⚰️
Deno is made to die on unhandled promises which is not the case when it comes to Node.js.
A hello-world Deno HTTP server does about 25k requests per second with a max latency of 1.3 milliseconds. A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and 300 milliseconds.
The deno standard library has been inspired by the Golang standard library, and also deno was first written in Go (back in 2018) but later in Rust.
Top-level await and browser compatibility are two more features of Deno that caught my attention. Browser-compatibility means where we overlap in functionality with the browser. Deno’s API is built to follow the browser’s API. This means that developers can easily go between the two. It would not be necessary to use build tools like webpack when using ES modules to make it browser compatible.
Will it kill Node.js?
The thing is deno is still the early stages of development. I mean version 1.0 is out but still it needs work to be production ready. In the other hand, Node is out there rocking the stage with a large number of companies running enterprise grade systems on it, not to forget the community support. So, no I do not think deno will kill node, atleast anytime sooner.
For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno.
It is important to understand that deno is a completely new implementation and it does not support existing node modules. You could read more on the issues they are facing with the current implementation on their blog post.
On a final note, I believe deno will get to where Node is today considering the amount of interest as of today. But something I really do not want to see is a bunch of frameworks on top of deno trying to solve or do the same thing, like we see on Node.
I started looking at deno after seeing my fellow collegues Chamod and Isuru trying it out. So shoutout to them. Also I just started playing with deno, so the comments section is open for any critisism, ideas or suggestions. Find my work with deno below, and will be updating in the future as I find time.
If you are interested in trying out deno, check below.
Happy coding :)
