Deno 1.0 is Coming!

📅 March 31st, 2020⋅☕ 4 min read

Today an update regarding the release date of Deno 1.0 was posted on it's official twitter account. It's coming on May 13th 2020 exactly after 2 years of it's initial release. All the major features are said to be achieved.

Nodejs literally shaped the last decade of JavaScript and web development in many cases. Within this time JavaScript and the web have evolved tremendously. Now the web asks for new demands. A new runtime is likely to fulfill most of those requirements keeping the future capabilities in mind. Deno is a runtime for JavaScript and TypeScript built by the main author of Nodejs Ryan Dahl which already has over 46k stars on github. It was announced by Dahl in 2018 during his talk in JSConf EU "10 Things I Regret About Node.js". He regreted mainly about the poorly designed modules system and centralized distribution, not using Promises in API design, package.json and lack of security in Node. To fix all these problems he started all over with a complete new project. The initial release was made on May 13th 2018. It aims to be a productive and secure scripting environment for the modern programmer. Similar to Node.js, Deno emphasize on event-driven architecture, providing a set of non-blocking core IO utilities, along with their blocking versions.(ref)

Deno is built on top of Typescript, Rust, C++ and JavaScript. It used V8, the JavaScript runtime of Chrome and Node and Tokio for the event loop. Deno was intially written in Go which was later replaced with Rust due to concerns of double runtime and garbage collection pressure. Tokio is introduced in place of libuv as the asynchronous event-driven platform.

Main Features

. TypeScript out of the box

It includes the TypeScript compiler in its executable image. So TypeScript support is built in unlike Node. So, when a TypeScript file is executed, it will first compile it to JavaScript and then pass that to the V8 engine.

. Security

Deno executes code in sandbox by default unlike Node. So the runtime won't get access to file system, network, environment variable and execution of other scripts.

. Modules System

In Node we use require to load CommonJS modules which implicitly comes from npmjs.com. As Deno doesn't have any centralized repository for third-part modules like npm, they can be explicitly imported using url using import keyword. So, no more package.json or node_modules. Deno will download the imported modules at the start and cache them. It won't download again unless it's explicitly told to. So, even if the URL of the module goes down and it will still be stored in cache.

// Imports `serve` from the remote Deno standard library, using URL.
import { serve } from "https://deno.land/std@v0.21.0/http/server.ts"

// `serve` function returns an asynchronous iterator, yielding a stream of requests
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" })
}

It also supports local import

First re-export the imported module from a local file

export { test, assertEquals } from "https://deno.land/std/testing/mod.ts"

Then we can import it from local resource. So if the above file name is local-test-utils.ts:

import { test, assertEquals } from "./local-test-utils.ts"

ref1, ref2

Comparison with Node

Uses ES module import instead of CommonJS require
Built-in package manager for resource fetching, decentralized distribution so no need of npm
Runs code in sandbox
Built-in TypeScript compiler
Better browser compability
Mnimizes core API size

ref

As it uses V8 so Google is like to promote so do Microsoft (for TypeScript) and Mozilla (for Rust). Besides being the original author of Nodejs, Ryan is also a big factor to attract the potential investors.

Will it be a game changer? Time will tell.