Deno’s popularity is steadily growing, it has half the number of stars of Node.js on Github already. When stable version will be released we can expect adoption rate to increase which should lead to more contributions to the project and hence faster growth. The goals are noble and we can only hope that we get a real alternative to Node in the upcoming future.
What is Deno?
Deno is a JavaScript runtime much like Node.js, but that aims to be secure. Made by Node’s original author – Ryan Dahl, who gives to Node.js developers surreptitious wink by naming his new project by anagram, wants to fix the design mistakes of Node. Deno’s stack includes V8 engine (same as in Node), Rust which makes it more secure and Tokio (Rust lib) that gives it asynchronicity. The development of Deno is going fast, expect v1 soon. Let’s take a look at this a little bit closer.
Leading features and differences to Node.js
Typescript support out of the box
Typescript compiler is available without any additional configuration. In the Node.js you have to install additional packages to support it. It means that typescript is built into Deno. Current (v0.20.0) supported Typescript version is 3.6.3
Secure runtime
Each program written in Deno is running in sandbox without access to filesystem and network unless we allow it for that with proper flag.
E.g.
$ deno --allow-read example.ts /etc/passwd
$ deno --allow-write example.ts
$ deno --allow-net=example.com example.ts
In Node.js we aren’t in control like in Deno. Each program can read/write something on the filesystem and network and it can cause security breach when we do not follow what dependency we incorporate to our source code, especially if it’s a deep dependency tree. What if you have 30 NPM packages and each of them has their own dependencies, and they also have their own dependencies? You could check if your closest dependencies didn’t change and added malicious code, but should you trust they did the same for their dependencies?
When was this a problem in Node?
- The event-stream incident
- How Two Malicious NPM Packages Targeted & Sabotaged Others
- Yet another malicious package found in NPM, targeting cryptocurrency wallets
- Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Wallets
Module System
Deno loads modules by URLs. You can be confused when you will see the code below, but I can calm you down because it makes sense.
import { TestModule } from "https://example.com/package/test.ts"
As you can see, there is no package.json, no node_modules. They can be directly imported by using a relative, absolute path or a fully qualified URL of a source file.
That’s a big advantage for package creators, who want to host their packages wherever they want and will be independent of only one source (NPM registry). Somebody can say that when the host will be down or the source of import will be deleted, we will be trapped. I agree, but only in half. Firstly, Deno caches all downloaded imports and until you reload cache by --reload flag it will take them from the cache. Secondly, it’s your choice from what source you want to import it. For someone who wants to share packages on his own (e.g. in private network), that Module System is a big advantage.
Worth to mention is also that you don’t need to always type full URL. Deno allows to create import map, which can look like this:
{
"imports": {
"example": "https://example.com/package/"
}
}
and then import that in code like that:
import { TestModule } from "example/test.ts";
but to keep it work, we have to run the program with a proper flag, look:
deno run --importmap=import_map.json example.ts
To not worry about package versioning you can implement whatever you want. Only the limit is your imagination. You can take inspiration from the author: github.com/denoland/registry
Road map to v1.0
The date of release isn’t known yet, but you can follow it by looking into todo list in on one of the GitHub issue. You will find there some really interesting features, like:
- debugging by using Chrome Devtools just by executing the program with
--debugflag - deno compile method to output a standalone executable file
- signal handlers (helps us to execute code e.g. before the application is killed)
- fs events (help us to watch file changes)
- auto-generated docs of your project
FAQ:
- Is Deno a drop-in replacement for Node, or requires adapting codebase?
Compatibility with Node is not its goal, you will have to adapt your codebase.
- Is Deno stable/production-ready?
No, Deno is still in v0, but development is going fast.
- How is Deno’s performance?
Deno has much faster startup times than Node – 89ms vs 680ms for a hello world script.
No substantial performance difference in other regards.