Creator of Node talks Deno 2.0 and the Future of JS

TL;DR

Deno’s default module stance is ESM-first, with CommonJS treated as a compatibility fallback rather than a recommended authoring pattern.

Briefing Cornell Notes

Briefing

Deno’s creator, Ryan Dahl, frames Deno 2.0 and the broader Deno ecosystem as a long-overdue correction to server-side JavaScript: stop treating the browser’s module and security model as optional, and rebuild the tooling stack around standards, safety, and simplicity. The core through-line is that JavaScript on the server should track what works in the browser—especially the ES module system—because mixing incompatible module styles (like CommonJS and ESM in the same file) creates avoidable technical debt.

Dahl traces the path from Node to Deno through a series of engineering tradeoffs. Node’s original design leaned on Go and V8, but Dahl left the Node project in 2012 after concluding that Go’s garbage collection plus V8’s garbage collection in the same process could become problematic. Rust then became the foundation for Deno, not primarily for memory safety, but for practical engineering advantages: a unified build system, a unified package manager, and straightforward dependency management. He also describes Rust development as mostly smooth at scale, with the main pain point being compile times—especially when link-time optimization makes release builds slow—mitigated through CI and caching.

On the JavaScript side, Dahl’s stance is blunt: ESM is the specified module system, and CommonJS should be left behind at the top level. Deno still supports CommonJS modules for compatibility, but it treats that as a fallback buried inside the runtime rather than a first-class authoring pattern. He argues that TypeScript fits into this standards-first worldview as a pragmatic bridge: types can be stripped for execution, and the long-term goal is for browser-native handling of TypeScript-like syntax (or an equivalent) so types become a layer that doesn’t change runtime semantics.

A major ecosystem pillar is jsr, a new JavaScript registry designed to replace the “stuck” feeling of npm publishing. Dahl criticizes npm’s feature stagnation and the operational confusion that comes with private registries and packaging mistakes (like incorrect file globs and main-file mismatches). JSR is positioned as open-source and “delightful” for both publishers and consumers: it autogenerates docs, includes security features, supports TypeScript publishing, and integrates natively with Deno via imports like jsr:… . For other runtimes (Node, Bun, Cloudflare Workers), it uses an npm adapter layer.

Dahl also addresses governance and trust in package ecosystems. He calls npm scope and package squatting harmful—citing a long-running issue where a similarly named “dino” package appears to mislead installs—and says JSR reserves well-known scopes and can remove scopes from squatters, handing them to verified organizations (he mentions Salesforce as an example). He extends the theme to branding and legal risk, arguing that “JavaScript” is a trademark owned by Oracle and that the mark may be vulnerable to cancellation due to questionable evidence of use; he points to an open letter and a planned petition process.

Finally, Deno’s security model is presented as permission-by-default, inspired by how browsers protect access to sensitive resources like webcam and microphone. Instead of granting permissions per dependency, Dahl says Deno applies checks at the V8 isolate level, which still provides meaningful containment—especially for deployments running untrusted code. He also highlights Deno’s Rust-to-V8 plumbing via Rusty V8 and a layered runtime architecture, and he downplays WebAssembly hype while noting that Deno can already execute wasm and is moving toward simpler import-based integration.

Taken together, the message is that Deno 2.0 isn’t just a runtime update; it’s an attempt to make server-side JavaScript feel coherent—one module system, one toolchain, one registry, and a security posture that assumes code is untrusted by default.

Cornell Notes

Ryan Dahl portrays Deno 2.0 as a standards-driven reset for server-side JavaScript: use ESM as the default module system, align runtime behavior with browser expectations, and reduce ecosystem chaos through a unified toolchain. He explains the Node-to-Deno transition as a shift from Go+V8 concerns to Rust’s practical strengths (build, packaging, dependency control), while acknowledging Rust compile-time pain at Deno’s scale. Deno’s ecosystem strategy centers on jsr, a new registry meant to be more secure and more straightforward than npm publishing, with native Deno imports and adapters for other runtimes. Dahl also defends Deno’s permission-by-default security model (enforced at the V8 isolate level) and argues that TypeScript is the pragmatic path toward typed JavaScript without changing runtime semantics.

Why does Dahl say Deno should default to ESM and treat CommonJS as a compatibility layer rather than an authoring style?

