The Disappointing Death of Deno: What Happened, Why, & What's Next
On Friday, October 9, 2026, it was announced that Cloudflare bought the Deno company, the people behind the open source Deno JavaScript runtime. The announcement also came with the disappointing news that the Deno runtime was going into maintenance mode, where it'll receive monthly security patches and bug fixes for twelve months, at which time the core Deno team will stop working on the runtime. The Deno company will also be shutting down their hosting platform, Deno Deploy, in six months.
It was not surprising to me that the Deno company got acquired. They were funded by venture capital investment and there were lots of signs in 2026 that the business was not healthy. But it was surprising to me that the result of the acquisition was the death of the Deno runtime. As a developer who has been all-in on Deno for my personal projects and introduced it in small, controlled ways in past jobs, I'm disappointed and frustrated. Deno, the runtime, is extremely developer friendly and was in many ways my ideal development environment. After having a weekend to reflect on all of this, here's a breakdown of what happened, why, and what could be next.
▶ Watch a ramble video version.
The Great JavaScript Runtime Battle
A JavaScript runtime is basically a program that allows you to run JavaScript code. You write console.log("Hello!"), save it in hello.js, and then tell the JavaScript runtime executable to run that code. The JavaScript runtime evaluates and executes the code, printing Hello! to the terminal. Web browsers are, in a way, the oldest and most long-standing JavaScript runtimes. Those would be considered client-side runtimes, as they run in the browser and not on the server. When it comes to server-side JS runtimes, Node.js has been around the longest (since 2009) and is the most widely used. It's been the de facto server-side runtime for over a decade.
The creator of Node.js is Ryan Dahl. He's also the co-creator of Deno. Just about 10 years after Node.js was released, he announced Deno, a new server-side runtime to address the shortcomings of Node.js. The name Deno comes from "node".split('').sort().join('') // => "deno". Core to Deno from the start was security, simplicity, and a better developer experience.
The Deno runtime was initially written in the Go programming language but switched to Rust. Around this same time, TypeScript (a typed superset of JavaScript) rose to popularity. Deno allows developers to run TypeScript directly without having to compile to JavaScript first, unlike Node.js at the time. Deno release v1 in May 2020. Especially in the runtime's first version, it tried to differentiate itself from Node.js. Deno aimed to be as compatible with the web's ECMAScript standard as possible, using module imports and familiar APIs like fetch. Deno also came with built in code formatting and linting, inspired by other modern languages and toolchains like Go and Rust.
This is around the time I started using Deno for my personal projects. I was writing more and more TypeScript for my day job, and I was excited by Deno because of how little configuration was needed to start a project. I could code zero-dependency TypeScript CLIs and even compile them into executable binaries with no configuration files. Deno has a standard library that can be imported that provides a ton of functions that you'd expect a modern language to have. You could even deno bundle to package up the code to run in the browser. It really did feel like bringing server-side JavaScript and TypeScript into modern times.
A little over a year after Deno hit v1, a third competitor arrived on the scene: Bun. Whereas Deno was trying to evolve the ecosystem, Bun aimed for drop-in replacement with Node.js, while bringing in a lot of what Deno offered: the ability to run TypeScript code directly, a robust standard library, and other ergonomic improvements. As Bun matured and became more capable, the three were capable JavaScript runtimes all with their own pros and cons.
I remember working on a personal at the time and being unsure whether to use Deno or Bun. I'd been using Node.js for a long time at that point, as it's pretty inescapable in modern web application development. So exploring Deno and Bun was exciting and refreshing. In the early 2020s, when comparing Deno and Bun, there wasn't a clear choice for me and my small projects. Bun had a lot of functionality built in, like the ability to easily connect to SQLite without pulling in an external dependencies and hashing algorithms you could easily call. Meanwhile, Deno had its built in formatter and linter, which was very convenient. Deno's built-in functionality that improved the developer experience is what ultimately led to me deciding to use Deno. I also really liked that it wanted to evolve the ecosystem rather than be compatible with Node.js. Deno's vision of the future was something I bought into.
During this time, Node.js was just trucking along as a mature, stable, widely-used runtime. New releases happened with sensible additions but rarely anything too innovative or breaking. But the problem with Node.js is that the ecosystem changes so rapidly that it's exhausting. Let's look at testing, as an example. Jest was the popular option for years. Then it was supplanted by Vitest. There's a lot of churn with frameworks, libraries, and utilities in Node.js. Something appealing about Deno and Bun is that a lot of those ancillary tools and libraries were built in, much like other programing languages. Fewer dependencies means less to upgrade and maintain. It means fewer security vectors.
Deno and Bun were both funded by venture capital investors. The JavaScript ecosystem, more so than any other language I've used, has a lot of investor open source funding. Database ORMs turn into full-fledged products. Some open source JS libraries feel less like collaborative projects and more like polished products (in a way I find unappealing and unusual). The Deno team and the Bun team used their funding to hire developers to work on the runtime. Deno tried to build commercial products, like their Deno Deploy hosting. They also built community projects like JSR, a new JavaScript code registry as an alternative to npm, the Node.js package manager. Deno, or at least Ryan Dahl, also spent a lot of time fighting Oracle's trademark of JavaScript. Bun, meanwhile, just focused on the runtime and vaguely talked about setting up a hosting platform at some point in the future. But investors expect returns on their money. Neither company was a non-profit foundation whose purpose was to build a stable, mature runtime. No, both companies needed to turn one investor dollar into two dollars, or ideally more.
Deno's hosting platform, Deno Deploy, was as simple to use as the runtime. Just push up some code to GitHub and it quickly deployed to the cloud and required no build step. The team added new features regularly, like cron jobs and a key-value store that were built into the runtime, making local development consistent with the hosted app. From my experience deploying a Fresh web application to it, it worked well and met my needs. At the time, it had a lot of potential and hoped that it would work as a sustainable funding source for the Deno company.
It seemed like the three JS runtimes competing would push all of them to become better while also innovating to differentiate themselves. Deno, up until the acquisition and deprecation, continued to add interesting features, like deno desktop to run an application in a web shell. The team built Fresh, a Preact-powered full-stack web application framework built on Deno as an alternative to Next.js. Deno had a vision for a simpler and more secure ecosystem. And the runtime had the tools, library, and team to execute on it.
Deno v2
In October 2024, Deno v2 was announced. Its main selling point was compatibility with Node.js, similar to Bun's. Deno would be compatible with Node.js' package.json and work as a drop-in runtime replacement. Instead of npm run dev, one could deno task dev and it would just work. They also rebuilt their hosting platform, Deno Deploy, but weirdly removed features like the aforementioned cron jobs. Maximizing Node.js compatibility became a shared focus for both Deno and Bun.
At that time, I remember thinking wow, this could be the chance for Deno to take off. There's no reason it shouldn't, given it can just replace Node.js entirely and has a better developer experience than Bun in a handful of ways. But that's not what happened. I can't speak to confidently as to why Deno didn't take off and rocket to success and become the de facto runtime, but I can at least speak to why, as an engineering leader, it never made sense to use Deno for anything other than small internal projects:
It's a bad idea to use a different runtime in development than in production.
Vercel was where the super majority of the TypeScript code that was being run at that job was hosted on. Some apps were also hosted on Render too. But at that time, code deployed to Vercel ran on Node.js. Matching the production environment locally as much as possible helps rule out bugs and strange behavior. "Works locally but not on prod" is terrible for debugging. I experimented with using Deno to run the applications locally, but there were enough issues that it wasn't really feasible. A major appeal of Deno is that the dev tooling (linter, formatter, LSP, etc.) is built-in. But you can't drop all those Node.js dependencies if only one person is using Deno. While Deno can run Node.js apps, that doesn't mean it's sensible to switch to Deno. Especially if the application host doesn't run the code with Deno.
Also, running the apps on Deno Deploy wasn't viable because Vercel had their claws deep into the Next.js applications, from their image optimizer to different caching mechanisms. Deno Deploy was never robust enough to move our mature web applications to it.
So we kept running Node.js to be consistent in the environments our application ran in.
It could be that now Next.js and other hosts support the Bun runtime. It might make sense to use Bun instead. I don't know, as I'm not actively working on any larger TypeScript web applications. But in 2025, even if I wanted to use Deno full-time at work and for personal projects, it didn't make sense to do so. So Deno, for me, was relegated to scripts and hobby projects.
Deno did find some buy-in with larger enterprises though. Slack's SDK, at least at one point, used Deno. Bunny.net's edge scripting runtime uses Deno. Netlify, at one point, used Deno for their scripting. The secure-by-default and ability to run TypeScript without a build step makes Deno a sensible runtime to use for those projects instead of Node.js.
The Decline of Deno & the Rise of LLMs
Deno was failing to have the massive growth needed to make a healthy return on the over US$26 million in investment poured into the company. I have no insight into whether the enterprise support provided by the Deno company amounted to much revenue. I have no insight as to whether or not Deno Deploy had many customers. But from the outside looking in, it sure didn't seem like Deno, the company or the runtime, were thriving.
Ryan Dahl wrote a blog post titled "Reports of Deno's Demise Have Been Greatly Exaggerated" on May 20, 2025, saying things like:
We’re not chasing feature parity with other runtimes. We’re building a cohesive system. We’re trying to fundamentally improve JavaScript development. If we have faulted, it’s because we’ve stretched too far in this goal. But I don’t think anyone can argue that Deno isn’t striving for a better world for the world’s default programming language.
We’re not winding down. We’re winding up.
We’re building new products based on everything we’ve learned from Deploy and KV, not yet released. They aim to make persistent, distributed applications simpler. More on that very soon.
We recognize that our silence has sometimes been a source of uncertainty, and we’re committed to improving our communication as we move forward with these exciting developments.
I remember reading this blog post at the time and really believing in what Ryan Dahl was saying. But looking back in hindsight, the timing was unfortunate. This blog post was written in May 2025, just on the cusp of the rise of agentic development—coding harnesses hooked up to an LLM API to generate code and run commands in a loop until a task is complete.
LLM-powered coding harnesses changed the nature of the Great JavaScript Runtime Battle and the fate of Deno. Deno was, in a lot of ways, primed to be the go-to runtime in a world where developers are using probabilistic coding harnesses to run commands and generate code. The runtime's secure-by-default nature, the built-in tools to check for correctness, the LSP, the running of TypeScript code directly. It was all there. But Deno did not take off alongside the rise of AI coding. In fact, the opposite happened. The second half of 2026 didn't come with any major developments announced in Deno land. Publicly, releases continued to happen (e.g., v2 of the Fresh framework was released). But despite Ryan Dahl's claim Deno was winding up, not down, it sure seemed like the latter.
Bun and Deno both make it easy to build command-line interfaces and compile them into executable binaries. With Deno, you run deno compile and it outputs an executable for your host OS (and others with an additional flag). The binary is large because it includes the runtime itself, but it's a quick and painless process that can be done from any operating system, making both runtimes convenient choices for building CLIs in TypeScript. LLMs are trained on lots of TypeScript and JavaScript. Plus the various type checking and linting tools help LLM-powered coding harnesses check the code being written as it works through the task.
Claude Code, the LLM-powered coding harness built by AI company Anthropic, is built using the Bun runtime. As investment money poured into AI companies and Claude Code became one of the most popular coding harnesses, Anthropic bought the team behind Bun in December 2025. Bun's investors got their payday and the future of Bun's development was financially secured, at least for the foreseeable future. Since one of Anthropic's primary products relied on the Bun runtime, it made sense to buy it, fund it, and have control over it.
I remember wondering why various companies chose Bun over Deno for their CLIs. I'm honestly not sure. Developers closer to the development of coding harnesses and other larger CLIs would have more insight. But regardless, Bun succeeded in the mission of making rich people richer by building an open source JavaScript runtime. One investment dollar likely turned into many more.
Despite Deno being primed for this major shift in how software is developed, the stars didn't align. The Deno company was four years into being fueled by investment dollars, and the team was quite a bit bigger than just a few people. It's not hard to imagine that capital was being burned through pretty quickly and starting to dwindle. I'd imagine Bun's acquisition only added more pressure for there being some sort of return on investment. If I was an investor, I'd be wondering if the competition was bought out by a large AI company, why haven't we been?
The Death of Deno
2026 was not a good year for Deno. In March, there was a mass exodus of employees. The first person I saw leave was the maintainer of the Fresh web application framework. Then one day there was a whole host of people announcing their farewells on social media and looking for new jobs. These were people core to the development of the runtime, the standard library, and the other ancillary projects. It was speculated that there were layoffs, but I couldn't find any confirmation of what actually happened. There was no press release by Ryan Dahl sharing what happened and why, in typical corporate behavior following a layoff. Just social media posts by former employees saying things like: "rooting for Deno from the sidelines now, wishing it all the best, great people!"
Then the hailmary AI passes began. Deno announced Deno Sandbox, a way to run code written by LLMs in a more secure way. You could even call sandbox.deploy() to promote it to Production on Deno Deploy. Kind of neat, and totally sensible given how much changed in the software development landscape since mid-2025. There was even a Python SDK created for it. The Deno team seemed to be taking what they learned from building Deno Deploy combined with the security risks that are inherent to LLMs running commands and generating code, and build a more general purposed environment that's safer to run in.
A few months later, in May, they announced Claw Patrol, an open source project to help protect infrastructure from agents possible causing havoc when they have access to servers, databases, secrets, etc.. It's something they extracted from internal use as they continued to lean into using LLMs for development and infrastructure.
While security-focused products, features, and libraries make sense, I actually think very few organizations who lean heavily into using LLMs for generating code and executing commands take the security implications very seriously. Even though developers know they shouldn't run coding harnesses hooked up to LLMS in full-auto mode with access to the internet and host machine and key infrastructure, it's too easy and too tempting to do it anyway. Maybe Sandboxes and Claw Patrol are widely used and I just don't know it, but I suspect that there's probably a mixture of indifference to the security risks with a flood of similar solutions for the companies who do care about the security risks that didn't lead to these two projects taking off.
Then in August, the Deno company released celld, an open source implementation of the Durable Objects model that Cloudflare created. The celld website says:
The Durable Objects model is one of the best primitives distributed systems has gained in years: a single-threaded object with its own storage, addressed by name. That design belongs to Kenton Varda and the Cloudflare Workers team. celld is a love letter to their idea; a primitive this good deserves to run anywhere.
celld didn't even get an announcement post on the Deno blog like Sandboxes and Claw Patrol did. But I can imagine if you've spent years building a runtime and a hosting platform for that runtime, a more scalable distributed architecture would be exciting and appealing.
While Sandboxes was a product, a thing that you could pay for, Claw Patrol and celld were released as open source projects without even a hint of how they might be turned into products. All three are projects aimed at an industry where LLMs are writing more and more code and have access to more and more infrastructure. It's unclear to me if Claw Patrol, Sandboxes, or celld were met with any kind of serious use. Maybe there was the idea of using celld to back Deno Deploy or some other sort of hosting alternative to Cloudflare that's easier to self-host? I have no idea.
But looking at the mass exodus, these three projects, and a handful of more minor Deno runtime releases, it's clear the clock was ticking at the Deno company for something to change quick. Building a commercially successful software product that can grow in revenue at the order needed by the Deno company takes at least six months, if not years, even with LLMs generating the code. Building wildly financially successful software products is hard. Acquisition seemed the only option, and maybe these efforts were bait on the fishing line to find a suitable buyer? Building and releasing open source tools and libraries doesn't seem like an obvious path to making money or an acquisition. But Silicon Valley is a strange place...
It worked though, at least to some extent. Cloudflare bought the Deno company to have the people work on celld. Cloudflare didn't buy Deno to continue to develop the runtime like Anthropic bought the Bun team. No, it was an acquihire to get Ryan Dahl and Bert and others to work at Cloudflare to work on their open source Durable Objects project workerd:
Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model.
Here's what was shared by Deno about the future of the runtime and their products post-acquisition:
We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development. Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers. JSR will continue operating, with its infrastructure moving to Cloudflare. We will continue supporting rusty_v8 and work toward integrating it into workerd.
The motivations are clear enough from the Deno post:
The need for better abstractions is especially acute with AI. Durable Objects bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface. This is what I’m most excited to explore and why celld focuses on Durable Objects.
Ryan Dahl is excited about a new way of building server-side software in this era of LLM-generated code. And, conveniently, it came with an out: some amount of money returned to the investors, no more layoffs or mass exoduses, no more building a JavaScript runtime with Node.js compatibility.
A commenter on Hacker News asked: "Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?" To which Ryan Dahl responded:
It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough. I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
On the Deno blog post, there's weirdly just a hollow thank you:
To everyone who contributed code, built businesses on Deno, reported problems, and trusted our direction: thank you.
The Future of Deno & Venture Capital-Funded Open Source
I'm sorry but a thank you and reminder that the codebase is open source is not an appropriate response. That's bizarre behavior. That's not being a steward of a project or helping shepherd it onto what's next. That's not actually believing in and investing in open source. Ryan Dahl, I'm sorry that the problems Deno solves aren't big enough for you any longer... I get it, a lot has changed. But like "Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough." is a wild thing to say after spending years and years of saying that these reasons are enough. Sure, Node.js can run some TypeScript code now, but to do anything near what Deno does requires adding dozens of packages and configuration. Node.js-land is a mess of package managers and utilities and versions. Deno had developers who used it for years for good reason and to be told those reasons aren't enough any more is just sad to hear from the person who started both Node.js and Deno.
After almost ten years of selling developers on why we should use Deno and the company's various products and libraries, the outcome of that effort is a year of maintenance, a thank you, and a whole lot of MIT-licensed Rust and TypeScript code. It's clear that Ryan Dahl and the team at Deno put a lot into the project and the products. It's admirable so much of it is free and open source. Good, innovative work went into Deno. Silicon Valley is a strange place where over US$26 million gets transformed into open source code and an acquihire by a large tech company like Cloudflare while the upstart competition that's arguably not any better gets bought by one of the largest AI companies.
I can totally understand how Ryan Dahl might be burnt out by running the Deno company and wants to move onto other more interesting technical challenges. The team built the Deno runtime and standard library and maintained it for years. It was, in that sense, a success.
But a thank you and a year of maintenance is not, in my opinion, a respectful or appropriate way to handle this. What about the Bunny.net's of the world? The companies who invested time and money and infrastructure into Deno and built platforms on it. The developers who have been using it for years and supporting it and enjoying using it? Even if Ryan Dahl or the team aren't interested in working on Deno any longer doesn't mean that you just dump it and run. Even if the resulting products didn't lead to the revenue needed to fund a sustainable company, this isn't an outcome I ever imagined. It's easy to imagine a slightly different approach to this all...
Why didn't Ryan Dahl, the Deno company, and Cloudflare instead open the future of Deno to the community in a collaborative effort? The announcement could have been: we're planning a series of open discussions and calls to establish a Deno Foundation to maintain the runtime moving forward with open governance. Then the developers and companies who rely on Deno wouldn't be left in the place we are now, which is uncertainty as to what to do and who has the right to use the Deno name and assets and all the other legal aspects that come with a situation like this. Ryan Dahl didn't need to have the answers, but I sure do wish there was more of an openness to the future of the Deno project than "If people want to carry it forward, I'd like that." Ryan Dahl, the Deno company, and Cloudflare can and should do more to help Deno transition to open maintainership and governance.
Not long after the mass exodus of staff from Deno in March 2026, the Fresh framework that was built and maintained internally at the Deno company was hoisted out into its own GitHub organization and was no longer an official Deno project. On June 3rd, one of the people who started Fresh, posted a GitHub Discussion saying:
TL;DR: Fresh is now in it's own org so that more people can have review and PR access to it, and so that we can build a public governance structure for it. Deno folks will continue to contribute. Fresh will become Vite-only, and gain a bunch of features in the process. I'm also working on new features around signals and serializable functions to make Fresh even easier to use.
In the four months since, there's been no follow up, no merged PRs, no responses to comments, no insight into the new governance, no nothing. What will happen to Fresh now that Deno is deprecated? What about the people running apps built on Fresh? That's not a simple migration to another framework or runtime.
"Just use Node.js or Bun" is actually not quite so simple of an answer. For any company or business who has invested in Deno, having your runtime effectively killed with no signals of planned continuity into the future by the community or another organization, is a horrible place to be in. What does an organization like Bunny.net do with their runtime being built on Deno? Do they maintain their own fork or help establish an organization to maintain it? Do they switch to Bun? Bun and Deno are not feature equivalent, so it'd take work and effort and have big implications for something at the scale of Bunny.net.
For a developer like me who was bought into Deno's mission and has a whole bunch of small CLIs, scripts, and Fresh web apps that rely on Deno, I'm left feeling upset and uncertain, and to some extent, dupped. I had reservations about Deno's funding and the lack of any sort of open governance for the project, but I wrongly ignored those concerns. I used Deno's Deploy platform (both versions of it) until very recently for my web apps and sites, but moving off of that wasn't too big of a deal for my projects. But I've still got lots of Deno in my pipeline, so to speak. I use it for formatting Markdown and HTML and CSS. I use it for generating static sites. It's been my go-to for years for my personal projects. I maintain libraries that are hosted on JSR. I'm tangled up pretty deeply in Deno's whole mess. The last thing you want as a developer is to go all-in on a core runtime, framework, or library and then get ghosted. You want stability, security, and innovation at a manageable pace.
I won't be using Deno for new projects, that's for certain. Not until it becomes clear if anything will happen regarding the governance of the project into the future or if there will be a maintained fork of it or what. There are too many uncertainties to know what will happen. I definitely won't be publishing packages to JSR any longer.
Sure, some of my projects would easily switch to Node.js or Bun. But I'd miss the built in formatting and linting and LSP that I utilize for my projects. I'm uneasy about Bun being funded and controlled by Anthropic, a company that is building software and behaving in ways that I am morally opposed to. Maybe Bun will overtake Node.js as the de facto server-side JS runtime? But I won't be using Bun. I guess I'd reluctantly use Node.js when I need to. But the problem for me is: I like using Deno. It has many features that made it my go-to. I'd imagine there are other developers who feel similarly. I will be curious to see what, if anything, happens with Deno. I'm not holding my breath. But I'd continue to use it and support it if there was a more open model for maintaining it. While the idea of forking Deno and Fresh and maintaining those sounds kind of fun and exciting at first thought, I don't actually know the internals of either of those projects or Node.js or TypeScript very well. That's not work I want to do, but it's not hard to imagine there may be other companies or people who do want to do that work.
My biggest takeaway from all of this though is clear as a cloudless sunny fall day: avoid venture capital-funded open source.
I'm not much of a business person. But it sure seemed weird to me for Deno, and then Bun, to receive millions of dollars of investment to create open source runtimes, libraries, and tools (and maybe some products too). Open source projects are funded in all sorts of ways, from the corporations who create the projects to the companies that rely on them to the communities that value them. There are pros and cons to the different methods and lots of politics related to it all. But if people and companies rely on open source project, it's pretty likely they'll get maintained to some degree. But venture capital-backed open source projects worry me the most because inherent to the funding mechanism is the pressure to grow, make money, and potentially sell out. Infusing a bunch of cash into a project and needing it to grow seems detrimental to establishing and sustaining a non-trivial open source project for years and decades to come. Products and businesses can definitely spring up around open source projects, but to need to turn one investor dollar into two or more investor dollars as table stakes for the project itself seems like an almost certain way of crashing and burning unless the stars align. While Bun has funding for now, the financial ground of the AI companies sure seems unstable, and it's tough to know what the future of Bun will be as well. Venture capital money does not lead to sustainable open source software.
Maybe there will be more to Deno's story, where the developers and companies who rely on it keep development going. Maybe even Ryan Dahl, the Deno company, and Cloudflare will help that happen in more meaningful ways. Or maybe it's truly the end for Deno once those twelve months of maintenance are up. I'll be curious to see how it all plays out. In the meantime, I'll spend some time porting my more important programs to something more stable.
Thank you for reading! If you found this post helpful and insightful, consider buying me a coffee to support my writing.
Additional Reading & Key Links
- Blog posts about the acquihire
- https://celld.dev/ - the open source project that led to the Cloudflare acquisition
- Reddit thread from mass exodus
- David Bushell's various Deno writings
Footnotes
- Sure, there was a weird split where io.js existed, but then it merged back into Node.js. But that's just a small bit of history at this point.
- https://deno.com/blog/greatly-exaggerated
- a simple Hello World program built with
deno compileis over 100 MB on Linux as of this writing with Deno v2.9 - https://news.ycombinator.com/item?id=50020371
- https://github.com/freshframework/fresh/discussions/3830
点赞
收藏
点踩
分享