Deno

Deno is a modern runtime for JavaScript and TypeScript created by Node.js’s original author to fix design regrets in Node — a permissions-based sandbox, native TypeScript execution with no build step, and Web-standard APIs (fetch, Web Streams, WebSocket) instead of a Node-specific API surface. It’s built in Rust on top of the V8 engine and the Tokio async runtime, with the actual JS/TS execution engine exposed as the separate deno_core crate that other Rust projects can embed independently of the full CLI.

Beyond the runtime itself, Deno ships as a single self-contained binary bundling a formatter, linter, test runner, bundler, and dependency-free package management (via URL and JSR/npm imports) — replacing a typical Node project’s stack of separately-installed tools (ESLint, Prettier, Jest, webpack, npm) with one built-in toolchain.

What You Get

• A permissions-sandboxed runtime requiring explicit flags (—allow-net, —allow-read, etc.) for file, network, and env access
• Native TypeScript execution with zero configuration and no separate build/transpile step
• Web-standard APIs (fetch, Web Streams, WebSocket, URL) instead of Node-specific globals, for closer parity with browser JS
• A built-in toolchain: formatter (deno fmt), linter (deno lint), test runner (deno test), and bundler in one binary
• npm and JSR package compatibility plus direct URL imports, alongside the separately embeddable deno_core JS engine crate

Common Use Cases

• Running TypeScript scripts and services directly without a separate tsc/babel build pipeline
• Building sandboxed, security-sensitive server-side JavaScript where explicit permission grants reduce the blast radius of dependencies
• Replacing a multi-tool Node.js project setup (separate linter, formatter, test runner, bundler) with Deno’s single built-in toolchain
• Embedding a JS/TS execution engine inside a larger Rust application via the deno_core crate rather than the full CLI

Under The Hood

Architecture — Deno’s codebase is a Cargo workspace of many crates: cli/ holds the main binary (main.rs, factory.rs, module graph resolution in graph_util.rs/graph_container.rs, npm/JSR handling in npm.rs/registry.rs), ext/ contains the Web-standard and Node-compat API implementations as individual ops crates (fetch, crypto, net, fs, webgpu, node, node_crypto, etc.), and runtime/ wires those extensions into a bootstrapped JS runtime. The core JS execution engine — embedding V8, managing the op dispatch system between Rust and JS, and snapshotting — is factored out into the separately publishable deno_core crate, which is what other Rust projects depend on when they want to embed a JS engine without the full CLI’s npm/LSP/testing machinery. Tech Stack — Rust workspace on the 2026 toolchain (rust-toolchain.toml), V8 for JS/TS execution, Tokio for async I/O. TypeScript itself is compiled/checked via a Rust-native or embedded pipeline rather than shelling out to tsc. The cli/lsp module implements a full Language Server Protocol server for editor integration. Code Quality — tests/ is a large, dedicated integration-test tree separate from the per-crate unit tests embedded throughout cli/ and ext/; the project also runs an integration_tests_runner.rs harness. A CLAUDE.md file at the repo root documents AI-agent-facing conventions for the codebase, reflecting active investment in contributor and tooling ergonomics. Commit velocity (523 commits/month, 17k+ total commits, 1,257 contributors) reflects a large, sustained core team plus broad community contribution. API Design — The CLI surface (deno run, deno test, deno fmt, deno lint, deno task) is deliberately consistent and subcommand-based, and permission flags follow one predictable --allow-* pattern across every capability, so learning one flag transfers to all of them — a deliberate ergonomic choice distinguishing it from Node’s implicit-access model.