Let’s Talk about Deno

Three Cognizant Softvisioners test the new JS runtime environment

Agustín Ramos, Dario Renzuli and Victor Hugo Valle Castillo are Software Engineers from the Web Community, at the Buenos Aires studio. Together, they decided to give a try on Deno, the new JS Runtime environment from the creator of Node.js, and share their experience. 

Since the project is in alpha state and looks really promising, we wanted to start playing with it, and testing to see if it lives up to Softvisioners standards. 

Our main goal for demoing Deno was to test its performance, noting all of the pros and cons that come along with it. Our big goal was to test and compare the main functionality with the current Node version, such as dependency management, file read/write, a web server with routing. 

The first thing that stood out to us was that it natively includes TS support, which is something really useful when we are developing backend services/apps. Deno is also based on Rust (https://www.rust-lang.org/) rather than C++, which promises to be faster and handle memory more efficiently. Here are some of our experiments from the test: 

First Experiment: A web server with routing and file read/write

An interesting thing is how to manage dependencies, Deno has already lots of modules to use, like:

The first set of imports are for the server – routing, and the second one is for file management.

For the routing:

We first create our router component/middleware, assign the methods we want. In this simple test we are just using two get methods, one to write, and the other to read.

After that we have to create our app instance, to bind the router, and all the other middlewares we want. We can implement a middleware to manage CORS, etc.

Here, we are using two middlewares created on the fly:

And this way we are implementing the routing middleware:

Second Experiment: Dependency management – Multi versioned module (use case)

As we saw in the example above, Deno has a very interesting way to manage all the dependencies, and we can take advantage of that feature, e.g:

  • Let’s create a script file and let’s call it math.ts for this example.
  • Let’s import some methods in order to perform some math operations within a small app.

As we can see, we are currently using the version 0.0.1 of the math module, and we are accessing its features via its public URL.

Let’s suppose we want to use the newer version of the same module due to the new version has some features that the previous ones don’t have, but we want to do it in the same app, even in the same file/feature.

We can take advantage of typescript to set an alias to the new version, e.g:

So, right now we have imported two versions of the same module and we can use those features in different scopes depending on our needs.

Finally, let’s import the colors module from the standard library in order to colorize our logs, e.g:

The output of this piece of code will look like:

Awesome! We found a cool way to manage and use multiple versions for a single module, we can also do the same for all the modules we want without worrying that we must refactor our entire app due to some conflicts due to multiple versions and/or features.

Third Experiment: Security

When we work with Node.js we usually realize our app runs without asking for any additional permission, meaning, you create an app, then read and write on your filesystem and perform any action within the runtime.

Deno is based on security, so when the app or any script starts running, users are asked for permissions, so depending on what users are doing, they allow: reading, writing and of course allow to establish a connection within their network. For instance, let’s imagine we got a Deno app and we want to run it via command line as we always do with Node.js, e.g:

As it’s indicated within the console, we need to allow the script running with network permissions, we can invoke our script with the specified flag as follows:

So, finally our script is successfully running!


This small app has been created for testing purposes only, the source code will be available on GitHub.

Conclusion and thoughts:

This is a very small experiment, but we can come clean with:

  • Feels faster than Node (reading, writing).
  • It has good native modules, so it’s more standalone and no need for external dependencies.
  • You can code with less code.

Coming up next…. Deno vs NodeJS