When the creator of Node.js built Deno, he wanted to fix the mistakes of his original creation. Eight years later, Deno is joining Cloudflare, and its standalone runtime is approaching the end of official development. So, did Node.js finally win the JavaScript runtime war?
On October 9, 2026, Cloudflare announced that it was acquiring Deno, the company behind the JavaScript and TypeScript runtime created by Ryan Dahl.
For anyone following the JavaScript ecosystem, this was big news. But the acquisition itself wasn't the most surprising part.
The real surprise was what would happen to Deno.
According to the official announcement, the Deno team will continue maintaining the runtime for another year, providing monthly bug fixes and security updates. After that, the team will stop developing the runtime. Deno Deploy, its hosting platform, will shut down after six months.
Deno will remain open source, meaning the community could potentially continue its development.
Still, the announcement marks the end of an important chapter in JavaScript's history.
And it raises an interesting question.
Has Node.js finally won the JavaScript runtime war?
I believe the answer is yes, at least when it comes to becoming the default general-purpose JavaScript runtime.
But the story is much more interesting than one technology defeating another.
It All Started With Node.js
To understand what happened to Deno, we first need to understand how Node.js became so important.
Before Node.js, JavaScript was primarily associated with web browsers. Developers used it to create interactive web pages, validate forms, and make websites more dynamic.
Backend applications, meanwhile, were usually developed using languages like Java, PHP, Python, Ruby, or C#.
That changed in 2009 when Ryan Dahl introduced Node.js.
Node.js allowed developers to execute JavaScript outside the browser, including on servers.
Suddenly, developers could use JavaScript to build APIs, web servers, command-line applications, and many other types of software.
One of Node.js's biggest advantages was its event-driven, non-blocking I/O model. Instead of waiting for operations such as database queries or network requests to finish before handling other work, Node.js could efficiently manage many concurrent operations.
This made it particularly attractive for applications involving large numbers of network connections.
But Node.js's success wasn't just about performance.
Something even more important happened.
An ecosystem started growing around it.
The npm package registry became a central part of JavaScript development. Developers could install libraries for almost anything, from web servers and authentication to database access, testing, and build tools.
Frameworks and tools such as Express, NestJS, Next.js, and countless others built upon the Node.js ecosystem.
Over time, Node.js became more than just a runtime.
It became the foundation of an enormous software ecosystem.
And that would eventually become its greatest competitive advantage.
Then Came Deno: A Second Attempt to Get JavaScript Right
Despite creating Node.js, Ryan Dahl wasn't entirely satisfied with how it had evolved.
In 2018, he publicly discussed several design decisions he regretted.
Among the concerns were its approach to security, the complexity surrounding its module system, and decisions that had become difficult to change without breaking existing applications.
So Dahl decided to create a new JavaScript runtime.
That runtime was Deno.
Deno was essentially an opportunity to rethink server-side JavaScript with the benefit of years of experience.
And it introduced several interesting ideas.
Security by default: Unlike traditional Node.js execution, where applications generally had broad access to system resources, Deno restricted access to files, network connections, and environment variables unless permission was granted.
Built-in TypeScript support: Developers could execute TypeScript without first manually configuring a separate compilation toolchain.
Built-in developer tools: Formatting, linting, testing, and several other common tasks were included directly in the runtime.
Web-standard APIs: Deno embraced modern JavaScript standards and APIs commonly associated with browsers.
A different approach to dependencies: Early Deno versions encouraged importing modules using URLs rather than relying on npm and the familiar node_modules structure.
For developers frustrated by JavaScript's increasingly complicated tooling, Deno was refreshing.
Imagine creating a small TypeScript application.
With a traditional Node.js setup, you might have needed to install and configure several separate tools for TypeScript compilation, formatting, linting, and testing.
Deno aimed to provide much of that functionality out of the box.
It was simple, modern, and thoughtfully designed.
On paper, Deno had several advantages.
But having a better design doesn't automatically make a technology more successful.
The Problem Deno Could Never Escape: The Node.js Ecosystem
This is where things became difficult.
By the time Deno arrived, Node.js had already established itself as the dominant server-side JavaScript runtime.
Millions of developers were familiar with it. Companies had spent years developing applications around it. Thousands of important libraries and development tools expected a Node.js environment.
Now imagine you're working on an existing Node.js application.
Your application uses Express for APIs, Prisma for database access, a few authentication libraries, and several other npm packages.
Deno arrives and promises better security, simpler tooling, and built-in TypeScript support.
Would you migrate your entire application?
Probably not.
Unless you're facing a real problem with Node.js, the benefits might not justify the migration effort.
And for someone starting a new project, the situation isn't very different.
Why choose a runtime that might require compatibility work when the entire JavaScript ecosystem already works with Node.js?
This creates what is commonly called a network effect.
The more developers use a platform, the more libraries, documentation, tutorials, and integrations are created for it.
Those resources attract more developers, making the platform even stronger.
Deno wasn't simply competing against Node.js as a piece of software.
It was competing against more than a decade of ecosystem growth.
That's a much harder battle to win.
Deno Eventually Had to Embrace Node.js Compatibility
One of the most interesting developments in Deno's history was its gradual shift toward Node.js compatibility.
Initially, Deno intentionally moved away from several established Node.js conventions.
But developers still needed access to the npm ecosystem.
That demand was difficult to ignore.
In 2023, Deno introduced support for package.json, something Ryan Dahl had previously identified as a design regret in Node.js.
Then, with Deno 2.0 in 2024, compatibility became one of its main selling points.
Deno introduced extensive support for existing Node.js applications, npm packages, package.json, node_modules, and CommonJS modules.
This was a sensible decision.
It made Deno significantly more practical for existing JavaScript developers.
But I think it also revealed something important.
Deno could challenge Node.js's design decisions, but it couldn't afford to ignore Node.js's ecosystem.
And this is perhaps the clearest evidence of who was winning the battle.
Deno had started by questioning the conventions that Node.js established.
Eventually, supporting many of those conventions became necessary for Deno's adoption.
In fact, the Deno 2.0 announcement prominently highlighted Node.js and npm compatibility.
Think about that for a moment.
A runtime created as an alternative to Node.js eventually had to become compatible with Node.js to make itself more attractive.
That's how powerful the existing ecosystem had become.
What the Numbers Tell Us
Developer surveys also help explain the difference in adoption.
According to the 2026 Stack Overflow Developer Survey, Node.js remained one of the most widely used web technologies.
Among 10,281 respondents answering the web frameworks and technologies question:
| Technology | Respondents who used it |
| Node.js | 46.4% |
| Deno | 4.0% |
These figures represent respondents who reported extensive development work with those technologies during the previous year. They are not a direct measurement of production market share.
Nevertheless, the gap is enormous.
The State of JavaScript 2025 survey showed a similar pattern. Among its respondents, 10,062 reported regularly using Node.js, compared with 2,321 for Bun and 1,244 for Deno.
Different surveys use different questions and audiences, so the figures shouldn't be treated as universally representative.
However, the overall picture is difficult to ignore.
Node.js remained the established choice, while alternative runtimes were still working to expand their adoption.
And adoption matters.
Companies don't choose technologies based only on benchmarks or elegant APIs.
They also consider long-term maintenance, available libraries, developer experience, community support, and how easily they can hire people familiar with the technology.
Node.js had a substantial advantage in nearly all these areas.
Node.js Didn't Just Survive. It Improved.
Here's another important part of this story.
Node.js didn't remain frozen while Deno and Bun tried to improve the developer experience.
It continued evolving.
Modern Node.js includes capabilities that were previously associated with external tools or competing runtimes.
For example, Node.js now provides a built-in test runner, native support for several modern Web APIs, a permission model, and built-in TypeScript type stripping.
Of course, these features don't make Node.js identical to Deno.
Their approaches and defaults still differ, particularly around security and tooling.
And it would be an exaggeration to claim that every improvement in Node.js happened because of Deno.
But competition certainly helped bring attention to weaknesses in the traditional JavaScript development experience.
Deno demonstrated that developers wanted a simpler runtime with fewer configuration requirements.
Bun showed how much performance and tooling integration could matter.
Node.js, meanwhile, could continue improving without asking developers to abandon the ecosystem they already depended on.
That's an incredibly strong position.
A competitor might offer a better experience in some areas, but the established platform can gradually adopt similar improvements while retaining its existing users.
This is one reason why replacing a mature platform is so difficult.
Sometimes the established technology doesn't need to defeat its competitors. It simply needs to improve enough that switching becomes unnecessary.
Cloudflare Acquiring Deno Is More Than Just an Acquisition
Now we come back to the announcement.
Cloudflare acquiring Deno shouldn't be interpreted as Cloudflare simply purchasing another JavaScript runtime to compete with Node.js.
The real story is about infrastructure.
Ryan Dahl's ambitions have gradually moved beyond improving the experience of executing JavaScript.
He now wants to simplify how developers build and operate distributed applications.
And that's where Cloudflare comes in.
Cloudflare already operates Workers, a platform that allows developers to execute application code across its global network.
Unlike a traditional application server that runs on a particular machine, Workers follows a model designed around distributed, serverless execution.
Cloudflare also provides Durable Objects, which make it easier to manage persistent state, coordinate operations, and build real-time applications.
For example, imagine building a multiplayer application or chat platform.
In a traditional architecture, you might need separate systems for application servers, persistent storage, coordination between servers, and scaling.
Durable Objects offer a different abstraction by allowing individual objects to combine computation, state, and communication.
Ryan Dahl became interested in extending this programming model beyond Cloudflare's own infrastructure.
That led to celld, an open-source project designed to make distributed Workers-style applications easier to operate on self-hosted infrastructure.
Meanwhile, Cloudflare already had workerd, its open-source Workers runtime.
The plan is to bring these projects together.
According to the joint announcement from Cloudflare, the goal is to make Workers and Durable Objects practical outside Cloudflare's infrastructure as well.
In other words, the Deno team is moving toward a different problem.
Rather than building another general-purpose JavaScript runtime, it wants to rethink the programming model used to build and deploy server applications.
And that is a much bigger ambition than simply making JavaScript run faster.
What Happens to Deno Now?
The acquisition has several practical consequences for developers.
Deno has officially announced the following plans:
- Deno runtime: Monthly bug-fix and security releases for another year, followed by the end of development by the Deno team. This points to approximately October 2027.
- Deno Deploy: The hosting platform will continue for six months before shutting down, approximately April 2027. Paying customers will receive migration support for moving to Cloudflare Workers.
- JSR: The JavaScript Registry will continue operating, with its infrastructure moving to Cloudflare.
- rusty_v8: Development and support will continue, with work planned toward integrating it into
workerd.
Importantly, Deno itself will remain open source.
This means the project doesn't necessarily have to disappear.
Another organization or the open-source community could continue maintaining and improving the runtime.
However, maintaining a production-quality runtime requires considerable effort, especially when dealing with security updates, JavaScript engine changes, platform compatibility, and the constantly evolving Node.js ecosystem.
Whether community development can replace the original team's work remains uncertain.
For companies running applications on Deno, the announcement is a reminder that the long-term future of a technology matters just as much as its present capabilities.
But What About Bun?
You might be wondering where Bun fits into this story.
Bun is another modern JavaScript runtime that has attracted developers through its performance, fast package management, and integrated tooling.
Interestingly, Bun also became part of a larger company.
In December 2025, Anthropic announced that it was acquiring Bun to support its development infrastructure, including Claude Code.
So, within a relatively short period, two major challengers to Node.js had been acquired.
Does that mean both failed?
Not necessarily.
There is an important difference.
Anthropic has stated that it intends to continue investing in Bun as a general-purpose JavaScript runtime and development toolkit.
The Deno team, on the other hand, has explicitly announced that it will stop developing its standalone runtime after the maintenance period.
These are very different outcomes.
Bun can still grow, innovate, and compete with Node.js.
Its performance advantages and integrated tooling remain attractive.
But even Bun puts significant emphasis on compatibility with the existing Node.js ecosystem.
And that supports my broader argument.
New runtimes can compete with Node.js, but the Node.js ecosystem has become the standard they must accommodate.
The war for ecosystem dominance is very different from the ongoing competition to build the best runtime.
So, Did Node.js Really Win?
I think it did.
But we need to be clear about what winning means.
Node.js hasn't proven itself to be the fastest runtime in every benchmark.
It doesn't necessarily offer the simplest developer experience.
And it certainly isn't perfect.
Deno brought meaningful improvements to JavaScript development, while Bun continues to push performance and tooling forward.
Cloudflare Workers is also demonstrating that running JavaScript doesn't always require a traditional Node.js-style server environment.
Innovation hasn't stopped.
The important distinction is between winning the ecosystem and winning every technical comparison.
Node.js won the ecosystem.
It became the default choice for server-side JavaScript, built an enormous community, and established conventions that even its competitors increasingly support.
When developers create a JavaScript library, compatibility with Node.js remains an important consideration.
When companies select a runtime, Node.js is frequently the safe starting point.
When a new JavaScript runtime enters the market, one of the first questions developers ask is whether their existing npm packages will work.
That is a remarkable position for a technology introduced back in 2009.
Deno's story highlights how difficult it is to challenge that position, even when the challenger comes from the creator of the original technology.
Deno Didn't Win the War, but It Changed the Battlefield
I don't think Deno should be remembered as a failure.
Its impact goes beyond its adoption numbers.
Deno challenged assumptions about what a JavaScript runtime should provide.
It helped popularize conversations around security by default, built-in TypeScript support, Web-standard APIs, and integrated developer tooling.
It demonstrated that developers shouldn't necessarily need a collection of external packages just to get started with a modern application.
Those ideas have influenced the direction of the broader JavaScript ecosystem, even when developers didn't adopt Deno itself.
And perhaps that is one of the most valuable forms of competition.
A challenger doesn't always need to replace the established platform to make a difference.
Sometimes, forcing the established platform to improve is an achievement in itself.
There is also something fascinating about Ryan Dahl's journey.
He created Node.js to simplify server-side programming with JavaScript.
Years later, he created Deno to address the limitations he saw in Node.js.
Now, he is joining Cloudflare to work on the complexity of distributed applications.
At every stage, the problem he wanted to solve became bigger.
First, it was about executing JavaScript on servers.
Then, it was about improving the JavaScript runtime.
Now, it is about changing how server applications are built and operated.
That is an interesting evolution.
Final Thoughts
If someone asked me today which general-purpose JavaScript runtime I would recommend for a new, long-term project, Node.js would still be my default recommendation.
Not because it is necessarily the best at everything.
But because it offers a mature ecosystem, broad compatibility, strong community support, and a comparatively predictable future.
Bun is worth exploring when its performance or integrated tooling offers a clear advantage.
Cloudflare Workers is worth considering when its execution model fits the application's requirements.
For existing Deno applications, developers should review their dependencies on Deno-specific APIs and hosting services, and begin evaluating their long-term options rather than waiting until the announced support period ends.
As for Deno, its ideas and contributions deserve recognition, regardless of what happens to the standalone runtime.
The JavaScript ecosystem is better because Deno existed.
But in the battle to become the default runtime, Node.js had already established a lead that proved incredibly difficult to overcome.
Cloudflare's acquisition of Deno, and the decision to end the team's development of the runtime, makes that reality clearer than ever.
Node.js won the runtime war. But Deno helped change what developers expect from a JavaScript runtime.
And with developers increasingly shifting their attention toward distributed computing, serverless platforms, and AI-driven applications, perhaps the next important battle won't be about which runtime executes JavaScript.
It will be about how we build and deploy applications in the first place.