Cloudflare acquires Deno
deno.com
deno.com
So unless someone else picks up development, Deno will no longer be supported.
unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...
...why acquire and kill? cloudflare can have more outreach and reputation by keeping deno alive
Aquihiring is a time-tested strategy to build out a team. The Deno folks likely have a bunch of experience that Cloudflare is well placed to make use of
Unless you dangle HEFTY stock options with incremental maturity dates, nothing is else is keeping them from leaving.
That is indeed how this whole thing works. I used to work with several folks who were kicking around FAANG for 4 years till their acquisition stock fully vested
When you consider how much time/money it takes to hire an experienced engineer, and how quickly they are liable to jump to the competition, acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal
well... why not tie who's already inside the company (who you actually know about) instead of an external people (who you DON't know about)?
it's much difficult to get info about some external person, and most info is about external reputation ('the looks')
though... that's the reason job-ping-pongs work: someone outside looks better than someone inside, because of your lack of info
- We want to do more work on our runtime and need people to do it
- Those developers for that company over are there working on another runtime
- Buying that company allows them to come work for us without any potential issues from investors in that other company
FWIW both Ryan and Kenton are very transparent in person, in public, and online over their professional careers. They will and do openly change their minds based on new information and opportunities as time goes along. Both are now founders of open source projects acquired by Cloudflare for the technical architecture talents seeing a future that they would like to build.
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
I don't. What do you mean?
For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.
So I never had much interest in looking into benefits of Deno or bun.
However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.
Finding the right balance of "being responsive to bugfixes, some of which may patch disclosed zero-days" and "not allowing a compromised package to be installed" is tough, these days.
edit: Sweet! seems to be all intact!! Thanks!!
Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.
Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.
What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.
For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.
However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.
> I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.
If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.
It also gets messy if you're building 2 or 3 services simultaneously out of the same node_modules dir. E.g frontend, backend, shared, scripts...
Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.
One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.
It would be far from a standard solution though.
It helps keep all your related packages on the same dependencies. It’s hell for react native sometimes though.
With nx you define the dependencies between your tasks, so that the packages build in the right order and with caching.
I do not think it changes anything about how packages are installed by the package manager or bundled by the bundler.
You can declare build tools in either the root package.json or packages/a/package.json, and I don't think anything prevents you from bundling something declared in devDependencies.
On second thought, I see now that you probably mean it helps keep shared dependencies at the same version when you declare them in the root package.json.
That's a feature of npm/pnpm/yarn workspaces though, not nx itself. And it only works with bundled dependencies, since they would be undeclared in the package itself and thus couldn't be installed externally. If you need that, I think pnpm catalogs would be the right tool.
It's not built in to ESLint, but it's fairly widely used in my experience and helps ensure that you've got a sensible split between production and non-production.
It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.
* Or, in the absence of well-written documentation, the source code, the decompiled object code, or at the very least inspect the end result.
But PKG is not supported by anyone any more (?) and it has an upper limit on the version of Node.js base-image it will support.
If Bun supports compiling executables nicely I hope that feature somehow stays alive and is migrated to other runtimes. Or maybe it can become a standalone tool for exe-compiling?
I don't mean that in a "social proof" kind of way. Popularity brings it own advantages. Because lots of people use something, you get the advantages of lots of other people using it:
a larger ecosystem, more libraries, easier to find new team mates, easier to find people willing to learn, better and more answers on Stack Overflow (or in LLMs now, I guess), etc., etc.
And there's just no compiled languages more used and known than JavaScript/TypeScript. Java and C# come closest, but they're still far off and still require runtimes.
All compiled languages require runtimes, the only difference is how big they are, and JavaScript runtimes are not among the smallest ones.
Hmmm, no ?
It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.
It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
It's an acquihire. They hired the people behind Deno
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.
- They originally bet on being a TypeScript dialect that didn't quite match the expectations of node in a few small places that ended up mattering hugely.
- One of the original value propositions was "deno compile" and "deno bundle", and those never actually worked well enough to be robust for our real-world use cases (early on they didn't support TLA, then dynamic imports didn't work, then they had issues with ARM compilation)
- Then they simultaneously tried to support node syntax out of the box with npm import specifiers _and_ create a new javascript registry (jsr.io)
- At the point where we expected them to actually make their base-level ecosystem robust, they pivoted to edge compute, and then the writing was on the wall
Server side compiled languages were working perfectly fine, but we had to have this scripting languages, performance doesn't matter 2010's vibe.
Only for all to realise 15 years later that performance actually matters when paying the electricity bill.
JS running on a raspberrypi can support most sites on the internet.
Sure it matters at scale but what tech interviews forget is most don't every get to the scale where it matters.
A 2015 machine with duel xeons can run many many small tech companies stacks.
They should hire a few devs to develop it then.
Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?
Do they also do their front-end in Dart?
This is actually a good decision though.
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
Wait till you hear about this thing called Bun.
Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.
Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.
Nonsense. They paused releases to get the rewrite out, and following the rewrite it was rather obvious they lost the ability to release production-grade software.
It would have been trivial to release patch versions with little cleanup work, but evidently the project isn't even able to put that together.
You guys should stop to hear yourselves talking about these vibecoded projects. How come they can simultaneously do major rewrites but be completely useless at refactoring and maintaining their own code?
How well designed the initial versions of TypeScript were can be seen by how smoothly later versions were able to build on them, and even after so many major improvements the language has barely a wart (enums probably being the only one).
Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)
For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.
1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.
Earlier metric in late 2024 shows 28%
If he had some experience he'd seen dozens of technologies that were "the future" being thrown away to the dustbin, not even getting any real adoption.
It sounds like you're coming at this from a perspective of popularity and thus access to engineering candidates with expertise in it which is fair, but speaking as someone who also went with Angular 2 over React during those times, I'm still using Angular and I'm very happy with it from a technical perspective. Yes, it does mean there are less options for hiring, but it has been a positive experience for my team and for me in my own projects to stick with it.
https://nodejs.org/api/permissions.html - since v20 - Apr 17, 2023
https://nodejs.org/learn/typescript/run-natively - stable and without a flag since v22.18.0 - which sometime after Apr 24, 2024 which was the v22.0.0 release
https://nodejs.org/api/single-executable-applications.html - Added in: v19.7.0, v18.16.0 but still in Active Development (not stable yet) - 2022
For reference, Deno was released in 2020 with all of these features from the start.
Feels like it always take some healthy competition for Node to make big strides like this. Like the whole io.js fork thing a long while ago.
Hey, you jest, but Flutter has a lot of traction!
(I conceptually like Flutter, but I can't get over the Dart thing, so I'm not part of that traction.)
I wouldn't be surprised if Bun is abandoned at some point as well.
(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)
Getting “funded” is to get a job maintaining the project. Great! This happens to incredibly few, high-profile projects. Those people wouldn’t be working on the alternative if they didn’t get paid to work on the one they care about.
In the context of Deno here, it obviously implies market share.
However that doesn’t mean it’s a good idea to use them, it is not
I wish it were otherwise but I don't think anyone running a hype-driven project of dubious utility needs to worry too much, humans are not rational creatures
Which is forever in the tech industry.
Unfortunately Node still can't do something like this out of the box (AFAIK at least):
import { Bla } from "npm:bla@^5";
Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.
It's a different mental model I'd say. Specifically: First, I add the part to the pile, then I wire it up.
I wouldn't call it redundant to explicitly spell out what actually happens. If anything, I'd call it good to remind people that they are adding something into their scope of responsibility.
Fix't it for ya.
You can, but you won't. Let's be real for a second now - the only reason you use this feature is because you can't be bothered to use a real package manager that pins versions.
Okay. Now I'm confused and my head hurts. You want to randomly download dependencies for a "shell script" at the time of invocation?
I think I need to lie down.
Nobody says Deno is not better overall than Node. It clearly is, across the board. And nobody cares.
If Deno would provide actual improvements people would care about then for sure it would survive. The problem is that it didn’t. It was just fun project and creators learned a lot for sure. And entire js ecosystem improved thanks to Deno’s push.
I wouldn't want a shell script to have side effects aside from its desired function.
On top of that, I wouldn't want a shell script that is being used for some task to have a runtime dependency on Internet connectivity, a registry being up, and/or the chance that a version of a dependency that is used is dependent upon when the artifact was first run.
But you replied to a comment that said "for simple standalone tooling scripts in otherwise non-JS/TS projects" where this absolutely is not a bad pattern.
There's no business here anymore.
You can't just switch over to nodejs
Deno has tons of browser APIs, e.g. Deno.serve uses the standard Request and Response objects. That's not platform lock in.
I understand why the venture-backed entity couldn't do this, but given the reactions here, could a new maintainer not take over and simply charge for support and future enterprise features like the Sidekiq guy?
If only those that boast online how X is greater than Y in every single thread, actually paid even a Starbucks coffee to X.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
To jest, businesses can be successful without sustainability. Instagram definitely was.
In the space of such foundational technologies, there’s always been a vast gap between the number of private vs open-source projects that succeed. Even all the way back to proprietary compilers 40-50 years ago.
If they had stuck to being an open-source project, the kind of adoption and mindshare they achieved would have put them among the most successful ever. And I am sure they would have been able get their team paid very well sustainably. The unicorn model cannot fit every single venture.
Some day devs will learn FOSS projects don't survive on good will alone.
But the VC path pushed them to increase costs more than they should. They didn’t need that money to deliver on the mandate of Deno, they had to inflate the vision to some grand cloud solution, which didn’t make much sense.
> then it is a failure as company
Perhaps it shouldn’t be a company at all. Private companies cannot attract the same support as open-source foundations do, since they are for-profit organizations.
Foundations are companies in disguise, with taxes benefits, and there isn't one without industry partners.
Which programming language survives with support contracts, no company sponsorship, and has mainstream adoption?
Of COURSE there are industry partners. That’s not a bad thing!
Ultimately, it was easier for the Node ecosystem to adopt those changes into Node than it was to migrate to a different JS runtime like Deno. Bun would likely not exist without Deno too.
https://esdiscuss.org/topic/a-reprieve-for-es6-comprehension...
But then again considering there's no barrier for entry to develop runtimes now, I guess these companies are just going to develop their own.
Congratulations to the Deno employees.
It appears that they are well on thier way to supporting all possible runtimes.
I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.
Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.
No one who has tried ruff, uv and ty would agree with that.
Nor go back to any of the previous alternatives Astral's products replaced. (With the possible exception of ty since that's still pretty new)
this is so much bullshit I don't even.
even if they thought that could actually work : it could not unless by "great engineers" you mean "resume-pad masters".
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
This is a weird strategy to stake future IP value on in the age of AI. With competent and fully qualified team, anyone should be able to reverse engineer this idea and build a roadmap for their own implementation. Especially in the world of open source.
At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.
What would they miss out on? A bunch of PRslop? The "open source community" is now dead.
Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.
What we will probably see in the next few months is a major version of `workerd` which is a rebranded celld with better Cloudflare support. And then a bunch of improvements in further versions. While I think `celld` is a nicer name it makes sense to keep the official Cloudflare product/solution as `workerd`.
I hope the developer experience gets closer to Deno, I'm no fan of setting up all the required Node tooling for proper TypeScript support. I really like Deno. RIP
Phrased as it being merged into the existing, but I can't help but fret a bit. Is cloudflare willing to let their own core compute product be something available to the world? Absolutely sick wins if so. But I worry celld pretty reasonably seen as a threat.
workerd is really far from production-ready Workers replacement, and seems to be very specifically scoped in such a way that essential parts of why Cloudflare dares to run it are not included in the bundle.
My best guess is you're talking about sandboxing, specifically how we defend ourselves against malicious tenants. Indeed, a lot of how we defend against that is not in workerd, and fundamentally can't be, because it's more than just some code, it's a process requiring active management.
However, you only need that if you have untrusted tenants.
If you are using workerd to self-host your own applications on non-Cloudflare infrastructure, then this isn't a concern for you. You don't have untrusted tenants.
If you are hosting untrusted tenants, then you can put workerd in a micro VM, the same as you'd do with any other popular runtime.
My best guess is that you are suggesting that we should open source our multi-tenant hosting technology, along with workerd.
But this doesn't make sense. No popular JavaScript runtime includes multi-tenant hosting technology. Multi-tenant hosting is the responsibility of the hosting provider. workerd is compatible with other providers' multi-tenant hosting approaches. You do not need our specific technology in order to run Workers apps on other hosting providers, and in fact would not even be particularly useful for that purpose.
(But I admittedly have not actually asked Ryan if he had long-term plans to add a multi-tenant scheduler so maybe I'm wrong.)
I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.
Surely buying a company out only to close their main offering is defined as anti-competitive?
IMHO, it shouldn't be allowed.
But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.
(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)
(There might be something the state of California could do, but I don't know how much they want to get involved.)
Sumner Redstone came from a movie theater family and formed modern Paramount by buying Viacom (which was spun out of CBS due to antitrust), Paramount, and then later CBS itself. He was able to buy Paramount as a cinema owner because the government abandoned the rule that you couldn't own both the studio and the theater in the 80s.
The corporate history of Hollywood is long and complicated. Skydance is obviously a big topic this month, but Paramount was owned by the Redstone family's National Amusements theater for as long as many of the adults on this site have been alive.
But the current issue is right now streaming services dwarf theaters today. The Paramount decree was officially suspended by this administration and its courts on this matter stating it isn't a monopolistic oversight for studios to own and entirely control their streaming services (despite doing the exact same things with "originals" and "exclusives" that led to the original Paramount decree). This administration and its courts not only said the current streaming situation is fine, but that it also means the original Paramount decree no longer applies and studios may own theater chains again, because theaters now compete with streaming.
Skydance having both Paramount+ and HBO Max gives them a huge amount of leverage in the streaming space that is going to get stranger with this consolidation, and gets back to why that 200+ years of combined film history is important and relevant.
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.
What they pulled off instead is the most toxic form of acqui hire ever invented.
I understand why it looks that way, and we knew it would be hard to combat this perception.
But it's simply not true.
The actual story is simply this: The Deno team made a strategic decision to refocus on celld, and we (Cloudflare) are excited to support this work, for the reasons I explained in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
See Ryan's own comment here: https://news.ycombinator.com/item?id=50023277
They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.
I'm very bullish on AI, but vibe-porting the piece of software you're the main maintainer over a few weeks without letting anyone in the community know and pushing that as a fait accompli to both your userbase and your open source community is definitely the kind of behavior that makes you not trustworthy enough to depend on.
they were stupid to do this in the first place. bun has always been a one man show. what were their plans for when he got hit by a bus?
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
Bun's release cadence dropped because they had just ported to a new language and they weren't about to release that to their community without letting it settle in for a couple of months first - which they did, by running it in Claude Code on millions of computers.
Nonsense. If that was remotely true we would have seen a wealth of maintenance releases immediately following the rewrite, along with feature work.
However, development completely stalled, even though they can throw ungodly amounts of AI compute at the problem.
Don't you notice an incongruence in your remarks?
(If it had stalled for a year then yeah, you'd have a point. I've seen projects stall for a year or more due to a rewrite.)
+------------+--------------+
| Week of | Main commits |
+------------+--------------+
| 2026-04-13 | 88 |
| 2026-04-20 | 95 |
| 2026-04-27 | 200 |
| 2026-05-04 | 25 |
| 2026-05-11 | 50 |
| 2026-05-18 | 148 |
| 2026-05-25 | 77 |
| 2026-06-01 | 70 |
| 2026-06-08 | 37 |
| 2026-06-15 | 60 |
| 2026-06-22 | 153 |
| 2026-06-29 | 102 |
| 2026-07-06 | 137 |
| 2026-07-13 | 213 |
| 2026-07-20 | 210 |
| 2026-07-27 | 185 |
| 2026-08-03 | 164 |
| 2026-08-10 | 316 |
| 2026-08-17 | 284 |
| 2026-08-24 | 196 |
| 2026-08-31 | 157 |
| 2026-09-07 | 119 |
| 2026-09-14 | 154 |
| 2026-09-21 | 123 |
| 2026-09-28 | 68 |
| 2026-10-05 | 21 |
+------------+--------------+
| Total | 3,452 |
+------------+--------------+
I think it takes quite severe motivated reasoning to look at a project that ported from one language to another and shipped to millions of end users without incident (Claude Code users didn't even realize they were running the new version) and conclude it was a "fiasco".
The fiasco was that a lot of people were unhappy about it. I'd be interested in seeing a Venn diagram of people who complained about the Bun rewrite and people who don't like AI-assisted programming. I suspect the overlap is heavy.
If I had built my own project on Bun specifically because it used Zed, and had my own custom Zed extensions, I would be justifiably angry that the project ditched Zed without any community input at all.
If that's your complaint than I think it's credible.
You know you're putting up bullshit metrics, not much different than counting lines of code touched by commits.
If you were forthcoming and showed relevant metrics such as release cadence (i.e., what projects declare to be relevant units of work to be delivered to their userbase) you'd be faced with the realization that since march (bun v1.13.14) Bun only managed to put together 4 meager releases:
* Bun v1.14.0 - Aug 20 (first release in 5 whopping months?)
* Bun v1.14.1 - Sep 4
* Bun v1.14.2 - Sep 5 (emergency regression fix)
* Bun v1.14.3 - Oct 10 (just a few hours ago)
This means in the last half year, following the rewrite the project barely managed to put together 3 patch releases. In semver terms this means no feature work, mind you.
Is this what you call productive.
There were a ton of new features in 1.14.0 - most of the release notes were about new features, the Rust thing was a side note: https://bun.com/blog/bun-v1.4
> It adds Bun.Image, Bun.WebView, Bun.markdown, Bun.cron(), Bun.Terminal, bun run --parallel, bun test --parallel, bun audit fix, bun dedupe, and bun prune. And it rewrites Bun from Zig to Rust.
I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.
Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.
I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.
One potentially useful way to measure that is to use Bun's TypeScript API definitions as a proxy for "features".
We can look at when those landed on main (which should make them available in a canary release) and when they landed on an actual release.
Here's a table that counts features in that way:
Month Main Released
----------- ---- -----------------
2025-01 20 24 (1.1.43-1.2.2)
2025-02 5 5 (1.2.3-4)
2025-03 11 14 (1.2.5-8)
2025-04 15 15 (1.2.9-11)
2025-05 19 8 (1.2.12-15)
2025-06 5 15 (1.2.16-17)
2025-07 5 3 (1.2.18-19)
2025-08 21 20 (1.2.20-21)
2025-09 14 24 (1.2.22-23)
2025-10 1 1 (1.3.0-1)
2025-11 6 7 (1.3.2-3)
2025-12 (A) 17 14 (1.3.4-5)
2026-01 13 16 (1.3.6-8)
2026-02 2 1 (1.3.9-10)
2026-03 9 9 (1.3.11)
2026-04 4 2 (1.3.12-13)
2026-05 (R) 9 5 (1.3.14)
2026-06 7 0 (none)
2026-07 9 0 (none)
2026-08 13 29 (1.4.0)
2026-09 9 6 (1.4.1-2)
2026-10 * 5 11 (1.4.3)
Pre-acq 11.1 12.4
Post-acq 9.0 8.4
Rust 9.4 8.0
Everything else is completely negligible.
yt-dlp executes code from the website to get the exact download URLs and header values. The websites obfuscate these to prevent downloading. Running arbitrary 3rd party code in Node or Bun might work, but is risky, especially when that code could potentially come from one of the many ads on that video website.
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
RIP Deno
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
This have a similar analogy with browsers. Back then when Internet Explorer was the only supported browser, the websites were not evolving as fast. When Firefox pushed it forward and then Chrome, customers won (better and faster sites).
But that points to an important aspect of the platforms-game: The interface between the runtime and everything else should be standardized, to support true pick-and-choose.
Just saying don't throw out the Common-JS sub-system with the bathwater.
The problem with ES6 modules (imo) is it does not support sync loading of dynamic imports, so you have to figure out how to handle the Promise.
that's an interesting reflection on the nature of open source - in theory the source is there and "the community" could conceivably continue development. especially in the case of something like deno where the people most motivated to keep it alive are already programmers. but the reality is that however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.
hopefully that single entity can be a consortium of companies invested in using the runtime, sort of like opentofu recently.
I believe this is very unlikely to happen. If the founder (Ryan) was involved in it or it have strong market position, it would have strong chances.
Now, is a kingdom without a king and without strong companies to steward it forward. I hope to be wrong though!
No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).
Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.
This was emphasized in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
> workerd and its semantics are not exclusive to Cloudflare infrastructure
I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).
All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.
> I really wish I was allowed to say who because one of the users is hilariously ironic
Ok, this peaked my curiosity. Would be great if you could share it!
Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.
In fact, celld has already done a lot of this.
> Ok, this peaked my curiosity. Would be great if you could share it!
You'll have to find me in person over drinks somehow. ;)
That's great to hear.
> You'll have to find me in person over drinks somehow. ;)
Challenge accepted!
Hiring an entire team that works well together is a big accelerant compared to finding and hiring the right individuals and trying to form that team.
See also Ryan Dahl's comment here: https://news.ycombinator.com/item?id=50019911#50023277
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?
Isn't that what FLOSS is all about?
But I stopped because I saw this coming the moment they changed course and started putting npm compatibility as a priority. Deno’s surface area went from beautifully simple to very bloated. I think they felt the pressure of VC funding and just gave up on rebuilding Node from first principles.
The silver lining is that early Deno was so good that Node copied some of its features. So at least we have a better Node now.
- typescript support - built in linting - built in package manager command - built in transpiler/bundler
Once it become “a drop-in for Node”, I decided why would I not use the more popular drop-in for Node that has a bunch of other interesting features.
Bun also had far better compatibility with many libraries & native dependencies
The moment they took on VC funding they had to care about competitors and also had to move away from the framework to things like Deno Deploy in pursuit of money.
A compatibility shim sounds like a great community run project while the core team could work on the slow-but-steady w/o concerning the core with too much burden of node compat.
Deno is now a feedstock for future JS runtimes.
Jt is interesting to speculate on what might have been had Deno never been a profit-seeking company. But having worked there, I am reasonably confident in my assessment above.
I hope workerd at least adopts Deno's security mechanisms so it functions as a better sandbox.
One of my favourite projects of 2026 was a configurable LLM harness built around using deno as the runtime. The idea is that the configuration builds a state machine-driven program which is bundled into a binary that can only provide access to the I/O your code explicitly needs. I used it primarily to build interactive programs for colleagues which allow some LLM magic to occur without needing to worry about what they would do with Claude Desktop handling the same data or accessing the same machines and so on. It also allowed for testing local LLMs in deterministic patterns. How do they reason about what to do next when they can evaluate the possible states they can enter, based on the current context? It was really fun. Now I don't really know how I'd rebuild it, knowing I wouldn't use Deno. Maybe that's worth learning anyway.
In the case of the latter, I'm wondering why. Most of cloudflares architecture like workers support js runtimes so wouldnt investment into deno be more strategic than other priorities
I guess this is why so much core staff left suddenly some months ago.
Sounds reasonable to me, and I wish him and his team the best as they continue to develop celld/workerd.
What kind of business move is this for Cloudflare? celld is a more complete Cloudflare-at-home runtime than current workerd. What does Cloudflare stand to gain from commodizing Workers?
I'll say that although I'm not really a Cloudflare Workers user, I've been eyeing workerd and celld with interest. The idea of a complete backend in a box appeals to me (see also: PocketBase, Algernon). At the same time, the acquisition means that another company won't acquire Deno for celld.
If you live in Elixir land, there's this repo from the Phoenix team, which is quite good. It has pluggable storage, and EKV (https://github.com/chrismccord/ekv) is supported as "batteries include" type storage adapter.
But again, it's very far from being a simple serverless micro server that scales infinitely and is super easy to use.
https://github.com/elyase/awesome-object-storage-native#stat...
> "Lock-in" actually hurts us — that's why we went open source If there were truly no escape hatch from Workers, then some of our largest customers would never have signed on with us in the first place.
> [...]
> 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. This will involve merging code and ideas from celld back into workerd. I'm incredibly excited for this work — I will personally be using it to host an instance of Cloudflare OS in my home.
- Cursor -> SpaceX
- Astral/uv -> OpenAI
- Stainless -> Anthropic
- Bun -> Anthropic
- Astro.js -> Cloudflare
- Deno -> Cloudflare
- VoidZero (Vite, etc.) -> Cloudflare
- NuxtLabs -> Vercel
- Hugging Face -> NVIDIA
- ... what else?
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
GitHub -> Microsoft, or is this too old
I've been following celld since it was announced. Bootstrapping both durability and coordination off object storage simplifies so many things for self-hosting. (Yes, ironic that self-hosting has a cloud dependency, but in this case I think justified because S3 has become a widely supported protocol that you can run yourself too).
Will be curious to see the details on exactly how that model makes it into workerd.
I think people are focusing on it because if you've built your business on Deno, then the "Deno will have no support in 13 months time" is a bit of an existential risk, and will be a huge time-sink for your team. So it's far more interesting to most of the people reading this page on HN, because HN is full of people who are first-adopters.
https://github.com/elyase/awesome-object-storage-native#stat...
Things don’t always shake out as you plan
And worse for Deno - nodejs may not be great but it's good enough.
And may you never have an incumbent competitor that is is "good enough" - it will be your downfall.
Deno's ability to import directly from a package registry or even git repo in a standalone TS script without requiring a package.json or similar 'meta-data' file was actually really nice for shell scripting stuff. AFAIK node.js still can't do anything similar?
mise use uv
uv install
of course i’m only talking about deno, the technology not deno, the cloud service.
vs
Download, prompt, test, prompt, wait because of 5 hour limit, prompt, test, run
Again, thanks to the MIT license.
Bad news, sorry, the article says:
> 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.
Sounds like Celld will live on within workerd, Deno is over.
From TFA: 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.
https://x.com/deno_land/status/2108543358197207048 (https://archive.is/H4GLt)
I understand your sentiment of justifying not being "old". but you gotta bring up "legacy code".
"Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
So either @TheGuardian is discussing about the age of software relative to his/her perspective or confused "legacy code" without understanding deno code base.
It's relative measurement. When you are 9th grader, even a freshman college student feels way older.
But as you are in your 30s, you feel less of difference.
Same thing here, How do you define Windows and Emacs being "old"? For those who's been using it for decades, not as old as Voyager software. For those who lived through those times, Windows and Emacs feels younger.
See where I am going with it?
---
If you have a nephew or a kid, they will say you are "old". But your parents will consider you "young" for the rest of their lives.
I think 8 years is old for software that has heavily Web based like Deno. But Windows and Emacs have had portions of their lifetime without the Web in a meaningful way, so 8 years would be young.
This is not a universally accepted definition. I've owned plenty of services with 95%+ unit test coverage, massive integ test suites, and synthetic canary tests that ran every minute that I would consider legacy. Plenty of AI slop today gets barfed out with 100% test coverage, but much of it is legacy from day 1.
What would you consider legacy? (not trynna fight, just wondering what you consider as one)
An example could be old API endpoints only hit by old versions of a mobile app where users may be slow to update. Or a case where only newer clients/instances support modern features and old ones are stuck on a frozen featureset until they cutover.
But active services with no immediately existant alternative may also be legacy. If your auth is behind a disappointing managed service like AWS Cognito, you may consider your entire auth stack legacy while the replacement is still looming in the roadmap down the line. Maybe you can't justify funding to work on a transition just yet, but you already would avoid building on top of the existing tech stack.
I’m taking the stance that no news is bad news here. If it was good, people would be doing Resume Driven Dev with deno and we would be buried in those articles. Alas.
Well node and bun sought to solve the same problems after Deno demonstrated a path. They got to learn from Deno's mistakes as well.
You can also see that JS developers don't really care about any of this stuff by reading the comments here, people don't even mention this and mention native typescript support like it is such a important thing to have for a significantly large/long-running project.
Ironically the reason why I hated it when it was introduced was the reason why they added support for npm (i.e. absolute URLs don't support semver and therefore you will load multiple versions)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
I also wish they expanded jurisdiction more. I worked at companies that couldn't use Cloudflare because of specific location requirements in contracts
If they bought Neon that'd be a coup.
No indication cloudflare would pursue that yet that I see.
[0] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno... [1] https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno...
I feel bad for anyone that now relies on Deno. And as good as Cloudflare might be for some things, I also feel bad for anyone relying on them.
It is a bit hypocritical in a sense. Similar to how I was sad that a local restaurant recently closed down. In the past two years I went there maybe three times total. But I just liked having it there as an option.
Deno had a ton of good ideas but I just never felt confident that it would have the lasting power. Some of the early decisions, like their initial refusal to fully support package.json and the npm eco-system, made me unsure of their suitability as the basis for a business.
But I always wanted them to succeed. In the same way I always wanted Heroku to succeed even though I never used their service.
More options are better. But I guess "use it or lose it" applies. Did I dodge a bullet or contribute to the downfall?
I had to evaluate Deno vs. Bun vs. Node for a project two years ago, and chose Node. I think Deno has good ideas but often times these projects cannot reach escape velocity, especially when they're constrained by VC motives.
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
They took on VC funding.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
It sure looks like they saw Bun eat their lunch and decided there was no reason to keep competing.
Not going with `node_modules` might be just as big a mistake for Ryan Dahl as introducing it originally.
The design and architecture is extremely minimal to the point that all of it can be explained on a single A4 page with a 14pt font including D1 + Durable objects. And I hope that it stays that way.
It has all the primitives that you can wish for to build a software system on top of it be it queues, long running jobs, workflows, pipelines, email handlers, cron jobs and even built in AI models ready for you to be invoked.
ATM - it is extremely cheap, reliable, simpler and more capable than anything out there. Deno itself had very little scope anyway because almost no developer tooling is sellable in this environment even more so post AI. Therefore, it is going to accelerate the Cloudflare platform to be the best in class and hopefully not complex and bloated.
Edit: Yes, but it's not named after me, which this fork fixes.
It's going to be the first JavaScript runtime to natively support Super Intelligence APIs.
I'm having an LLM replacing all occurrences of "ai" in every API with "si", in the hopes that OpenSI or SpaceXSI will acquihire me.
I know Node is boring but it's not going anywhere.
Also Deno was starting to try to increase revenue with stuff like Deno Deploy. If Deno did succeed, they would be a direct competitor with Cloudflare Workers
With Bun I think it was basically a marketing ploy. To show that it can be developed by AI and still useful
I don't know, the vast majority of daily Microsoft Defender offenders I have to wade through, as well as the majority of the intune remidy requests are related to Node being used in various Microsoft applications. The Azure CLI is one of them, but the one which really ranks high on the security risk levels is always something "Agent" or "AI" related folder which I assume are what runs the Copilot and Cowork clients.
I think I had around 800 CVE warnings in relations to Axios in side a Microsoft tool related to AI running node this week, from just 8 devices.
Bun having it's own batteries included is probably a nice benefit to avoid that.
https://blog.cloudflare.com/deno-joins-cloudflare/
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
Most of us are here because we’re curious what it means for Deno specifically and FOSS TypeScript runtimes in general, since Bun was also acquired.
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.
I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are
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. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
I disagree that there's little differentiation between Node and Deno these days. Sure, I love Deno's UX and tooling, but the security benefits Deno has over Node are still the number one reason, we're picking Deno over Node at work. I'm honestly sad we may have to reconsider and switch.
I understand you are working on a new model for server development and I'll take a look at celld for sure. But what about scripts? I have a couple hundred repositories all using Deno for a wide range of scripting tasks. I'd love to continue using Deno for scripting for another 8 years or longer.
I'm just feeling a bit sad, you know. It kinda feels like I'm gonna lose a friend. That happy little dinosaur, now standing in the pouring rain again...
The DX of Deno far surpasses Node (or at least it did, idk if Node has caught up in that regard).
What are the big problems you see that still need solving that a future Deno (fork) could handle?
EDIT: Talking to people in the Discord and was reminded that the community may have been the inspiration. Adoption was low so boom, add Node compatibility and now adoption grows. MEH.
If I'm doing a fork, I'm removing Node.
Looking back now after almost 20 years (Nov 2009 to now for me), I can see the arc from what node was then to what celld can be now as your thinking has evolved
A distributed operating system running in userspace is the primitive that can break apart the siloing that has become the default across the walled gardens we all operate in
All the best in what's to come
I remember early into my first programming job as an intern in 2017 someone shared a very similar looking series of sketches intended to explain git with cats. I didn't understand it at the time, and then years later when I was much more comfortable with git I took a look at it again and the explanations make just as little sense to me now as it did then.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
I guess the positive is that at least Deno pushed Node.js to evolve.
So, obviously it was a blog post about business strategy and not technical architecture. Maybe that's disappointing when people expect me to talk tech.
But I sort of thought the direct argument for open source and against lock-in as a business strategy would please the technical audience.
My role hasn't changed. I have always been simultaneously writing code, designing technical architecture, and also influencing product/business strategy. This particular piece of strategy is one I advocated and won support for, which is why I wrote the post.
Deno's ability to run TypeScript files - stripping types - was arguably implemented in Node because of Deno. The consolidated tooling approach was a good attempt at solving tooling fragmentation that Node suffers from.
I think for Deno to succeed, it would've had to have been under a non-profit and maybe that can still happen.
Deno Deploy offering would have never be profitable because it contradicted the very core of the Deno's technology promise: absence of lock-in and freedom to self-host.
> The Deno team is joining Cloudflare to radically simplify self-hosting Workers and Durable Objects so developers can use the same primitives in more places.
Well, that's pretty big news actually.
It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].
And when you can't manage to coordinate with an ecosystem dependency as large as webpack before the migration to make sure nothing breaks... my suspicion is utter incompetence and gross misuse of AI.
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
Deno was never going to be a thing anyways.
Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.
Every company that is using Bun is getting so much more perf benefits — faster and less memory used; also less crashes/bugs. New features are dropping rapidly. All those naysayers about rust port will be littered with bugs and unmaintainable crap are already proven wrong. So now you just call it dead. nice.
The amount of new features they are coming up with, the speed of development has been even faster than before.
We have not seen any indications so far Anthropic messing with Bun's direction. It was always Jarred deciding what to do and it is still the same. So far Anthropic has left Bun alone and they are just reaping benefits of bun getting faster and faster.
I see that as a long term benefit. Not a negative.
For example it doesn't support enums.
Bun and Deno do the real thing.
Deno from my understanding included a version of the TypeScript compiler as part of its build. Node doesn't do this. I'm not sure what Bun does, but I wouldn't trust it for anything more than a hobby project.
That's by design. Deno smoothly hides the fact that TS needs to be converted to JS for V8 to run it. Similar to how it smoothly hides everything about npm.
If you want to use TS stripping for your own project the typescript ecosystem makes it very easy to avoid using the wrong features. Just set erasableSyntaxOnly and verbatimModuleSyntax to true in your tsconfig.json and you will be warned when you're doing something node would not be able to handle. These days I find more code is being written to be stripping friendly than not, the incompatible stuff is of little importance besides enum for which you could resort to an as const object or a string union. I consider the presence of such things a smell, the TS dev team considers things like enums to have been a mistake, the goal of TS is to remain minimally divergent with JS outside of the type annotations.
Don't know what Bun does though.
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
I also believe, like others here, that Bun future is also not safe, Anthropic might decide to kill it as soon as they believe it doesn't bring in any more value.
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.
Also worth calling out that if you want to disrupt a major player, you need to be 10x better, not just 2x.
Either way, congrats team. Hope you going on to build something great at Cloudflare.
I'll probably move to Rust for scripting I reckon. It's not very mature but hopefully it won't be too much longer.
Fresh was also the best web framework I've used. Oh well.
So what's the story with JSR sticking around then? Does it already see meaningful use among people using Workers, or do they just really want an escape hatch in case we see more long-term issues with GitHub and NPM?
And does it at least mean the stdlib will see continued development?
I liked its scoring system for packages and "make the Typescript docs a public part of the package page" and "focus entirely on ESM-first/ESM-only packages". None of that npm does today, so JSR is still the best way I know to find modern and up-to-date/clean packages versus npm just has a nasty swamp of things still in CommonJS for no reason or that will never get upgraded out of CommonJS because the original maintainers are long gone.
With cloudflare being a cloud company I am pretty sure that building native desktop apps is not exactly their highest priority.
I think I'll have to look at options again.
Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.
Edge Functions are built on the Deno runtime today, but importantly, we operate our own infrastructure and don't depend on Deno's hosted services. While Deno is winding down active development over the next year, the Deno team has committed to contributing bug and security fixes until then. And we'll continue our work with the Deno team to incorporate critical improvements to the Edge Function runtime during this transition.
Our next-generation offering, Compute (https://supabase.com/compute), is already in an advanced stage of development and will support Deno as well as other runtimes like Node.js and Bun. We'll provide a seamless migration path from Edge Functions to Compute. Our goal is to make Compute available for new workloads and existing Edge Functions well before Deno's support window closes.
Existing Edge Functions will continue to be supported, and there's no need to migrate today, and no need to stop writing them. Longer term, Compute will give you more flexibility in choosing your runtime, and we expect it to become the recommended path for new workloads.
We don't have a public timeline to share yet, but we'll provide updates as soon as we do.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
My point is, even if Bun stayed on Zig, Deno still struggled to compete regardless of the language used.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
They don't even need to be the long term stewards either. Spend some time setting up a proper governance structure for Deno, hand it off, and then pay some maintainers to continue their existing effort.
At least how it's stated in the post, it really feels like an "ah good luck everyone, I'm out!" sorta deal, which seriously sucks for everyone who really believed in Deno.
CF workerd is only one out of those 5.
Extremely disappointing...
I know it's been done for years and reflects so basic a misunderstanding I have about the ecosystem.
Also, if your goal is to commercialize, why open source at all anymore vs have a free tier and ecosystem?
You corrupt the hearts of core maintainers with truckloads of cash, then get them to stop working on it (and instead on something else) and to effectively kill the brand.
Of course the code is free for anyone to pick up & work on, but setting up new infra & finding new people is costly in both time and money.
create a plan to implement a javascript runtime similar to {deno,bun,node.js,whatever} in {Rust,C++,ASM,Go,Fortran} language, use subagents @ max effort, keep building until you're done, follow instructions according to INSTRUCTIONS.md
Wait a day and you're done.
(I've trademarked ENDO , feel free to DM me for a license)
I've been using deno for years and built some nontrivial services in it. When deno added support for npm packages, the early days were pretty rough. I ran into lots of issues with packages and spent a lot of time reading random github issue threads. It's been pretty smooth sailing for the last year or so though.
At least I can use ai to help migrate off of deno.
i always wondered how they were making money
Given it's server focus though, I'd be very surprised if it was as good as Deno for giving agents a local code sandbox.
Also another blog post from when the feature became generally available: https://blog.cloudflare.com/dynamic-workers/
I agree it would be an awkward choice for an agent that runs as a local application, but the trend I think is towards agents running more and more on servers.
Especially with LLMs automating all sorts of code and operational aspects, we could do Tcl/Lua type whitelist sandboxes where the application can only call a limited set of functions.
I think they ran out of money and joining Cloudflare was their only remaining option.
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
Whom did they work for before?
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
I doubt it will be the last time.
I took the plunge and ripped out all my (“open source”) Magento shopfronts and reimplemented them from the ground in…… 2 hours. And it is so much more performant to boot.
Just this morning I checked the Deno blog (again like so often in recent weeks) to see if they are still alive. The number of mentions in Hacker News posts and comments was zero in recent weeks. The project was basically dead or abandoned already. Sucks, because I went all-in on Deno.
For me, the entire thing that made me want to use Deno was it was a clean-sheet rewrite that was aiming to overcome the negatives of node and npm. It was a breath of fresh air. Yet overtime they basically ended up just trying to replicate node. Such a shame.
Still, I like cloudflare's offerings so I'm very interested to see what they come up with after work on worded/celld
Its no longer gonna be supported after 1 year
In that case Deno is not joining cloudflare, it's got eaten.
I invested a lot and use deno everywhere. Can't trust anything these days.
Lets fork it into opendeno. I like to have an all-in-one swiss army knife tool.
Uh no. The lack of users killed Deno.
One of them should fork if it's cheaper than migrating because a lot of Deno code is not portable.
I know the runtime is in trouble, but i'm not as worried tbh b/c the principles deno championed are going to keep going.
- there are companies offering serverless functions on their platforms, powered by Deno Deploy. Can this acquisition be an attempt to kill competition?
- Cloudflare now owns a huge chunck of JavaScript ecosystem, like Vercel. They are buying like countries that are arming themselves for war. What is the strategy here?
Of course, that's not to say the work done on these platforms was wasted. The divide around io.js was meaningful to getting things moving faster and change the governance structure. Deno and bun both showcased things Node could be doing better and some of that was folded back in.
And in spite of all those past experiences, I still find myself using pnpm over npm today. I'm sure npm will continue to evolve and eventually the critical features of pnpm will just be part of core npm. But the gap today is massive enough that pnpm over npm feels critical. The disk usage and performance wins are life-changing for daily work and CI flows.