He ties the module decision to the ES module specification and to avoiding long-term technical debt. Dahl argues that ESM is the specified module system and that mixing require and import in the same file creates avoidable pain later. Deno still supports CommonJS modules, but it’s implemented deeper inside the runtime so developers don’t build new code around CommonJS patterns.

What practical reasons does Dahl give for moving from Go+V8 (Node’s era) to Rust (Deno’s foundation)?

Dahl’s main concern was running two garbage collectors in one process: Go’s GC and V8’s GC. He also emphasizes Rust’s engineering advantages beyond memory safety—especially a unified build system, a unified package manager, and easy dependency inclusion. He describes Deno’s Rust development as mostly smooth, with compile time as the biggest scaling pain (including slow release link steps when LTO is enabled).

How does jsr aim to fix problems Dahl associates with npm publishing and private registries?

Dahl describes npm as feature-stagnant and highlights recurring packaging mistakes in npm workflows, especially in private registries (wrong file globs, confusion around main vs actual entry files, and weak validation). JSR is positioned as open-source and “delightful” for publishers and consumers: it autogenerates documentation, includes security features, supports publishing TypeScript directly, and integrates with Deno via jsr:… imports. For Node/Bun/Cloudflare Workers, it uses an npm adapter layer.

What governance approach does Dahl say JSR takes toward squatting and scope ownership?

He argues that squatting harms the community by tricking installs into pulling the wrong packages. Dahl says JSR reserves well-known scope names and can remove scopes from squatters, then reassign them to verified organizations. He cites Salesforce as an example of a company requesting and receiving reservation after proving identity.

How does Deno’s security model work, and why is it isolate-level rather than per-dependency?

Dahl frames Deno’s security around V8’s sandboxing and the browser model of permission prompts for sensitive resources. In Deno, code must opt into access to disk or network. He says V8 currently lacks primitives to enforce permissions at per-module or per-dependency granularity, so Deno applies permission checks at the V8 isolate level (process/thread scope). He notes this still helps by allowing whitelisting of specific domains and failing safely when code tries to access anything else.

What does Dahl say about TypeScript’s role given Deno’s standards-first stance?

He calls TypeScript pragmatic and productivity-enhancing, and he suggests types can be stripped quickly so browsers can execute the underlying JavaScript. Dahl’s hope is that TypeScript (or a similar system) becomes the next version of JavaScript in practice, while Deno already supports writing TypeScript even though browsers don’t yet natively understand it.

Review Questions

What engineering and ecosystem problems does Dahl attribute to mixing module systems, and how does Deno’s ESM-first stance address them?
How do Dahl’s reasons for choosing Rust over Go+V8 connect to Deno’s build and dependency workflow?
What mechanisms does jsr use to improve publishing reliability and scope ownership compared with npm?

Key Points

1
Deno’s default module stance is ESM-first, with CommonJS treated as a compatibility fallback rather than a recommended authoring pattern.
2
Dahl’s Node-to-Deno transition centers on concerns about running Go and V8 garbage collection together, plus Rust’s unified build and package management workflow.
3
Rust compile times become a real scaling issue for Deno at hundreds of crates, but CI and caching are used to manage release build latency.
4
jsr is positioned as a more reliable, security-focused registry than npm publishing, with native Deno imports and adapters for other runtimes.
5
JSR governance includes reserving well-known scopes and removing scopes from squatters, with scope reassignment to verified organizations like Salesforce.
6
Deno’s permission-by-default security model is enforced at the V8 isolate level because V8 lacks finer-grained primitives for per-dependency permissions.
7
Dahl argues TypeScript is the pragmatic bridge to typed JavaScript, with an eventual goal of type stripping so runtime semantics remain JavaScript-like.

Highlights

Dahl calls mixing require and import in the same file “doing it wrong,” arguing it creates technical debt that only shows up later.

Rusty V8 is described as a zero-overhead Rust binding layer over V8’s C++ API, making V8 embedding more ergonomic through Rust’s type system.

JSR is pitched as “delightful” for publishers and consumers—autogenerated docs, security features, and TypeScript publishing—plus native Deno imports via jsr:… .

Deno’s security permissions are applied at the V8 isolate level, inspired by browser permission prompts, to sandbox disk and network access for untrusted code.

Topics

Deno 2.0
ES Modules
jsr Registry
Rusty V8
Package Security

Mentioned

Ryan Dahl
ESM
LTO
CI
V8
JSR
npm
LSP
IRC
XHR
VM
TC39
GN
WASM
GN