So unless someone else picks up development, Deno will no longer be supported.
Cloudflare acquires Deno (deno.com)
964 pointsby ilreb9 hours ago505 comments
theodorejb 9 hours ago
> 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.
simonw 9 hours ago
I don't like how that's in the Deno post but gets no mention in the Cloudflare post. Seems like a pretty important detail!
elcritch 8 hours ago
Definitely negative karma points for Cloudflare.
sysguest 8 hours ago
well I just don't get it -- why?
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
swiftcoder 7 hours ago
> why? unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...why acquire and kill?
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
moistoreos 7 hours ago
Aquihiring also requires the personnel hired to... actually stay with the company....
Unless you dangle HEFTY stock options with incremental maturity dates, nothing is else is keeping them from leaving.
swiftcoder 6 hours ago
> Unless you dangle HEFTY stock options with incremental maturity dates
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
sysguest 6 hours ago
> 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
ptaffs 7 hours ago
If the talent wanted to work at Cloudflair, they'd apply there. Being acquired is a loss of agency and the project you care about is shut down. Several public research papers say retention is hard.
WorldMaker 6 hours ago
Which also leads to considerable questions about if the thing being shut down in the acquirehire was the real purpose and any momentum of the team itself moving to new projects a bonus.
zem 3 hours ago
that just means they might not be actively looking to join cloudflare but are willing to do it if the price is right. nothing wrong with that, it's how employment works for the most part. likewise retention in these cases is typically solved via golden handcuffs, another "the price is right" thing.
saghm 3 hours ago
I assume the logic is something like this:
- 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
rancar2 8 hours ago
I think it’s covered appropriately for the audiences. The two posts are for different audiences and purposes. The Deno post by Ryan is for the Deno audience, which is mention at the top of his writing on the Cloudflare post that is for a broader audience of what this means for the Cloudflare audience:
“For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.”
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.
baobabKoodaa 4 hours ago
There's no need to excuse this behavior. People who write announcements like this are dishonest to their core.
rvz 9 hours ago
I mean we already have a winner (Bun) and it just means that Deno has admitted defeat.
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
binlog 9 hours ago
Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.
kaliqt 8 hours ago
Bun being acquired was not an admission of defeat. They are still actively developing.
binlog 9 hours ago
This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.
kuekacang 9 hours ago
I went all-in with bun. Did I bet wrong?
behnamoh 9 hours ago
Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.
buremba 8 hours ago
Use bun when it's drop in replacement of npm, never use Bun API itself.
simonw 8 hours ago
"we know the extents they go to protect their competitive advantage"
I don't. What do you mean?
user43928 9 hours ago
What did it get you?
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.
nateb2022 8 hours ago
As a former bun user, speed.
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.
btown 4 hours ago
Now I'm fascinated why you've chosen the node/npm ecosystem for something with such high security requirements. Are you doing anything special to deeply pin dependencies, etc.?
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.
nateb2022 4 hours ago
npm has supported min-release-age since Februrary, both that and pinned dependencies are stuff I think everyone should be doing. wrt sensitive environments, I can't say too much about our internal processes but we have an audited private registry among other things. for containers, Iron Bank provides a free and publicly accessible baseline https://p1.dso.mil/iron-bank to build on top of.
zamadatix 8 hours ago
I mean I used to do a lot of things I'm glad I don't have to anymore. I'm not a big fan of doing repetitive work just because I understand how to.
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.
user43928 7 hours ago
I also don't like repetitive work, but I think it can be beneficial to understand how the tools you use work, and bun/Deno seem to abstract much of it away.
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.
KronisLV 7 hours ago
Silly drive by take:
> 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.
8n4vidtmkvmk 6 hours ago
You can and probably should set up your production builds that way but it's not automatic.
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...
user43928 6 hours ago
How would you set that up?
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.
mikeryan 2 hours ago
NX Monorepos work that way. Broadly speaking (and with many exceptions) all packages end up in the root. It “builds” release distributions with the correct package.json files and transpiled js.
It helps keep all your related packages on the same dependencies. It’s hell for react native sometimes though.
user43928 an hour ago
I don't see what you mean.
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.
andrewaylett 37 minutes ago
https://github.com/import-js/eslint-plugin-import/blob/HEAD/...
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.
zamadatix 6 hours ago
One should understand how their tools work but there's no such thing as doing that without understanding things across the abstractions involved and at least a good portion of what happens under them, Deno or not.
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.
threecheese 7 hours ago
As a non-js developer, Bun compiles my ts code to local executables nicely. Allows me to experiment with the new diversity of ts frameworks and distribute the binaries (hobby scope).
galaxyLogic 3 hours ago
I'm using Vercel PKG to compile my JS code to executables "nicely".
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?
Buttons840 8 hours ago
Bun always seemed weird because they decided to build it with Zig. I want Zig to succeed, but it's not stable yet.
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.
croes 8 hours ago
Didn’t they switch to Rust?
kaliqt 8 hours ago
Bun was converted fully into Rust overnight, works fine so far.
neuronexmachina 7 hours ago
As of bun 1.4, it's all rewritten in rust instead of zig: https://bun.com/blog/bun-v1.4
porridgeraisin 8 hours ago
I was really surprised that cloudflare was acquiring deno to be honest, I have written about this here before, Deno was always sort of dead to me due to how little they cared for compat of all kinds (nodejs, CJS, backwards). It was refreshing to see bun care a lot about it (well, now its on a different path in other ways).
Then I read that paragraph, and it made more sense that they're acquihiring + killing.
vazark 8 hours ago
The way i see it, cloudflare acquired celld. Deno was just given a decent burial as part of the package
troupo 8 hours ago
> I was really surprised that cloudflare was acquiring deno to be honest
It's an acquihire. They hired the people behind Deno
porridgeraisin 4 hours ago
galaxyLogic 3 hours ago
And seems they want to compete with Anthropic, by having expertise on JS runtimes? A big feature I think is the ability to produce an executable application and have your AI agent-tools work well with that.
elcritch 8 hours ago
How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.
gritzko 8 hours ago
Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
cscheid 8 hours ago
I lead a project built on Deno; it was not my call, just to be clear. Deno turned out unfortunately to be a miss and we had seen the writing on the wall. FWIW, we're moving to a much bigger Rust core program with node for JS user extensibility. (In other words, I'm not willing to risk using the deno_core crates.)
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.
daveidol 7 hours ago
Can you elaborate on why it was a “miss”?
cscheid 3 hours ago
A few things off the top of my head (we've been on deno since 2022)
- 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
tempest_ 6 hours ago
LLMs writing rust that no one reads will spell doom for all the server side JS stuff in time.
2OEH8eoCRo0 8 hours ago
> So many companies went all-in on Deno in recent years.
They should hire a few devs to develop it then.
coldtea 8 hours ago
>So many companies went all-in on Deno in recent years.
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?
vmg12 8 hours ago
> Do they also do their front-end in Dart?
This is actually a good decision though.
maherbeg 8 hours ago
Slack? I think some of their plugins API was all Deno based for a while.
chaosharmonic 8 hours ago
Netlify and Supabase have also been using them for edge functions.
0x6c6f6c 7 hours ago
Given these two are both comparable to the Cloudflare developer stack that I often think of as alternatives, this makes the decision to let Deno die feel at least a bit more calculated.
chaosharmonic 6 hours ago
I do wonder if it's been shopped around to any of these large-scale users as potential maintainers. Seems in the overall wheelhouse for Supabase in particular.
sysguest 8 hours ago
well Deno was the only player who could have prevented recent npm security disasters:
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
Onavo 7 hours ago
> 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?
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.
locknitpicker 5 hours ago
> 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.
rwz 2 hours ago
They shipped a metric ton of new features in 1.4 and it seems relatively stable enough that it doesn't require too much hot bug fix releases.
CSMastermind 7 hours ago
Like a decade ago I got into a huge fight with a Staff Eng at our company over Dart. I had just been put in charge of the company's architecture and one of the first things I did was migrate everything to TypeScript (which was relatively new at the time). He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).
ZeroCool2u 7 hours ago
It's really a bummer that Dart gets a bad rap, because of its early versions. The recent versions of Dart are a lovely language to work with. Pub is the only package manager I've used that approaches Cargo in quality.
p-e-w 6 hours ago
All TypeScript competitors got out-engineered by Microsoft. It’s a triumph of experience over new ideas.
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).
WorldMaker 6 hours ago
namespaces are the other one, and that's a fun legacy because Typescript had to implement a half dozen module systems in the early days: no modules (jQuery-era globalThis pollution), AMD, UMD, CommonJS, SystemJS, Typescript's own which was proto-ESM inspired but not ESM, then Typescript's realignment with ESM.
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.)
phatskat 6 hours ago
I don't know enough about Angular 2 to know exactly how much of a bad choice that was, but my experience in React has always been "they should have used something else". I vaguely recall our lead backend being unhappy with his decision to do the original admin panel in Angular, but I chalked that up to him not being a frontender.
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.
lenkite 4 hours ago
> He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).
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.
galaxyLogic 3 hours ago
I wonder if TS could evolve into a compiler whose output would use either Deno, Bun or Node? When the exe is compiled it no longer matters what libraries it uses underneath?
michaelsalim 3 hours ago
Where is that stat from?
darepublic 2 hours ago
My dart story. While in college for computer programming our professor telling us if we wanted to get ahead of the curve start learning dart. It was the future
rezonant 2 hours ago
> though picking Angular 2 over React not so much
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.
jamesrr39 7 hours ago
For me Deno has a really nice security posture, the permissions model is just something I haven't seen in from other runtimes (JS or otherwise). There were other nice features (native typescript support, compilation to a standalone binary), but the permissions model was just unique.
flanbiscuit 6 hours ago
Which Node now has:
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.
8n4vidtmkvmk 6 hours ago
I didn't know node got that too but it says right at the start that malicious programs can bypass it. What's the point then?
genxy 5 hours ago
The Docker of JS runtimes. Deno will get picked up by the community. But CF should sponsor it for at least 250k a year.
oofdere 5 hours ago
You can give permissions to Web Workers when starting them in Deno, which afaict Node cannot do.
LunaSea 6 hours ago
The security model has always been a half-baked afterthought. The initial versions were riddled with vulnerabilities .
limagnolia 6 hours ago
But it is Open Source, so if said companies like Deno enough, all they have to do is pay for its continued maintenance and development. This is one major thing that sets Open Source apart from proprietary software.
jchw 6 hours ago
> Do they also do their front-end in Dart?
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.)
fg137 8 hours ago
Exactly why any company that cares about long term maintenance should stick with Node.js except in cases that justify alternative runtime.
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.)
sionisrecur 7 hours ago
As long as the competition forced Node to become better then it's all good.
shimman 6 hours ago
Communities aren't always in competition with one another.
fhn 4 hours ago
Yes they are. If opensource product A does not have better features than competing opensource product B, uses move to the better product A and pretty soon, almost nobody will use product B. Take BSD vs Linux for example. We get "we've migrated to BSD" or "we've migrated to Linux" posts all the time and arguments for one or the other. Is there a winner and loser? Yes. Larger communities, more developers, more corporate sponsors, more contributions, etc. Certainly looks like competition to me.
trio8453 8 hours ago
Asking as a non-JS person - what's the cost and effort to switch?
jayknight 7 hours ago
It probably depends on how much of the deno-specific api is being used, and then how similar that is to whatever you're going to switch to.
redox99 8 hours ago
You can migrate off deno in a single day. It's not a big deal.
hodder 8 hours ago
Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.
matesz 7 hours ago
Exactly that. I am really surprised by the amount of comments with this huge sentiment and doom mongering. These days it’s really not a big deal. Million lines of deno based ts is not a problem because pretty much any functionality provided to deno is available for node as well. You probably can migrate off much of the external deps without much hassle. You can even migrate to different language ecosystem altogether like others have mentioned in comments.
flohofwoe 7 hours ago
> ...pretty much any functionality provided to deno is available for node as well.
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.
mahboi 4 hours ago
This doesn't seem like a big deal. Don't you just npm install whatever you need and then change the import names?
flohofwoe 42 minutes ago
I don't want the install step. That's redundant. Just a .ts script I can run via `deno run bla.ts` and which directly pulls in any dependency it needs from the web.
mahboi 33 minutes ago
I understand the point of this, just saying an existing codebase importing things this way doesn't seem all that hard to convert if you need to get off Deno.
ecares 4 hours ago
this one is actually a bad pattern to avoid.
flohofwoe 44 minutes ago
Only when you have no control over the version you're pulling in, but the semver resolution works as expected. Also we're talking about small standalone 'shell scripts', not 'real projects'. Think 'bla.sh', just with a .ts extension. Deno is really great for such small helper scripts.
michaelmior 3 hours ago
FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.
echelon 7 hours ago
And this is why deno is exiting.
There's no business here anymore.
notnullorvoid 4 hours ago
Node only has experimental permissions support (making it not as good for local scripts), and no WebGPU (though you can import dawn wrapper). Deno desktop is way ahead of anything available for Node.
beanjuiceII 4 hours ago
what other runtime has runtime security features?
anvuong an hour ago
It's one of those things that the technical aspect is simple but the paperwork dehumanizes me. Just a couple more bullshit engineering design documents to generate
hodder 8 hours ago
Honestly migrating back is trivial now. It just isn't that big of a pain.
conartist6 7 hours ago
It's why I usually look more closely at the comments here than at the story for stories like this.
clint 7 hours ago
Seems like an extremely risky thing to do. Luckily they can keep maintaining it and improving it if their business is truly dependent on it.
not-kinsale-joe 7 hours ago
I wonder how much they have financially contributed to Deno.
jimbokun 7 hours ago
At least open source gives them an opportunity for the community to find a way to support it going forward. But I suppose that's just table stakes these days.
jkahrs595 6 hours ago
Anybody who has been bitten by the many issue with Yarn over the years can tell you, just stick with stock tools and deal with it.
ForHackernews 6 hours ago
Radical idea here, but maybe those many companies could _fund_ the development of key components of their infrastructure.
galaxyLogic 3 hours ago
Maybe but only if that gives them a competitive advantage.
christoff12 3 hours ago
Indeed, seems like it should be pretty straightforward.
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?
duskdozer 6 hours ago
I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.
orthoxerox an hour ago
Well, the license Deno is distributed under explicitly warns you (sorry for all caps):
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.
fmbb 8 minutes ago
Node is old I’ll give you that. Dependable is debatable.
moralestapia 9 hours ago
Hmm ... so why would they acquire it to let it die?
yxhuvud 9 hours ago
Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.
corytheboyd 9 hours ago
Competitors use it as their serverless JS runtime, likely as simple as that.
ffsm8 8 hours ago
Isn't that underselling the opportunity?
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
behnamoh 9 hours ago
Kinda feels like a rug pull, similar to Bun.
kaliqt 8 hours ago
Not even close as Bun is still being actively developed, albeit with less fervor.
nchmy 9 hours ago
I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.
sebmellen 9 hours ago
Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.
edf13 9 hours ago
This is the real headline... and more so that it has been hidden away.
giancarlostoro 9 hours ago
Thats really upsetting ngl.
singpolyma3 9 hours ago
Which any existing user can just do?
yoyohello13 8 hours ago
Damn that sucks. I love Deno. It really should have ‘won’ the runtime race. Oh well.
hackerbrother 8 hours ago
Shame- it is my favorite Markdown formatter.
taikon 7 hours ago
Why would they acquire them then shut it down? Is there a reason for that?
arnvald 7 hours ago
Acquihire - they’re acquiring it for the team behind it to eventually develop proprietary software
moistoreos 7 hours ago
> develop proprietary software
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.
scottyah 6 hours ago
Do you really think someone off the street, armed with Opus 5.5 could recreate Deno? Or would you pull Cloudflare people off what they were doing (meaning it's a very inefficient company) to work on this?
At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.
duskdozer 6 hours ago
1. They can gain at least a temporary advantage by using a proprietary version. They'll have the original devs who can continue where they were before.
2. I wouldn't be surprised if we end up with a situation where LLM-based copyright laundering becomes illegal/enforced, but only in favor of large corporations' copyright, in which case they could maintain the advantage
What would they miss out on? A bunch of PRslop? The "open source community" is now dead.
jms703 7 hours ago
acqui-hire
ttul 7 hours ago
Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.
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.
galaxyLogic 3 hours ago
I wonder how easily could you port celld to Node.js?
jauntywundrkind 7 hours ago
Hopefully not to stop celld, the cloudflare Durable Object compatible impl. https://github.com/denoland/celld https://news.ycombinator.com/item?id=49185430
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.
coloneltcb 6 hours ago
read the Cloudflare post, basically the opposite of that: https://blog.cloudflare.com/deno-joins-cloudflare/
benrutter 7 hours ago
Genuine question, is this legal under US anti-monipoly laws?
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?
thayne 7 hours ago
I'm not sure if it is legal or not, but it happens all the time, and nothing is done about it.
IMHO, it shouldn't be allowed.
WorldMaker 6 hours ago
US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.
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.)
Uvix 4 hours ago
California has chosen not to get involved - they threatened to then backed down.
bsimpson 4 hours ago
US v. Paramount separated movie studios from movie theaters.
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.
WorldMaker 3 hours ago
National Amusements wasn't considered an official breach of the Paramount decree because it was "the other around", a theater chain owning a studio rather than a studio owning the theaters. It also got a lot of weird exceptions because National Amusements was entirely private at the time.
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.
scottyah 6 hours ago
Do you think Deno was real competition for Cloudflare, and now that they've merged we don't have alternative options for goods/services that are mostly essential?
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
TSiege 6 hours ago
In what sense did deno compete with cloudflare? It is a niche runtime and cloudflare is a cloud platform
tancop 5 hours ago
Workers against Deno Deploy? And even if you don't count Deno as a whole in the same market as Cloudflare it's still shady as hell. They had plans to buy out a company with the explicit intent to shut down their main product.
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.
kentonv 3 hours ago
> They had plans to buy out a company with the explicit intent to shut down their main product.
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
dml2135 3 hours ago
> but didn't Facebook get in some trouble for purchasing Instagram
They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.
ericfr11 7 hours ago
Interesting. I guess open source is not as dependable as it used to be
heliosAtwork 7 hours ago
The CloudFlare blog concludes with:
"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.
kentonv 6 hours ago
We don't completely know what it will look like yet either, but it will absolutely be open source -- as workerd and celld are both already.
bodge5000 7 hours ago
Funny that with Bun being acquired by Anthropic, if this big bet on AI doesn't work out we'll end up right back where we started; Node. Obviously Deno will still be OSS, Bun would likely end up that way too, but you get the idea
swyx 5 hours ago
but even in that scenario, the node competitors absolutely spurred new energy and innovation in node, as node themselves have acknowledged
pjmlp 6 hours ago
The fate of many forks, while reference implementation keeps chugging along adopting the most relevant features.
etatester 6 hours ago
Deno is decidedly not a fork for Node.
pjmlp 5 hours ago
Did they replace V8? Nope.
etatester 4 hours ago
Is Node a fork of Chrome? They didn't replace V8 either.
pjmlp 2 hours ago
It is Chrome on the backend, so yeah, kind of.
dkersten 6 hours ago
So "Deno" isn't joining Cloudflare, Deno is effectively defunkt and its former team is joining Cloudflare.
vorticalbox 6 hours ago
jsr is moving to cloudflare.
chiffaa 4 hours ago
isn't that fairly irrelevant if Deno dies out? Does anything else use JSR?
herpdyderp 4 hours ago
I tried using JSR for about a week, but the restrictions were so tight I gave up.
vorticalbox 4 hours ago
It’s immutable npm, you can’t unpublish I believe but yeah it’s trick of allowing one to publish typescript packages rather than compiled js only applies to deno.
skybrian 8 minutes ago
JSR packages can run on Node.js, Bun, Cloudflare Workers, etc. The maintainer uploading the package decides which runtimes are supported.
tech234a 6 hours ago
The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.
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.
827a 6 hours ago
As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad". They might reevaluate that in light of things being generally fine and losing their precious handcoded runtime choice.
tech234a 6 hours ago
The vibecoded rewrite led to the deprecation of support for Bun but I believe Deno was already the default. Also Bun had the note “No permission restrictions available. Scripts have full file system and network access.”
stymaar 5 hours ago
> there wasn't a ton of explanation given beyond the general vibe of "ai bad"
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.
swyx 5 hours ago
as a counterpoint, your fears are hypothetical so far - nobody on earth cares as much about bun as the bun team and if it was good enough for them it is probably good enough for 99% of users
inknight 4 hours ago
i think someone who has built their infra on top of bun and have bills to pay care much more about bun stability than the team who get paid by Anthropic to vibecode an entire rewrite to another lang
phoghed 4 hours ago
> someone who has built their infra on top of bun and have bills to pay
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?
its-summertime 5 hours ago
If I remember correctly, Deno was always priority number 1 due to having a permissions system. Bun's removal due to the rewrite had people complaining using Deno as the focus as Deno's development shifted towards being LLM heavy. Node now supporting permissions would likely be the priority now.
tedivm 5 hours ago
There was a ton of criticism beyond "ai bad". A complete rewrite, in a different language, is a brand new project. It doesn't have any where near the hardening as the previous version thousands of deployments. If they had done that exact same thing but without AI people still would have been upset.
locknitpicker 5 hours ago
> As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad".
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.
bambax 4 hours ago
For asynchronous downloading of huge media files, speed should not be a priority?
lavela 4 hours ago
Afaik it's used more for circumventing anti-bot measures and solving challenges than the download handling itself.
toomuchtodo 4 hours ago
This is accurate (maintainer of downstream project that depends on yt-dlp for archiving operations).
antisthenes 4 hours ago
When downloading huge media files, the only speed you're being limited by is your bandwidth.
Everything else is completely negligible.
antalis 2 hours ago
QuickJS works fine for yt-dlp and is way smaller: less than 1 MB vs 34 MB + its many dependencies for Deno.
brundolf 6 hours ago
Oof.
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
BrunoBernardino 5 hours ago
I'm saddened by this, and will now need to plan for some migration work in a couple of production projects. Sigh.
lukan 4 hours ago
So they don't want to buy Deno, they want to buy the team to work on something cloudflare specific.
patcon 4 hours ago
I'd say it's durable object specific. Both team deno and cloudflare (and many others) have been won over by the paradigm. Cloudflare is just the primary implementers of it as a strong example of an actor-based programming model at infra layer, but others have been trying to push it (Rivet, and TerseAI's durable actors, celld)
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
zengid 3 hours ago
i guess bun won
port11 3 hours ago
‘Acquires’ is an interesting word, given they’re hiring people and sunsetting the product. They didn’t buy Deno, they hired the team that built it and that forces them to abandon the project.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
syrusakbary 3 hours ago
I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land.
I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.
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)
hanspagel 3 hours ago
Dumb question: Why do we need many independent Node.js runtimes?
sdcfgy 3 hours ago
Well it keeps all the node developers away from my shit so I'm happy :)
syrusakbary 3 hours ago
I believe it indicates a healthy market and pushes competition and better outcomes for customers.
In this case, Deno pushed Web primitives for Node.js and Bun pushed forward on speed (and helped Node.js work on their numbers better).
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).
galaxyLogic 3 hours ago
We need them so you can pick and choose the one that works best for your current project.
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.
zem 3 hours ago
> now Deno will not be developed further.
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.
syrusakbary 3 hours ago
> consortium of companies invested in using the runtime
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!
saghm 3 hours ago
Maybe in another decade he'll pop up again with a third runtime called something like "Edno" that tries to do things differently than both Node and Deno. There are plenty of permutations of those letters left!
saghm 3 hours ago
From a quick search, it looks like they raised $21 million in funding half a decade ago (after an earlier seed round), so this seems less like a reflection on the nature of open source in general and more just a reflection of this one project. It was set up in a way where development was happening because people were being paid to do it, and this time next year, they won't be. Maybe the community would have come in to try to keep it going if there wasn't any funding, or maybe it would have just stopped seeing any real development, but we can't really say for sure either way.
zem 2 hours ago
the $21M was presumably not just to develop deno but to build a business around it, which is a much harder problem. this feels like more of a bystander effect problem; if as few as three large companies that benefited from deno were willing to form an "openedeno" foundation and assign one full time employee each to it i'm betting that would be enough to at least sustain the project in a usable state, but of course everyone is hoping someone else will do it.
galaxyLogic 3 hours ago
Why Edge of Node.js?
kentonv 3 hours ago
> since it push on semantics that can only be run on Cloudflare infrastructure
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/
syrusakbary 2 hours ago
Thanks for chiming in Kenton.
> 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!
kentonv 2 hours ago
> 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).
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. ;)
tibozaurus 29 minutes ago
Is it the triangle ?
steve_adams_86 an hour ago
I'm so bummed about this. Deno is by far my favourite JS runtime. I could sense this coming for a while now, but I was hopeful and just waiting to see what happened. Here we are. I'm glad I don't need to get off the runtime immediately. Sad we won't see any innovation like we did in the last 8 years or so.
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.
sholladay 7 hours ago
I loved early Deno and am sad to see it die. I invested heavily in the Deno ecosystem because of Ry’s initial vision for it.
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.
the_gipsy 6 hours ago
They basically gave up the day they decided to become npm compatible. That was the day Deno died.
shepherdjerred 6 hours ago
That’s the day I switched to Bun
spankalee 6 hours ago
Yet Bun has Node compatibility.
Dylan16807 4 hours ago
Presumably they like other aspects of Bun, in a world where a clean API is not an option.
tehbeard 3 hours ago
Probably because node imcompat / fresh start wasn't the only key differentiator for them?? Bun also had/has (in context of a leg up over node and similar to deno):
- typescript support - built in linting - built in package manager command - built in transpiler/bundler
carefulfungi 6 hours ago
Bun's adoption rate (because of its NPM compatibility) was the forcing function; not VC funding. Deno could pursue a slow-and-steady better-will-win approach vs. Node until another runtime competitor appeared with a more seamless node integration. In fact, the VC funding is what made the slow-but-steady strategy possible in the first place.
afavour 6 hours ago
Strong disagree. Deno could have been a cheaply run open source project with corporate sponsors and could have pursued the slow and steady approach. There's no reason to feel pressure from competitors unless you want to if you're forging a genuinely new path. "Clean break from Node" was the differentiator. Once they abandoned that the reason for using it went away.
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.
genxy 5 hours ago
I only tangentially followed Deno, but am a proud Deno 1 hoodie-haver!
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.
carefulfungi 4 hours ago
I doubt deno could have funded its development purely from sponsorship. And Deploy generated real revenue (on its OEM/b2b side).
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.
afavour 4 hours ago
I agree that should it need to be profit making then what’s e got makes sense. But hey, Node isn’t a profit making enterprise. Deno could have been the same.
an0malous 4 hours ago
Enshittification is inevitable once a company takes VC funding
coldtea 8 hours ago
"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.
brcmthrowaway 6 hours ago
Brilliant take, this is why I come here. Cut through the "our amazing journey" BS.
atif089 5 hours ago
I'm trying to understand this. Cloudflare wants the people to work on different priorities or cloudflare wants deno to die?
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
conductr 4 hours ago
It’s likely that this could be true but they simply have something else they want the acquihired to work on and feel Deno would be a distraction. At least they’re being honest with it instead of letting development stall and all the ill will that comes with the usual slow death by acquisition
cprecioso 2 hours ago
I'm more thinking of "Deno (the company) lost interest/faith in Deno (the runtime), so they were looking for an out". They like working with runtimes, so Cloudflare is probably a good choice.
I guess this is why so much core staff left suddenly some months ago.
sixdimensional 4 hours ago
So the developer tooling consolidation/acquisitions continue... hmm!
- 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?
simantel 4 hours ago
Shopify bought Remix and Tailwind and hired the maintainer of Preact
letrix 4 hours ago
TanStack next?
wodenokoto 4 hours ago
Didn't we use to say that the startup exit strategy was to sell to Yahoo. I guess now a days it is sell to AI
hirako2000 4 hours ago
- Warp -> OpenAI
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
jatins 3 hours ago
Replit is not acquired by Anthropic
hirako2000 2 hours ago
Good catch, no idea why I thought so. I edited that mistake thanks.
kevinfiol 3 hours ago
Svelte -> Vercel
johnz 2 hours ago
BetterAuth -> Vercel
mahboi 2 hours ago
Scala -> Vertiseit AB this year, I was going to joke about someone acquiring Scala but found out it really happened
GitHub -> Microsoft, or is this too old
raphlinus 32 minutes ago
Dioxus -> Cognition
networked 7 hours ago
RIP, my favorite JavaScript runtime, and thank you. You were too secure for this world.
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.
k9294 7 hours ago
To kill celld and potential competitor early? AFAIK, there is no a single Durable Objects alternative at the moment? It's better that way I guess.
barkerja 7 hours ago
> there is no a single Durable Objects alternative at the moment
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.
ericfr11 7 hours ago
Meaning better that there is no alternative?
Jonovono 6 hours ago
Rivet
elyase 5 hours ago
There is rivet and terse
https://github.com/elyase/awesome-object-storage-native#stat...
nicce 31 minutes ago
Celld seems great, did not even know!
jitl 5 hours ago
From the Cloudflare blog post, this quote from Kenton Varda (head of Workers):
> "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.
LoganDark 3 hours ago
Love the transition from being secure on my machine to being secure on somebody else's machine. This offers additional security by making it impossible for me to move the code anywhere else. Which solves the common security problem of me moving my business anywhere else.
ryanrasti 8 hours ago
A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model into workerd.
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.
OtherShrezzing 8 hours ago
>A lot of the comments are on sunsetting Deno, but the more interesting part is merging the celld model 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.
hunts 6 hours ago
Maybe it’s time to ask AI to rewrite those projects ;)
elyase 5 hours ago
check rivet and terse
https://github.com/elyase/awesome-object-storage-native#stat...
rough-sea 5 hours ago
The plan is to bring the celld model to workerd: run a fleet of workerd instances that use a bucket for coordination and storage. Building on workerd, instead of a separate runtime means our effort isn't split and that APIs are exactly the same in both CF and self-hosted. And of course the deno team will help improve the worker runtime itself.
bennett_dev 9 hours ago
I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively.
Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now.
timdorr 9 hours ago
Investors are a helluva drug
vanviegen 9 hours ago
Meh, those types of large scale migrations are just a very short prompt nowadays.
phaser 8 hours ago
specially deno to bun
mapmeld 8 hours ago
Yeah they just made me migrate my blog to their new cloud platform four months ago.
TIPSIO 8 hours ago
Don’t have a strong opinion on any of this, but it’s actually super normal for anyone who helps run a business to push hard and try to grow it.
Things don’t always shake out as you plan
flohofwoe 8 hours ago
To summarize my feelings: Shit!
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?
ewy1 7 hours ago
if you're not locked to javascript you could use python with pep-723[1] to declare inline dependencies
flohofwoe 7 hours ago
I just migrated that project away from Python to TS :D (cries in corner).
jauntywundrkind 7 hours ago
`zx --install` will give you this. It's quite handy and enjoyable generally for shell scripting in ts/js. https://google.github.io/zx/cli#install
phaser 9 hours ago
I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.
of course i’m only talking about deno, the technology not deno, the cloud service.
weli 9 hours ago
read the blogpost, they are discontinuing deno after 1 year
phaser 8 hours ago
it’s open source. i’m hoping it gets picked up by the community. maybe i’m just too hopeful
its-summertime 7 hours ago
The majority of the last year's development has been via LLM. I don't think anyone is going to want to fork that when they can just tell an LLM to do whatever and get the same result
adobrawy 8 hours ago
The fact that Deno development is being suspended doesn't mean the community can't step in. The Deno runtime is licensed under MIT. Such forks might be impulse to grow even further.
shimman 6 hours ago
People always say this but it's always an extreme mixed bag where most developers/maintainers just move on.
bayindirh an hour ago
Or, we can also speculate that after one year, Cloudflare will create an internal Deno fork and will continue to reap the benefits and improvements.
Again, thanks to the MIT license.
pimterry 9 hours ago
> I’m happy if this means Deno is able to get a second impulse
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.
mzajc 9 hours ago
> I’m happy if this means Deno is able to get a second impulse.
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.
TheRoque 8 hours ago
Damn. Deno is a super old project, in 2018 the Nodejs creator did the talk "things I hate about NodeJS" and introduced Deno. It's 8 years ago now, and clearly even though the project was known by most Node users, it didn't gain any traction at all. I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ? Anyways Node will keep evolving and implement new features, new standards, optimization. I think it's super risky to move to an alternative. In the age of the LLMs, if you wanna get out of Node, you better translate all to native Go or Rust.
kaoD 7 hours ago
8 years is not super old, or even old. It's important to understand software maturity cycles for core components.
yipinwong 7 hours ago
"old" is relative term. Given @TheRogue's account is 4 years old, maybe new to field. If so, it feels "old".
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.
hbn 7 hours ago
If 8 years is "super old" in terms of software, what is Windows? Or Emacs? Or old Fortran software from the 50s in the Voyager software?
yipinwong 6 hours ago
Define "super old" or just "old".
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.
1dom 5 hours ago
In the context of software, I think "how old is old" depends on how web based the software has been over its lifetime.
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.
yipinwong 5 hours ago
ty. I like this over others as it uses the "web" as the basis for relativity.
tosti 2 hours ago
Ancient
bilalq 6 hours ago
> "Working Effectively with Legacy Code" defines legacy code as code without tests thus hard to change it easily or with confidence.
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.
yipinwong 5 hours ago
I aggree thre are many defs. I only used that ex as it's easy to use and understand.
What would you consider legacy? (not trynna fight, just wondering what you consider as one)
bilalq an hour ago
Workloads that either are superseded or there is a desire to supersede them. It's not just old deprecated stuff, but also stuff that people want to deprecate.
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.
TheRoque 7 hours ago
It's not that old, but it's old enough that it should have gained a bit of traction, it should have been mentioned in more discussions etc. And ultimately adopted more. It's purely a gut feeling though because I didn't run any numbers
SenHeng 7 hours ago
It may not be old, but it sure hasn’t caught on much after 8 years. I did remember a lot of posts about migrating cloud functions/lambdas to deno initially, but not much since.
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.
hbn 7 hours ago
Also it didn't hit 1.0 until 2020 so it's more accurate to say it's 6 years old.
goosejuice 7 hours ago
> I don't even remember "the bad parts" that Deno tries to solve, were they that bad at all ?
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.
etatester 6 hours ago
To me Deno died the day it decided to not support npm packages and died again when it started supporting it.
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)
nonethewiser 5 hours ago
Once Deno's direction became clear, success seemed unlikely.
mahboi an hour ago
In what way does supporting npm packages compromise Deno's design? I don't know a lot about Deno but thought it was more about rewriting in Rust, more batteries included like native TS support, and more secure defaults.
akagusu 23 minutes ago
I have 2 questions:
- 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?
pimterry 9 hours ago
The Cloudflare side is also worth a read: https://blog.cloudflare.com/deno-joins-cloudflare/
wewewedxfgdf 6 hours ago
Deno should never have been a business - there's no business model.
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.
duesabati 8 hours ago
Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.
jesse_dot_id 5 hours ago
Whatever allows you to make stuff is good enough.
duesabati 2 hours ago
you are definitely right, thank you for this reminder, it's just that I'm a bit tired of managing trash like NodeJS
tiborsaas 9 hours ago
Congrats on the exit :)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
bsoqk 9 hours ago
And then Danone.
khalidkhair 8 hours ago
This one might have to be spooned
nateb2022 8 hours ago
Sounds like something Bending Spoons would like
Latty 5 hours ago
Oned maybe.
greeniskool 3 hours ago
I wonder how this will affect Bunny's competitor to Cloudflare Workers, Edge Scripting [1] -- which runs on Deno.
wg0 8 hours ago
This might not be seen in much favourable light by many but IMO Cloudflare has the most elegant serveless PaaS as I have seen to date.
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.
AznHisoka 8 hours ago
I think the biggest thing Cloudflare needs to buy is some sort of Postgres-database service. They've already cornered the market for everything front-end/serverless
shados 8 hours ago
D1 is their bet there but considering hyperdrive, a real Postgres would be cool.
I also wish they expanded jurisdiction more. I worked at companies that couldn't use Cloudflare because of specific location requirements in contracts
CuriouslyC 8 hours ago
D1 is a very different product. D1 is designed to be tenant sharded for any real workloads.
If they bought Neon that'd be a coup.
mj4e an hour ago
PlanetScale might be more likely as Neon was bought by Databricks.
eknkc 8 hours ago
Yeah. D1 is nice and easy but a serverless postgres offering would make a significant difference.
HatchedLake721 7 hours ago
Planetscale?
bilalq 5 hours ago
Cloudflare could make the biggest impact by doing something similar to AWS DSQL. There are very few options in the multi-region replicated space, and it ties in nicely with their edge workers.
stillpointlab 5 hours ago
I'm very sad Deno is going away, even though I've never used it nor did I plan to use it.
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?
255kb 2 hours ago
It seems VC money is not really compatible with open source
mahboi 2 hours ago
Maybe they all learned their lesson from Docker giving away the entire product for free
multisport 9 hours ago
I'm very surprised they are not running with the runtime. That seemed like Deno's secret sauce? The rest of it is very aligned with Cloudflare already, deploy, kv, workers, etc seems like the lower hanging fruit.
DannyBee 7 hours ago
It's almost certainly not worth it. Having less software that you can keep more reliable is almost always worth it over having more software just because it's 10% faster or whatever. This isn't always true but it's mostly true.
chrysoprace 2 hours ago
It's very sad. I was excited about Deno from day one, and I wanted to see it succeed.
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.
herrherrmann 2 hours ago
It would certainly be nice if someone continued the work. But I wouldn’t hold my breath for it. Seems like an unthankful job (although I’m sure many projects using Demo now would be happy if it’s still supported, at least).
huqedato 8 hours ago
RIP Deno. Goes into the bin, after Bun.
po1nt 8 hours ago
I was rooting for Deno so much as I was fighting with node for years. Luckily I made full transition from JS last year and not comming back.
adamddev1 8 hours ago
What did you transition to?
schnebbau 7 hours ago
AI.