Version 2.0 of Deno, a JavaScript and TypeScript runtime, is now feature complete and a release candidate is available, four and half years after the release of Deno 1.0 in May 2020; but the project’s limited adoption versus Node.js suggests that its big bets, on TypeScript and ECMAScript modules, have yet to pay off.

In Deno version 2.0, some key APIs are no longer flagged unstable. These include WebGPU, FFI (foreign function interface) functions for calling native code, and createHttpClient for using the Fetch API with custom certificates or a proxy connection.

A major new version is an opportunity for breaking changes, and in Deno 2.0 the global window variable, designed to improve compatibility with code running in the browser, has been removed. It caused problems with libraries which check for this variable specifically to discover if the code is running in a browser. 

There is also a list of removed APIs in the Release Candidate blog post which will require attention when migrating from 1.0 to 2.0; a migration guide is available.

Deno 2.0 improves Node.js compatibility by supporting the process global variable, used by Node, which means more libraries written for Node will run seamlessly. There is also better support for CommonJS, particularly when used in the developer’s own code rather than in libraries. More Node.js APIs are now supported, further improvement compatibility with Node.js libraries.

Dependency management has been revised, and the permission system has changed to distinguish between operating system and Deno permissions. 

Deno 2.0 removes the bundle subcommand, because it did not do what developers expected it to do. It was not a customizable bundler, but rather “a simple tool to concatenate multiple files into a single-file for easier distribution.” There are plans for a future bundler, presumably with more sophisticated features.

TypeScript 5.6, the latest version, will ship with Deno 2.0.

Deno was invented by the creator of Node.js, Ryan Dahl, and when 1.0 was released he wrote about the compromises and mistakes in Node.js, which dates from 2009, in part because “Node had to invent concepts which were later taken up by the standards organizations and added to the language differently.” Deno was intended to be both simpler and more standard, adopting for example the ECMAScript module system (ESM) versus CommonJS as used by Node. Other key changes included native TypeScript support and no requirement for a node-modules folder, the location used by Node for dependencies.

Since that time, Deno has attracted significant usage but still far below that of Node.js. According to StackOverflow’s 2024 survey, 40.8 percent of developers use Node.js versus just 1.9 percent for Deno. The fact that many Deno 2.0 features are focused on improved Node.js compatibility suggests that Dahl and his team under-estimated the importance of this; it also means that much energy has been expended on this aspect rather than on more innovative features.

Deno rival bun, which from its beginning embraced Node and CommonJS compatibility, has won more attention as a result; and the Node.js project itself has moved to add some TypeScript support, potentially removing one of Deno’s key differentiators.