Deno turns 1: This is behind the Node.js alternative with the dinosaur in the logo

Ryan Dahl wanted to do ten things better with Deno that he doesn’t like about Node.js. On Wednesday the alternative runtime for JavaScript and TypeScript version 1.0 reached. We took a closer look at the node alternative.

Like Node.js, Deno is a runtime environment for JavaScript. Just like Node.js, Deno offers a way to write server-side JavaScript – or TypeScript. It is similar to Node.js in many ways in terms of its functionality, just like Node, it uses the V8 JavaScript engine under the hood and was even started by the same person who is behind Node. Unlike Node, however, Deno was not implemented in C ++ and JS, but in Rust and TypeScript. This means for you: You can write statically typed code directly in Deno without ever having to touch a TS-config.json file – you can access all features within the runtime from the Deno namespace.

Deno comes with some security precautions as standard.

Suppose you want over console.log( Deno.cwd() ) log out the current working directory. You can download such scripts via deno run Execute via the command line – but not without first granting permission to execute such actions within Runtime. In this specific case, we can do this via the –-allow-read-flag:

deno run --allow-read main.ts

There’s something behind this called sandbox, which prevents programs from doing things that you don’t want to allow. This is useful when you want to run a JS program outside of the browser, but don’t want it to just access anything inside your system.

There is nothing in Node.js that prevents a Node.js app from, for example, accessing your SSH keys and forwarding them to a server. You can protect yourself against this if you ensure that only packages from trustworthy authors are installed. But there is still a bit of a security risk; these packages can also be hacked.

Using the sandbox, Deno replicates the browser’s permission model – even JS executed in the browser require your explicit permission to carry out any action on your system. Other flags you can use to grant Deno permissions are, for example --allow-write or --allow-net.

Bye bye callback hell: Promise handling with top-level await

One thing that TypeScript users should be enthusiastic about is that Deno – like TypeScript since V 3.8 – implements top-level await.

In Deno you can execute a network request via the fetch API – as if you were in the browser:

const res = await fetch( ‘’ );

And because Deno supports top-level await, you don’t even need one async-Function.

Browser compatible events

Deno wants to make your code as browser compatible as possible. The runtime includes a window-Object with lifecycle events,

window.onload = event => console.log( ‘t3n says hi 🦕’ )

on which you can schedule event listeners. This makes it possible to write code that can be executed on both the browser and the server side.

Deno is WebAssembly compatible

Deno can also run WebAssembly binaries.

const wasmBinary = new Uint8Array([ 0, 23, 77]);

const wasmModule = new WebAssembly.Module(wasmBinary);


One thing that doesn’t work in Deno, however, is npm packages. Deno is a runtime and package manager in one and is therefore not compatible with the separate package manager. In Deno you can instead import packages using ES module syntax via their URL, for example like this:

import { serve } from ‘’ ;

Remote modules are referenced via URL. When you run a script for the first time, its code is saved and cached locally. There is no package.json. Code can be referenced via any URL, similar to how it works in the browser.

Deno has a selection of standard modules for common use cases. For example, as in the example above, you can use the http module serve import and use it to create a server that will be handled like an async iterable:

// main.ts

import { serve } from ‘’;


const s = serve({ port: 8000 });
for await (const req of s)
req.respond( {body: ‘Deno 🦕 is cool’} );


You can then do the whole thing via deno run --allow-net main.ts 

Deno was released in V 1.0 on Wednesday. In the short term, the runtime will certainly not replace Node.js. Node creates a closed ecosystem that is now relatively stable. It remains to be seen whether the JavaScript developer community will turn away from Node.js in favor of the dinosaur in the longer term. If you want to take a closer look at the runtime, you will find a blog post on V 1.0, a detailed manual, the standard library and all third-party modules that have been supported so far on the team project website.

For further reading: Web Development Now and Later: 3½ Predictions You Should Read

You might be interested in that too

Ready to see us in action:

More To Explore
Enable registration in settings - general
Have any project in mind?

Contact us: