Let’s start with the basics
In detail Deno is built with:
- The core is written in Rust (Node core is written in C++)
- Tokio is used for the event loop handling, which is also written in Rust
- Deno shares only the V8 engine with Node.js, which is known from the Chromium project
Why should Deno be better than Node.js?
One of Deno’s most important features is the focus on security. What does this mean? Unlike Node, Deno executes the complete code in a sandbox by default, which means that the runtime has no access to the file system, the network, other scripts or the environment variables.
Does this mean I can’t create files or write to files on my system? No, but the system asks us for permission if we want to adapt or create a file. On the first view this could be a little bit bothersome and insistent, but the advantages outweigh the disadvantages. Now we can decide which file or which service has the permission to access the file system or the network.
A short example could look like this: We create a script to write to the file system with a message from the other side. And the environment asks for permission. Of course there is the possibility to set a flag to grant the permission by default or set a flag when we execute the script. But why should we do this?
As mentioned early, Deno doesn’t use npm as package manger. But how can we load modules and where are these modules stored? The answers is pretty simple, Deno is just like a browser and loads the modules via a URL.
What? Why? What the f**k?
The reason is also pretty simple: there are varies problems with npm and to prevent them or to create the same mistakes in a new centralized registry the decision was to load the modules via a URL. So now every developer can decide on his own where and how the code should be hosted. For the first time an application is started, the module is downloaded and Deno chaches the code until we tell the service to reload the module. What is meant by “caches the code”? The cache is stored on our local machine as a real file, and we can handle this copy how we like. We could check it into the version control or host the dependencies self. So if we use an external service for dependencies and the external host goes down, our system is still working because we have our own copy in cache.
No package.json? But how do I know which packages in which version my project uses?
The reason behind dismissing the package.json is as follows: In classical Node projects, there are too many reverences where it is stored and which package should be loaded. To solve this there is no manifest or a lock file, that stores the info. But if you are a fan of an overview of your used packages, you can create a sort of a manifest via an “import map”. This is also a JSON-file which includes every used dependencies and our services can load the dependencies via this map file. In my projects I would choose to create a map file, because I like to see on one page which external modules I use.
Wrapping it up
What do we wish for the future for Deno:
- Top-Level async/await handling
- Serve HTTP more efficiently
- Better tooling (CLI, Bundling, Linter, etc.)
- Easy debugging tools