What? Ryan Dahl did it again? He created a new language, which claims to overcome the inherent problems and security issues of Node.js. With these announcements alone, it’s worth taking a closer look at Deno.js.
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
It is definitely a fancy new open source project and one to keep an eye on!
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
Tobias is lead web developer at karriere.at and programmer with heart and soul, he loves to bury himself in complex problems and to master them with creative solutions. Frontend, Backend doesn’t matter, he enjoys every task. If there is no improvement for a web application on the agenda, he likes to learn more about artificial intelligence and machine learning.
karriere.at is not only the country’s leading career portal, it’s also a great place to work. Day after day a young, dynamic and creative team tries to improve the platform even further. More than 50 people are employed in the product development department. It is really cool for developers to work for karriere.at, because here you are not a small screw in the system, but you can implement your own ideas with your favorite framework. Modern technologies like Laravel, Slim, Vue.js and Kotlin are used for the implementation. Do you prefer another language? Let’s talk about it over a cup of coffee.
If you’re interested in more information now, have a look at our blog, devland.at. There you’ll also learn more about why it’s great to work at karriere.at.