Ryan Dahl keeps finding fault with his own success

Ryan Dahl returned to a JavaScript conference in Berlin in 2018 with a peculiar gift for the people using his software: a list of things he wished he had done differently. Nine years earlier, he had introduced Node.js at JSConf EU. Now he was back to examine its design, including decisions that had become difficult to change because so much software depended on them. Success had made his early choices everybody else’s working conditions.

The talk was called “10 Things I Regret About Node.js.” It was an unusual way to spend the goodwill of a room full of developers. Most creators arrive with a roadmap. Dahl arrived with corrections. He discussed security, the build system and the machinery for finding and loading code. These were practical complaints, directed at a system he knew from the inside. The awkward detail was his own name on the original work.

At the end came Deno, a new JavaScript and TypeScript runtime. A runtime supplies the environment in which a program executes; Node had made JavaScript useful far beyond the browser. Deno offered another approach to that job. Dahl’s reputation might have bought him a hearing. His willingness to revise the design gave the audience something to argue about afterward. In software, even remorse can arrive with installation instructions.

Before JavaScript, a one-way ticket

Dahl grew up in San Diego, with early access to an Apple IIc and a mother who encouraged his interest in computers. As a teenager, he saved money from working as a movie theater projectionist to buy a used PC. He wanted to run Linux. The equipment was modest, and learning involved a great deal of working things out for himself. A computer was something to investigate, rather than a finished appliance.

His academic route led through community college, the University of California, San Diego, and graduate mathematics at the University of Rochester. There he studied algebraic topology. He eventually left the doctoral program and bought a one-way ticket to South America. Work on a Ruby on Rails website for a snowboard company helped turn programming into a profession. Abstract problems had given way to a client who needed an actual website.

Later, in Germany, two pieces of his work came together: the small server interface of Ruby’s Rack and the nonblocking approach used by Nginx. Google’s V8 JavaScript engine supplied another ingredient. JavaScript programmers already knew how to request something and handle the response later. Dahl saw a way to make that familiar rhythm useful on the server. He had time to work on the idea, and spent months doing so.

A server that could get on with things

The central attraction of Node.js, introduced in 2009, was what happened while a server waited. Reading a file or fetching information takes time. Instead of tying up an execution thread for each waiting request, Node’s event-driven model could arrange to handle the result when it arrived and continue with other work. JavaScript’s event loop made sense in this setting. Waiting could be organized, rather than allowed to hold up the queue.

This did not make every computing problem a JavaScript problem. It did give web programmers a familiar language for building servers and tools. Dahl joined Joyent and worked on Node with other engineers. In January 2012, he handed operational leadership to Isaac Z. Schlueter, the creator of npm. The project had acquired both a community and a future beyond the person who started it.

Being recognized was less straightforward. Dahl recalled people asking for photographs in Japan and online remarks attracting a volume of responses he had not expected. He preferred writing code to carefully maintaining a public persona. He also resisted being assigned a permanent professional identity. His later work at Google Brain, including machine learning, makes a narrow description of him as only a JavaScript specialist rather inconvenient.

The second draft had a lock on the door

Deno 1.0 arrived on May 13, 2020, with Dahl, Bert Belder and Bartek Iwańczuk among the authors of its announcement. The proposal was deliberately approachable: one executable, support for JavaScript and TypeScript, and behavior that followed browser standards where those standards applied. A script could fetch code from a URL. A small program could remain small, without first acquiring an entourage of configuration files.

Permissions were part of the design. A Deno script did not automatically receive access to the disk or network. The person running it could grant that access explicitly. The analogy was familiar from browsers, where a website must ask before using certain capabilities. For a developer running a utility, the practical question became what the program needed to do, and whether it had been allowed to do it.

The company followed publicly in March 2021. Dahl and Belder announced $4.9 million in seed capital and a business intended to build on the open-source technology. They committed to keeping Deno under the permissive MIT license. In June 2022, a $21 million round led by Sequoia added resources. Nat Friedman and Dylan Field were among the participants. The runtime now had a company behind it, with all the obligations that accompany that sentence.

