815: Deno 2 with Ryan Dahl

Episode Summary

Executive Summary: Ryan Dahl discusses Deno 2.0 as a production-ready evolution of Deno: ESM-first, web-standards-driven, secure by default, and now broadly compatible with npm, package.json projects, and frameworks like Next.js. The conversation covers Deno’s tradeoffs, performance, JSR, TypeScript’s future, Jupyter/data workflows, and why Deno aims to smooth migration without abandoning modern JavaScript ideals.

Main Topics: Deno 2.0 and npm/Node compatibility: Deno 2.0 significantly expands compatibility so most npm packages and even complex Node-based frameworks can run with minimal changes, including support for package.json projects and Next.js. Standards-first JavaScript vs. ecosystem pragmatism: Ryan argues Deno remains committed to web standards, ESM, and browser-compatible JavaScript, but acknowledges that practical support for npm and Node APIs is necessary for real-world adoption. Security and simplification: A major Deno value proposition is secure-by-default execution, reduced configuration, and fewer supply-chain risks compared with Node’s traditional flexibility, especially around post-install scripts. Performance and deployment: Ryan emphasizes Deno’s speed, particularly cold-start performance and V8 code caching, while noting that performance claims should be grounded in realistic workloads rather than cherry-picked benchmarks. JSR, package publishing, and the future of TypeScript: JSR is positioned as a modern registry for ESM-first packages, supporting better sharing across runtimes. Ryan also sees TypeScript or 'types as comments' as an inevitable direction for JavaScript. Data science, Jupyter, and AI in JavaScript: Deno’s Jupyter support, Observable Plot, TensorFlow.js, and emerging data tooling are presented as signs that JavaScript could become a serious alternative to Python for notebooks, data work, and some ML use cases. WASM’s limits relative to JavaScript: Ryan is skeptical of WASM as a broad replacement for JavaScript, arguing it should be treated as a complementary tool rather than the primary runtime model for web developers.

Key Arguments: Most npm packages now work in Deno, because real-world adoption requires compatibility with the existing ecosystem, not just idealized standards. Deno supports Node APIs by reimplementing or mapping many of them, while some complex ones require lower-level Rust implementations. Security is a major reason to adopt Deno: secure-by-default permissions and avoiding unsafe post-install scripts reduce supply-chain risk. Deno 2 makes migration incremental, so teams can adopt it without rewriting entire applications at once. JSR is intended to be a modern, ESM-first package registry that encourages best practices and works across runtimes, not just Deno. TypeScript is likely the future of JavaScript; types-as-comments could become the browser-native path to type-aware JavaScript. Deno’s performance is strong, especially for cold starts and serverless environments, even if benchmark comparisons are often overstated. WASM is useful but should not be treated as the main future of application development, because most developers still want to write JavaScript directly.

Data Points: Deno age: 7 years - Ryan says Deno started seven years ago; it has been a company for about four years. Node API coverage: ~90% - Ryan estimates roughly 90% of built-in Node APIs are mapped or reimplemented in Deno. Work split for Node compatibility: 50-50 - He says compatibility work is roughly split between API reimplementation and module/package loading support. Linter speed: 100x faster than ESLint - Ryan claims Deno’s Rust-based linter is about 100x faster than ESLint. Express throughput improvement vs Node: ~2x - He suggests Express throughput can see around a 2x improvement over Node in Deno. Cold-start performance: Best-in-class on AWS Lambda - Ryan says Deno’s V8 code caching gives it top-tier Lambda cold-start behavior. Deno 2 release timing: Later this year - He says Deno 2 is expected to ship later in the year. Type stripping complexity: Very simple - Ryan contrasts type stripping with type checking, saying stripping is easy to implement while type checking is much more complex.

Pivotal Quotes: "Deno 2.0 is kind of our marker that Deno is ready for production, ready for use cases." — Ryan Dahl: Describing the significance of Deno 2 and its stability/long-term support direction. "There is no world in which this is going to continue to work like this." — Ryan Dahl: On npm post-install scripts running arbitrary code by default and the need to eliminate them. "JavaScript is for sure going to be here, I think this is inevitable." — Ryan Dahl: On the long-term future of JavaScript, TypeScript, and types in the language ecosystem.

Implications: Deno 2 aims to make modern JavaScript safer, more portable, and easier to adopt without forcing a rewrite. For teams, it offers a practical path to ESM-first, TypeScript-friendly infrastructure with stronger security and better compatibility.