Deno 2 quick overview

JavaScript runtimes

Deno is a JavaScript runtime, built on V8, Rust and Tokio. Released in 2018, it just hit a major milestone with the release of Deno 2.0 in October 2024.

Core design principles

  • Zero config TypeScript support
  • ECMA Script modules only
  • complete toolchain with included:
  • test runner
  • standard library
  • linter and formatter
  • built-in HTTP server
  • support for Web API's (fetch,crypto, web sockets, workers and many more)
  • requires explicit permission for:
    • network access
    • file access
    • environment access
  • JSR registry like npm but for ESM only
  • Node.js backward compatibility layer

Getting started

The easiest way to install Deno is to either use:

  • Shell curl -fsSL https://deno.land/install.sh | sh
  • Or homebrew brew install deno

For more methods and OS please refer to official docs

Create a Deno project deno init deno_test

It will create the project with a simple TypeScript example and a test.

VSCode setup

To support Deno in VSCode you need to install official plugin Make sure you provide the Deno path to the extension which deno and copy it to deno.path You can autogenerate settings with cmd + shift + p or ctrl + shift + p and select Deno initialize Workspace configuration Above step will create .vscode/settings.json with base setup for Deno for you.

Deno config file

Deno init created Deno config file deno.json with the following contents

{
  "tasks": {
    "dev": "deno run --watch main.ts"
  },
  "imports": {
    "@std/assert": "jsr:@std/assert@1"
  }
}
  • tasks act as scripts field in the Node.js package.json
  • imports is similar to dependencies - it will contain your JSR and NPM packages

Additionally, you can configure other things like:

  • lint - config will apply to built-in linter
  • fmt - config will apply to build-in formatter
  • compilerOptions - config for TypeScript
  • unstable - toggle to enable unstable Deno features

Note: Deno provides JSON schema for autocomplete in the config file: https://deno.land/x/deno@v2.0.3/cli/schemas/config-file.v1.json?source

We can now run the tests: deno test

JSR

JSR is Deno's version of npm - aiming to not replace the npm but to be it's superset. You can use it with any JavaScript package manager (pnpm, yarn, npm).

Example

Let's try to install valibot package from the JSR in our demo project:

  • run deno add jsr:@valibot/valibot
  • new entry will be added to deno.json and deno.lock
  • import it like in regular project import {email, minLength, object, pipe, string} from "@valibot/valibot"; Everything works the same way as in the regular Node project:
const LoginSchema = object({
	email: pipe(string(), email()),
	password: pipe(string(), minLength(8)),
});

Developer Experience Advantages

Provides great DX for package authors with:

  • auto-generating the d.ts and docs
  • enforcing the semver
  • no need for the bundling process, just export your entry TS file
  • publishing package via CLI deno publish or link to Github repository

Provides great DX for package users:

  • has scoring system to determine package health, example of Hono framework score
  • provides automatic commands of how to use it with popular package managers and runtimes
  • basic docs - autogenerated from the source-code
  • source code overview (you don't have to visit Github to check source code)
  • JSR packages can be used in any JS project that has node_modules

To demonstrate last point I will install the Deno standard library collections module in regular Node.js project:

  • We need to install the collections module pnpm dlx jsr add @std/collections
  • Import it like a regular npm package:
import { maxBy } from "@std/collections";
const t = maxBy(
		[
			{ name: "Anna", age: 34 },
			{ name: "Kim", age: 42 },
			{ name: "John", age: 23 },
		],
		(person) => person.age
	)

Tradeoffs

  • Sadly there are many packages still missing in JSR (total 7184) - hopefully it will change over time 🤞
  • JSR has strict policies for TypeScript, ESM and package score - it won't help with adoption for other packages
  • JSR Search Orama based search has significant usability issues, as highlighted by the lack of relevant results and incomplete or deprecated packages appearing in searches. original issue

Standard library

Sadly, unlike other programming languages, JavaScript still lacks a standard library. Deno Team and its community seem to be filling in this missing part. STD is available on the JSR with the following advantages:

  • written in TypeScript
  • no external dependencies
  • reviewed by the Deno Core Team Members
  • designed to work in any JavaScript environment
  • fully-tree-shakeable

Even if the code is on the JSR you can import some modules to the regular JS project, for example:

  1. pnpm dlx jsr add @std/encoding
  2. import * as _std_encoding from "@std/encoding";

Summary

Deno will be an ideal "starter" for any JS code challenges like the advent of code. Deno's zero-config setup really shines here.
CLI tools and automation scripts may also really benefit from the Deno security model.
I don't expect Deno to gain more popularity in the upcoming years.

Advantages

  1. Built in cross-platform binary creation
  2. Security model for files, environment access and network
  3. Complete toolchain, no need for installing linters, formatters, bundlers etc.
  4. Out of the box TypeScript support (Node is working on it too)
  5. Support for Web API's
  6. LTS versions

Tradeoffs

  1. Limited ecosystem compared to the npm registry
  2. Many Node packages still need testing with the compatibility layer
  3. Deno's funding, primarily from venture capital sources
  4. Way smaller community
  5. No Deno SQL Lite API 😉 (Node already has it as an experimental)