Those obligations included maintaining releases and supporting developers who wanted dependable infrastructure. Deno also joined Ecma International in 2021, with Luca Casonato representing it at TC39, the committee that develops the JavaScript standard. The team was building its own environment while participating in the shared language underneath it. Even an opinionated second draft has to live among other people’s paragraphs.

“I think I’m mildly happy with it so far.”

Ryan Dahl, introducing Deno in 2018

Then his corrections needed correcting

Deno’s original separation from the npm ecosystem looked clean on paper. In practice, developers had existing libraries and projects. In March 2023, Dahl explained why Deno had added support for package.json, a file he had previously criticized. The aim was to make programming easier and faster. If a minimalist module system made ordinary work harder, its elegance had become a questionable bargain.

The problem was specific enough to follow without being a programmer. Importing code from a URL meant identifying a host, a file and a particular version. Two nearly identical addresses could bring two versions of the same library into a project. Familiar short package names, backed by dependency information, could help resolve that. An extra file could reduce the confusion that removing files had created.

By July 2024, Dahl was discussing the drawbacks under the title “What we got wrong about HTTP imports.” Long URLs cluttered code. Versions were awkward to coordinate. Independent servers could disappear at inconvenient moments. Deno responded with import maps and JSR, a registry for modern JavaScript and TypeScript. HTTP imports remained available, but the team had recognized that larger projects needed more structure.

Deno 2, released on October 9, 2024, made compatibility central. It supported Node.js and npm workflows, package.json and node_modules, alongside Deno’s own tools. That combination makes a simple story of replacing Node difficult to sustain. Dahl was working around the habits and dependencies his earlier project had helped establish. A successful ecosystem is a formidable collection of people who have other things to do today.

Another turn, with Cloudflare

On October 9, 2026, Dahl announced that the entire Deno team was joining Cloudflare. The new direction followed work on celld, which used the Cloudflare Workers programming model to make distributed applications easier to operate on independently managed infrastructure. Dahl and Belder would lead an effort to bring code and ideas from celld into workerd, Cloudflare’s open-source Workers runtime.

This moved the center of attention beyond choosing a runtime. An application also needs storage and ways for its parts to communicate. Developers repeatedly assemble those pieces, then operate the machinery underneath. Cloudflare’s Durable Objects bring execution and persistent state together. The joint effort aimed to make the Workers model a supported option on a developer’s own infrastructure as well as on Cloudflare’s network. The work was still ahead of the team.

Cloudflare engineer Kenton Varda explained that workerd’s existing self-hosted support had not provided the full distributed experience. Celld addressed a gap Cloudflare wanted to close. The connection is revealing: Dahl’s next opportunity came from work that borrowed another team’s programming model. A career so often described through individual inventions was moving forward through a deliberately shared design.

For Deno users, the announcement carried concrete consequences. The runtime would receive monthly fixes and security updates for another year, after which the team would end its development. Deno Deploy would operate for six more months. JSR would continue, with infrastructure moving to Cloudflare. The runtime would remain open source. People who had built on Dahl’s previous direction now had decisions of their own to make.

The problem he takes with him

Dahl’s stated interest in the new work includes AI agents. Durable Objects combine persistent state, WebSockets and a JavaScript interface, capabilities he sees as useful for running them. The ambition is to reduce the infrastructure each application has to assemble. It continues a question that was already present in Deno Deploy: how much machinery should a developer have to understand before their program can simply run?

His record offers no promise that the next design will escape compromise. It offers plenty of evidence that he will notice the compromises. Node’s choices became the subject of a conference talk; Deno’s module system became the subject of his own corrective essays. This habit can be productive, and it can leave users with migrations to plan. Public revisions have consequences beyond the person holding the pen.

What makes Dahl interesting is the specificity of the dissatisfaction. He keeps returning to permissions, dependencies, waiting, storage and deployment: the unglamorous decisions that shape a programmer’s day. His projects change; the irritation remains recognizable. Somewhere between an elegant idea and the first person who has to use it on a Tuesday, another complication appears. Ryan Dahl tends to start working on it.