Rendered at 22:17:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
theodorejb 1 days 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.
So unless someone else picks up development, Deno will no longer be supported.
binlog 1 days 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.
coke12 22 hours ago [-]
If it was truly “so many companies” then they wouldn’t be in this situation… reading between the lines here it’s clear Deno was not a successful project.
oersted 21 hours ago [-]
It might not have been a successful project as a VC growth startup, but lots of people saw that coming here in HN when they started raising millions.
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.
pjmlp 17 hours ago [-]
If they cannot pay bills, because no one pays upstream, then it is a failure as company, regardless of VC growth.
Some day devs will learn FOSS projects don't survive on good will alone.
oersted 17 hours ago [-]
An open-source project with their success could have easily paid their bills through sponsorships and support contracts, as many others do.
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.
pjmlp 17 hours ago [-]
No they don't, they survive like street performers, some days the hat is full enough for a warm meal.
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?
sailfast 9 hours ago [-]
Was going to suggest Python but that doesn’t pass your “foundations don’t count” logic (that I don’t really agree with)
Of COURSE there are industry partners. That’s not a bad thing!
sokoloff 9 hours ago [-]
C? c++?
locknitpicker 13 hours ago [-]
> An open-source project with their success could have easily paid their bills through sponsorships and support contracts, as many others do.
I have great news for you, then. You are free to pick up the project for free and rake in all that free sponsorship cash.
Do you think this is a reasonable investment of your time?
pseudosavant 4 hours ago [-]
It was successful for the Node community, but not for Deno the runtime or business. Deno launched with many features Node didn't have, but that it has now adopted: ES Modules, fetch(), .ts file support, web streams, web crypto, a built-in test runner, file watching, etc. Node's APIs didn't even use Promises/async/await, they were all callback-based.
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.
makeitdouble 21 hours ago [-]
Being successful or not depends on the scale of the company. I'd wager at Cloudflare scale, many otherwise decent businesses would have virtually no effect on their baseline and wouldn't be worth running.
pjmlp 16 hours ago [-]
Regardless of the size, being successful means, is there enough money in the bank at the end of each month.
makeitdouble 16 hours ago [-]
You're defining being sustainable. IMHO "successful" is a lot more relative and defined by expectations.
To jest, businesses can be successful without sustainability. Instagram definitely was.
pjmlp 15 hours ago [-]
If being successful means pumping an idea for acquisition.
wongarsu 12 hours ago [-]
Or if being successful means building something billions of people use on a regular basis
lstodd 7 hours ago [-]
like, idk, nginx?
Andrex 8 hours ago [-]
Reminds me of Gatsby.
fg137 1 days 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 1 days ago [-]
As long as the competition forced Node to become better then it's all good.
ifwinterco 14 hours ago [-]
Yeah this is it, Bun, Deno etc are 100% good for JS/TS in the aggregate because they push Node.js and npm to actually improve.
However that doesn’t mean it’s a good idea to use them, it is not
Andrex 8 hours ago [-]
But if that becomes common wisdom and nobody ends up using such new projects going forward out of such fears, how will they get the momentum to meaningfully affect change on Node? This worked out with Bun and Deno but not sure about the future.
ifwinterco 6 hours ago [-]
There are always hype train/resume driven development developers (in fact, there's way too many).
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
shimman 1 days ago [-]
Communities aren't always in competition with one another.
fhn 1 days 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.
simonask 22 hours ago [-]
That’s because you’ve been brainwashed by capitalism. The alternative getting less attention might have fewer resources, but there is nothing to “win” here.
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.
ksec 22 hours ago [-]
>but there is nothing to “win” here.
In the context of Deno here, it obviously implies market share.
simonask 5 hours ago [-]
There's no "market" to have a "share" of.
jppope 21 hours ago [-]
It wasn't that long ago that Nodejs was the new kid on the block, and companies were worried it would go under.
fg137 10 hours ago [-]
If my timeline is correct, that was over a decade ago.
Which is forever in the tech industry.
Andrex 8 hours ago [-]
Even longer I'd say. Node was the new kid on the block when I was in college 2010-2011. By 2016 it was entrenched.
cowlevel 20 hours ago [-]
Or they could pay for their dependencies.
redox99 1 days ago [-]
You can migrate off deno in a single day. It's not a big deal.
matesz 1 days 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 1 days 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";
Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.
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 1 days 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 1 days 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.
hypfer 12 hours ago [-]
Is it?
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.
mahboi 5 hours ago [-]
There are use cases like small scripts where people just want a single js file. So the top of that file basically functions as the package.json.
mahboi 1 days 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.
otabdeveloper4 6 hours ago [-]
> and which directly pulls in any dependency and exploit
Fix't it for ya.
sroussey 1 days ago [-]
Bun has auto-install for you, but you do have to enable it.
brlewis 21 hours ago [-]
Deno's is slicker. Deno's built-in LSP works with the automatically installed package's types.
cowlevel 20 hours ago [-]
Well, nobody is supporting that any more. So you either support it yourself or stop using it.
mahboi 15 hours ago [-]
That wasn't the question though
ecares 1 days ago [-]
this one is actually a bad pattern to avoid.
flohofwoe 1 days 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.
insaneirish 21 hours ago [-]
> 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.
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.
flohofwoe 16 hours ago [-]
Please explain what exactly is the problem with installing dependencies on demand compared to an 'npm install -g bla', 'brew install bla' or 'apt install bla'? It requires exactly the same amount of trust and is the the same thing under the hood, just that it happens automatically on first invocation of a script.
matesz 9 hours ago [-]
Then put shell function to your globals which will mimic install + run. It’s literally like 5 minutes of work max and you’ve spent way more arguing over it already.
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.
brlewis 6 hours ago [-]
If we were talking in the context of large TypeScript projects, you would be right. Central management helps the project avoid adding too many dependencies.
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.
michaelmior 1 days ago [-]
FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.
brazukadev 23 hours ago [-]
Bun is not an alternative, it was also acquihired and will probably become an internal project of Anthropic for claude code.
nimchimpsky 1 days ago [-]
[dead]
notnullorvoid 1 days 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.
anvuong 1 days 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
beanjuiceII 1 days ago [-]
what other runtime has runtime security features?
hodder 1 days ago [-]
Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.
echelon 1 days ago [-]
And this is why deno is exiting.
There's no business here anymore.
hoppp 22 hours ago [-]
Not really. Tons of platform lock in Apis, Deno.serve, KV etc..
You can't just switch over to nodejs
brlewis 18 hours ago [-]
I don't use KV, but I doubt it's hard to migrate to another key-value store.
Deno has tons of browser APIs, e.g. Deno.serve uses the standard Request and Response objects. That's not platform lock in.
hoppp 11 hours ago [-]
It requires a rewrite and to migrate production systems away from it. Its not a small task.
iririxjrifk 21 hours ago [-]
[dead]
Abishek_Muthian 17 hours ago [-]
Doesn't supabase edge functions run on Deno? I presume this is huge setback for companies like that and their users.
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.
albuic 9 hours ago [-]
There is no barrier for entry to develop runtimes but there is one for maintaining it. Let's not forger that cost.
consumer451 9 hours ago [-]
I was wondering about Supabase as well.
It appears that they are well on thier way to supporting all possible runtimes.
I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.
plazma 16 hours ago [-]
Whoever did it, decision maker was reckless and should his job should be reassessed. This is not surprise, similar will happen to Bun as well, just matter of time.
Xenoamorphous 16 hours ago [-]
Those reckless decision makers are also responsible for Node’s popularity.
Aeolun 15 hours ago [-]
Only after Anthropic rebuilds Claude in Rust.
kuekacang 1 days ago [-]
I went all-in with bun. Did I bet wrong?
user43928 1 days 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 1 days 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 1 days 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 1 days 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.
mech422 20 hours ago [-]
I thought iron bank got shutdown...Be cool if its still running! goes to look
edit: Sweet! seems to be all intact!! Thanks!!
threecheese 1 days 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 1 days 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?
pjmlp 16 hours ago [-]
That being the case, why not use a compiled language in first place?
lucumo 14 hours ago [-]
One of my software engineering maxims is that popularity is a feature.
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.
pjmlp 13 hours ago [-]
JavaScript is partially compiled, given the limitations of using JIT compilers in dynamic languages, and Typescript is basically a linter.
All compiled languages require runtimes, the only difference is how big they are, and JavaScript runtimes are not among the smallest ones.
lucumo 9 hours ago [-]
Then what was the point of asking why they used JS over "a compiled language"?
albuic 9 hours ago [-]
> compiled languages require runtimes
Hmmm, no ?
giveaccountpls 4 hours ago [-]
Python is compiled (fun fact: it has stronger typing than c++). Java is also compiled, so is C#. All of them require a runtime. Your comment is silly.
13 hours ago [-]
zamadatix 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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'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.
mikeryan 1 days 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 1 days 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.
confidantlake 20 hours ago [-]
On most projects you really only need one person to set it up one time with any deep level of understanding. Having each person on a project go deep into the weeds on how the package manager works is not very useful. That time would be better spend on almost anything else.
zamadatix 1 days 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.
jasomill 23 hours ago [-]
This is why I'm not overly concerned about AI taking our jobs. Those who do not RTFM* are doomed to rewrite it in blood, toil, tears, and sweat.
* Or, in the absence of well-written documentation, the source code, the decompiled object code, or at the very least inspect the end result.
behnamoh 1 days ago [-]
Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.
simonw 1 days ago [-]
"we know the extents they go to protect their competitive advantage"
I don't. What do you mean?
buremba 1 days ago [-]
Use bun when it's drop in replacement of npm, never use Bun API itself.
pjmlp 17 hours ago [-]
Like any other late stage capitalism corporation, curve must go up exponentially, otherwise shareholders will be depressed.
886424808632 7 hours ago [-]
[dead]
Buttons840 1 days 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.
Bun was converted fully into Rust overnight, works fine so far.
croes 1 days ago [-]
Didn’t they switch to Rust?
1 days ago [-]
fmbb 1 days ago [-]
Node is old I’ll give you that. Dependable is debatable.
elcritch 1 days 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.
cscheid 1 days 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 1 days ago [-]
Can you elaborate on why it was a “miss”?
cscheid 1 days 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_ 1 days ago [-]
LLMs writing rust that no one reads will spell doom for all the server side JS stuff in time.
pjmlp 16 hours ago [-]
Hopefully, it should never had left the browser.
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.
tempest_ 10 hours ago [-]
It still doenst really matter for most people.
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.
airstrike 19 hours ago [-]
Curious what the GUI part of the stack looks like if you don't mind sharing
gritzko 1 days 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.
ale 11 hours ago [-]
Node was once the shiny new thing, so that argument is irrelevant. Deno got a lot of traction by promising to fix Node’s issues, some people trusted that promise, and Deno just didn’t deliver.
not-kinsale-joe 1 days ago [-]
I wonder how much they have financially contributed to Deno.
miki123211 12 hours ago [-]
Deno always felt like a "people pot", the kind of company whose sole (but unstated) purpose is to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company who can actually utilize them. The actual product was secondary at best.
Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.
senko 8 hours ago [-]
> Astral [...] The actual product was secondary at best.
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)
lstodd 7 hours ago [-]
> to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company
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".
imdsm 12 hours ago [-]
Surely they could fork it and just continue it OSS?
trio8453 1 days ago [-]
Asking as a non-JS person - what's the cost and effort to switch?
jayknight 1 days 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.
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.
ForHackernews 1 days ago [-]
Radical idea here, but maybe those many companies could _fund_ the development of key components of their infrastructure.
pjmlp 16 hours ago [-]
Developers as well, all other professionals pay for their tools.
If only those that boast online how X is greater than Y in every single thread, actually paid even a Starbucks coffee to X.
christoff12 1 days 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?
galaxyLogic 1 days ago [-]
Maybe but only if that gives them a competitive advantage.
jasomill 23 hours ago [-]
There's no reason companies can't fund mutually beneficial entities. In fact, it's quite common in the form of trade associations.
conartist6 1 days ago [-]
It's why I usually look more closely at the comments here than at the story for stories like this.
porridgeraisin 1 days 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 1 days ago [-]
The way i see it, cloudflare acquired celld. Deno was just given a decent burial as part of the package
troupo 1 days ago [-]
> I was really surprised that cloudflare was acquiring deno to be honest
It's an acquihire. They hired the people behind Deno
galaxyLogic 1 days 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.
>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?
jamesrr39 1 days 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.
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.
oofdere 1 days ago [-]
You can give permissions to Web Workers when starting them in Deno, which afaict Node cannot do.
8n4vidtmkvmk 1 days 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 1 days 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.
LunaSea 1 days ago [-]
The security model has always been a half-baked afterthought. The initial versions were riddled with vulnerabilities .
CSMastermind 1 days 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).
phatskat 1 days 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.
rezonant 1 days 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.
ZeroCool2u 1 days 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 1 days 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 1 days 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.)
darepublic 1 days 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
lenkite 1 days 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 1 days 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 1 days ago [-]
Where is that stat from?
sysguest 1 days 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
limagnolia 1 days 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 1 days 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.)
maherbeg 1 days ago [-]
Slack? I think some of their plugins API was all Deno based for a while.
chaosharmonic 1 days ago [-]
Netlify and Supabase have also been using them for edge functions.
0x6c6f6c 1 days 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 1 days 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.
To be extra clear, Netlify no longer uses Deno's managed infrastructure, but still uses the Deno runtime. (Source: I work at Netlify.)
chaosharmonic 8 hours ago [-]
Did they have any heads up about this, and/or do they have any roadmap for what's happening now?
vmg12 1 days ago [-]
> Do they also do their front-end in Dart?
This is actually a good decision though.
Onavo 1 days 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 1 days 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 1 days 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.
locknitpicker 13 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.
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?
hokumguru 22 hours ago [-]
I mean, if you have any test suite worth a damn, then this should only cost a few dollars in tokens for the average team and be nothing more than a minor inconvenience.
fithisux 13 hours ago [-]
They can fork it.
hodder 1 days ago [-]
Honestly migrating back is trivial now. It just isn't that big of a pain.
2OEH8eoCRo0 1 days ago [-]
> So many companies went all-in on Deno in recent years.
They should hire a few devs to develop it then.
clint 1 days 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.
locknitpicker 13 hours ago [-]
> So many companies went all-in on Deno in recent years.
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.
jkahrs595 1 days 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.
phatskat 23 hours ago [-]
I dunno, we've been using pnpm for years now without issue, and it's been faster and a little more secure to boot!
orthoxerox 1 days 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.
tech234a 1 days 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.
For asynchronous downloading of huge media files, speed should not be a priority?
lavela 1 days ago [-]
Afaik it's used more for circumventing anti-bot measures and solving challenges than the download handling itself.
bambax 13 hours ago [-]
Yes, that's what I meant; if the download is going to take minutes, then a fem milliseconds spent doing the challenge don't matter much?
nickitolas 11 hours ago [-]
I believe the parent comment is saying the js runtime doesnt affect the speed of downloads, thats all c/c++/rust code
toomuchtodo 1 days ago [-]
This is accurate (maintainer of downstream project that depends on yt-dlp for archiving operations).
antisthenes 1 days ago [-]
When downloading huge media files, the only speed you're being limited by is your bandwidth.
Everything else is completely negligible.
mvdtnz 20 hours ago [-]
What makes Deno more suitable for this than any other runtime? It's just executing JS code right? I wouldn't think this would leave any meaningful fingerprint.
geggo98 17 hours ago [-]
Sanboxing makes it more suitable.
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.
827a 1 days 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.
stymaar 1 days 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 1 days 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 1 days 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 1 days 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?
topato 23 hours ago [-]
I totally thought the other guy had you in the argument, and your retort blew my mind. An excellent point, people really need to research their runtimes before placing the entirety of your infra on them.
Then again, I suppose that’s partially the reasoning for the existence of support contracts.
I’m just going to add this here, but: was this whole thing just an aquihire? The dude is a badass, so I can see buying deno just to get him… skillset matches the areas cloadflare has roadmapped out, but still needs to shore up (a lot)
genxy 1 days ago [-]
[flagged]
1 days ago [-]
tech234a 1 days 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.”
its-summertime 1 days 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 1 days 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 1 days 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.
simonw 24 hours ago [-]
I don't think that's a good interpretation of what happened.
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.
locknitpicker 13 hours ago [-]
> (...) they had just ported to a new language and they weren't about to release that to their community without letting it settle (...)
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?
simonw 8 hours ago [-]
Development stalled? Here are the stats on commits to Bun in the past six months:
(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.)
For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.
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.
simonw 8 hours ago [-]
Actually, to be fair, the real fiasco was project governance.
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.
locknitpicker 4 hours ago [-]
> Development stalled? Here are the stats on commits to Bun in the past six months
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.
Considering one of those releases was a full rewrite to a new language yes, I do consider that 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.
dkersten 1 days ago [-]
So "Deno" isn't joining Cloudflare, Deno is effectively defunkt and its former team is joining Cloudflare.
vorticalbox 1 days ago [-]
jsr is moving to cloudflare.
chiffaa 1 days ago [-]
isn't that fairly irrelevant if Deno dies out? Does anything else use JSR?
herpdyderp 1 days ago [-]
I tried using JSR for about a week, but the restrictions were so tight I gave up.
skybrian 1 days ago [-]
JSR packages can run on Node.js, Bun, Cloudflare Workers, etc. The maintainer uploading the package decides which runtimes are supported.
chiffaa 13 hours ago [-]
Ah, fair enough, makes the whole situation a bit more lame
vorticalbox 1 days 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.
port11 1 days 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.)
simonw 1 days 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!
rancar2 1 days 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 1 days ago [-]
There's no need to excuse this behavior. People who write announcements like this are dishonest to their core.
elcritch 1 days ago [-]
Definitely negative karma points for Cloudflare.
sysguest 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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 1 days 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
brundolf 1 days 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
syrusakbary 1 days 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)
> 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.
> 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 1 days 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. ;)
syrusakbary 21 hours ago [-]
> the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure
That's great to hear.
> You'll have to find me in person over drinks somehow. ;)
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.
saghm 1 days 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 1 days 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.
jflatow 2 hours ago [-]
I think it could be done by just 1 reasonably large company
zem 1 hours ago [-]
it could, but then they would need to be willing to put at least three people on it, and the project itself would be subject to the political currents in that company. having several companies involved is more stable. (anecdotally several good open source projects at google died in their first big wave of layoffs)
syrusakbary 1 days 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 1 days 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!
hanspagel 1 days ago [-]
Dumb question: Why do we need many independent Node.js runtimes?
galaxyLogic 1 days 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.
syrusakbary 1 days 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).
sdcfgy 1 days ago [-]
Well it keeps all the node developers away from my shit so I'm happy :)
galaxyLogic 1 days ago [-]
Why Edge of Node.js?
lukan 1 days ago [-]
So they don't want to buy Deno, they want to buy the team to work on something cloudflare specific.
patcon 1 days 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
taikon 1 days ago [-]
Why would they acquire them then shut it down? Is there a reason for that?
ttul 1 days 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 1 days ago [-]
I wonder how easily could you port celld to Node.js?
arnvald 1 days ago [-]
Acquihire - they’re acquiring it for the team behind it to eventually develop proprietary software
moistoreos 1 days 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.
duskdozer 1 days 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.
scottyah 1 days 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.
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.
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 1 days ago [-]
but even in that scenario, the node competitors absolutely spurred new energy and innovation in node, as node themselves have acknowledged
edf13 1 days ago [-]
This is the real headline... and more so that it has been hidden away.
heliosAtwork 1 days 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 1 days 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.
LoveMortuus 9 hours ago [-]
Why would they buy something just to potentially kill it?
pjmlp 1 days ago [-]
The fate of many forks, while reference implementation keeps chugging along adopting the most relevant features.
etatester 1 days ago [-]
Deno is decidedly not a fork for Node.
pjmlp 1 days ago [-]
Did they replace V8? Nope.
etatester 1 days ago [-]
Is Node a fork of Chrome? They didn't replace V8 either.
pjmlp 1 days ago [-]
It is Chrome on the backend, so yeah, kind of.
dyzone 6 hours ago [-]
Why is cloudflare even buying deno in that case? Is it an acquihire?
donatj 24 hours ago [-]
What is in this for Cloudflare? Just the employees? I can't imagine hiring these days is that hard that it's worth creating this much ill will.
cowlevel 20 hours ago [-]
This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.
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?
krzyk 7 hours ago [-]
So why cloudflare buys them? Just to do the MS thing?
benrutter 1 days 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?
WorldMaker 1 days 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.)
bsimpson 1 days 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 1 days 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.
Uvix 1 days ago [-]
California has chosen not to get involved - they threatened to then backed down.
thayne 1 days 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.
scottyah 1 days 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).
dml2135 1 days 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.
TSiege 1 days ago [-]
In what sense did deno compete with cloudflare? It is a niche runtime and cloudflare is a cloud platform
tancop 1 days 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 1 days 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/
It's good for everyone but the community, unless I'm looking at it wrong
simonw 21 hours ago [-]
Yeah, the only losers here are people who have a heavy investment in Deno for their own projects :/
1 days ago [-]
nchmy 1 days ago [-]
I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.
ericfr11 1 days ago [-]
Interesting. I guess open source is not as dependable as it used to be
moralestapia 1 days ago [-]
Hmm ... so why would they acquire it to let it die?
yxhuvud 1 days ago [-]
Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.
corytheboyd 1 days ago [-]
Competitors use it as their serverless JS runtime, likely as simple as that.
ffsm8 1 days ago [-]
Isn't that underselling the opportunity?
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
1 days ago [-]
noduerme 22 hours ago [-]
This is exactly what I was wondering.
sebmellen 1 days 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.
koolala 18 hours ago [-]
Why buy it then? The staff?
zengid 1 days ago [-]
i guess bun won
locknitpicker 13 hours ago [-]
> So unless someone else picks up development, Deno will no longer be supported.
Isn't that what FLOSS is all about?
BrunoBernardino 1 days ago [-]
I'm saddened by this, and will now need to plan for some migration work in a couple of production projects. Sigh.
hackerbrother 1 days ago [-]
Shame- it is my favorite Markdown formatter.
white_dragon88 1 days ago [-]
[dead]
cjonas 1 days ago [-]
[flagged]
niek_pas 1 days ago [-]
The word 'skitzo' is pretty offensive to people who actually suffer from schizophrenia, maybe try 'unhinged' or 'bizarre' or something.
tommica 1 days ago [-]
[flagged]
Forgeties79 1 days ago [-]
[flagged]
k33n 1 days ago [-]
[flagged]
tommica 1 days ago [-]
[flagged]
k33n 1 days ago [-]
[flagged]
williamdclt 1 days ago [-]
[flagged]
pylotlight 1 days ago [-]
[flagged]
Forgeties79 1 days ago [-]
[flagged]
diroussel 1 days ago [-]
Anthropic bought bun.sh
diroussel 1 days ago [-]
Interestingly, Jared Sumner of bun fame is the anthropic guy who pushed claud to find this new limit in the Rieman hypothesis.
1 days ago [-]
MeetingsBrowser 1 days ago [-]
Anthropic acquired bun
FrostKiwi 1 days ago [-]
That was bun, not deno
1 days ago [-]
1 days ago [-]
1 days ago [-]
1 days ago [-]
rvz 1 days 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 1 days ago [-]
Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.
kaliqt 1 days ago [-]
Bun being acquired was not an admission of defeat. They are still actively developing.
pylotlight 1 days ago [-]
[flagged]
binlog 1 days ago [-]
Right up until the day the founder gets bored and leaves Anthropic, or some middle manager does a reorg and the project isn't important to them anymore.
freeopinion 1 days ago [-]
Didn't the danger of the founder getting bored always exist? With or without Anthropic?
binlog 1 days ago [-]
What happens when the founder of node.js walks away? Nothing, because the project is community driven and is backed by the Linux foundation.
simonw 1 days ago [-]
Good example there, since Ryan Dahl of Deno is the founder of node.js.
famouswaffles 1 days ago [-]
Anthropic use bun. It wasn't an acquihire. They depend on the tool. If the founder gets bored and leaves, it will continue to exist at least as long as Anthropic use it.
behnamoh 1 days ago [-]
Kinda feels like a rug pull, similar to Bun.
kaliqt 1 days ago [-]
Not even close as Bun is still being actively developed, albeit with less fervor.
1 days ago [-]
singpolyma3 1 days ago [-]
Which any existing user can just do?
steve_adams_86 1 days 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.
kentonv 22 hours ago [-]
For what it's worth, workerd has some pretty aggressive sandboxing too. I'm a bit biased but ask your favorite LLM about it.
grougnax 1 days ago [-]
[dead]
sholladay 1 days 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.
carefulfungi 1 days 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 1 days 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.
carefulfungi 1 days 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 1 days 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.
genxy 1 days 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.
the_gipsy 1 days ago [-]
They basically gave up the day they decided to become npm compatible. That was the day Deno died.
shepherdjerred 1 days ago [-]
That’s the day I switched to Bun
spankalee 1 days ago [-]
Yet Bun has Node compatibility.
shepherdjerred 6 hours ago [-]
Yes, I used Deno because it had an interesting approach to permissions, dependencies, etc.
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
tehbeard 1 days 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
Dylan16807 1 days ago [-]
Presumably they like other aspects of Bun, in a world where a clean API is not an option.
an0malous 1 days ago [-]
Enshittification is inevitable once a company takes VC funding
brazukadev 23 hours ago [-]
That's the correct answer, the rest is cope.
coldtea 1 days ago [-]
"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.
atif089 1 days 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
cprecioso 1 days 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.
jasomill 21 hours ago [-]
Ryan for one said as much a few hours ago right here[1]: he's more interested in building a better architecture for server development than maintaining what was ultimately evolving into a Node-compatible runtime.
Sounds reasonable to me, and I wish him and his team the best as they continue to develop celld/workerd.
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
brcmthrowaway 1 days ago [-]
Brilliant take, this is why I come here. Cut through the "our amazing journey" BS.
networked 1 days 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.
jitl 1 days 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 1 days 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.
k9294 1 days 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 1 days 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.
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 1 days ago [-]
Shopify bought Remix and Tailwind and hired the maintainer of Preact
wodenokoto 1 days 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
mahboi 1 days 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
torben-friis 22 hours ago [-]
Different scala from the programming language (not sure if you knew that already, I did have to check).
ambigious7777 22 hours ago [-]
nearly got a heart attack thank you for this
mahboi 20 hours ago [-]
Oh my goodness, my bad, thanks for the catch.
hirako2000 1 days ago [-]
- Warp -> OpenAI
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
jatins 1 days ago [-]
Replit is not acquired by Anthropic
hirako2000 1 days ago [-]
Good catch, no idea why I thought so. I edited that mistake thanks.
kevinfiol 1 days ago [-]
Svelte -> Vercel
brazukadev 23 hours ago [-]
and also React
larodi 9 hours ago [-]
Llama.cpp -> hugging face -> NVidia
raphlinus 1 days ago [-]
Dioxus -> Cognition
greazy 18 hours ago [-]
SLURM -> NVIDIA. Pretty big deal for the science community.
1 days ago [-]
sapsan 16 hours ago [-]
W&B -> CoreWeave
kaelwd 23 hours ago [-]
EdgeDB -> Vercel
johnz 1 days ago [-]
BetterAuth -> Vercel
letrix 1 days ago [-]
TanStack next?
jitl 9 hours ago [-]
tanner seems not-acquireable
pyaamb 1 days ago [-]
[dead]
ryanrasti 1 days 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.
rough-sea 1 days 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.
OtherShrezzing 1 days 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 1 days ago [-]
Maybe it’s time to ask AI to rewrite those projects ;)
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.
TIPSIO 1 days 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
timdorr 1 days ago [-]
Investors are a helluva drug
mapmeld 1 days ago [-]
Yeah they just made me migrate my blog to their new cloud platform four months ago.
mindwok 22 hours ago [-]
That's a pretty uncharitable take. It literally only exists because of him, he pushed hard for it for years, and now he's decided not to anymore it leaves a bitter taste? What do you want him to do?
vanviegen 1 days ago [-]
Meh, those types of large scale migrations are just a very short prompt nowadays.
phaser 1 days ago [-]
specially deno to bun
vanviegen 15 hours ago [-]
What's with the downvotes? Do people doubt that this type of work is something AI is particularly good at? Or is it just resentment against the resulting fact that making the right architectural decisions isn't as important as it was?
leighmcculloch 17 hours ago [-]
I have felt very misled with the communications around this like this X post. They say Deno + Cloudflare. But at the bottom of the post it's clear that Deno is RIP.
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?
I just migrated that project away from Python to TS :D (cries in corner).
jambutters 22 hours ago [-]
So you prefer scripting in deno/JavaScript over python?
flohofwoe 16 hours ago [-]
I heavily prefer scripting in Typescript over Python (nowadays at least). I'm also not a big fan of how Python is developing since around the 2 => 3 compatibility break tbh.
nonethewiser 18 hours ago [-]
Python package management is a horror show.
jitl 9 hours ago [-]
uv means it’s fine now, at least on the consumer side.
mise use uv
uv install
this coming from a long time devtools engineer
wewewedxfgdf 1 days 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.
phaser 1 days 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.
pimterry 1 days 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 1 days 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.
weli 1 days ago [-]
read the blogpost, they are discontinuing deno after 1 year
adobrawy 1 days 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 1 days ago [-]
People always say this but it's always an extreme mixed bag where most developers/maintainers just move on.
bayindirh 1 days 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.
phaser 1 days ago [-]
it’s open source. i’m hoping it gets picked up by the community. maybe i’m just too hopeful
its-summertime 1 days 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
croes 15 hours ago [-]
Download and run
vs
Download, prompt, test, prompt, wait because of 5 hour limit, prompt, test, run
1 days ago [-]
TheRoque 1 days 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 1 days ago [-]
8 years is not super old, or even old. It's important to understand software maturity cycles for core components.
yipinwong 1 days 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 1 days 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 1 days 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 1 days 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 1 days ago [-]
ty. I like this over others as it uses the "web" as the basis for relativity.
tosti 1 days ago [-]
Ancient
bilalq 1 days 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 1 days 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 1 days 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.
SenHeng 1 days 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 1 days ago [-]
Also it didn't hit 1.0 until 2020 so it's more accurate to say it's 6 years old.
TheRoque 1 days 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
joegibbs 17 hours ago [-]
Node itself was only 9 years old in 2018
goosejuice 1 days 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.
ozgrakkurt 18 hours ago [-]
The main thing was the permissions model and the other runtimes in fact did not learn from it. And there were real big consequences to the node's insane package management model recently.
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.
etatester 1 days 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)
mahboi 1 days 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.
nonethewiser 1 days ago [-]
Once Deno's direction became clear, success seemed unlikely.
tiborsaas 1 days ago [-]
Congrats on the exit :)
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
Latty 1 days ago [-]
Oned maybe.
bsoqk 1 days ago [-]
And then Danone.
khalidkhair 1 days ago [-]
This one might have to be spooned
nateb2022 1 days ago [-]
Sounds like something Bending Spoons would like
duesabati 1 days 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 1 days ago [-]
Whatever allows you to make stuff is good enough.
duesabati 1 days ago [-]
you are definitely right, thank you for this reminder, it's just that I'm a bit tired of managing trash like NodeJS
jesse_dot_id 10 hours ago [-]
Seems like a lot of people have built, and continue to build, pretty successful careers on NodeJS applications.
jadbox 22 hours ago [-]
What's wrong with NodeJS or Bun?
duesabati 6 hours ago [-]
NodeJS has just a long history of mistakes and stubbornes. CommonJS, node_modules mess, hostility against standards, low attention to performance just to name a few. Only recently they finally decided that TypeScript is fundamental, they are what is wrong in the JS ecosystem. I don't hate Bun, but it could've been just a slightly better NodeJS they don't solve fundamental issues like Deno has, so I don't like it. I'll just try as much as I can to wrap/hide NodeJS in my toolchain.
white_dragon88 1 days ago [-]
[dead]
AznHisoka 1 days 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
bilalq 1 days 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.
shados 1 days 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 1 days 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 1 days ago [-]
PlanetScale might be more likely as Neon was bought by Databricks.
eknkc 1 days ago [-]
Yeah. D1 is nice and easy but a serverless postgres offering would make a significant difference.
HatchedLake721 1 days ago [-]
Planetscale?
mathiasrw 8 hours ago [-]
One year of runtime support and six months for Deploy is a scramble. I can’t even imagine how this feels for any CTO who bet on Deno.
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.
multisport 1 days 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 1 days 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.
greeniskool 1 days ago [-]
I wonder how this will affect Bunny's competitor to Cloudflare Workers, Edge Scripting [1] -- which runs on Deno.
Very unfortunate. I’ve been using Deno for years and recently embedding the runtime into applications/platforms for agents. I’ll continue to use it and hope a community springs up.
garganzol 22 hours ago [-]
I believe so. Deno is too good to just die off.
huqedato 1 days ago [-]
RIP Deno. Goes into the bin, after Bun.
rootnod3 1 days ago [-]
All of this just re-informed my believe to stay with true and tested systems that have survived decades. C if I fell confident and Common Lisp otherwise. Both standardized, have been around for ages, and they don’t disappoint.
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.
6thbit 1 days ago [-]
Didn’t they have a flashy lawsuit to free the JavaScript trademark?
What happens to that now?
No indication cloudflare would pursue that yet that I see.
readyp1 1 days ago [-]
It looks like, after Oracle kept on pushing out the deadline for a certain step in the suit process, the parties are in settlement negotiations now [0]; the motion was granted [1], so we might see more info after October 28th.
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?
yellow_lead 1 days ago [-]
Remember "choose boring technology"?
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.
po1nt 1 days 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 1 days ago [-]
What did you transition to?
po1nt 15 hours ago [-]
Rust
da02 7 hours ago [-]
What types of apps are you using for Rust?
schnebbau 1 days ago [-]
AI.
AbstractH24 4 hours ago [-]
Can someone explain to me how you "acquire" an open-source project?
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?
pmdr 2 hours ago [-]
> Can someone explain to me how you "acquire" an open-source project?
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.
JaceComix 1 days ago [-]
Node always felt so annoying to deal with. I was really excited when Bun and Deno were coming up. Pour one out.
ProgStudio 11 hours ago [-]
It's really interesting folks at CF and Deno making this decision while unikernel slowly integrate into mainstream cloud computing as Prisma and Netlify adopting Unikraft. With AI is getting better each day there will comes a day when people be like "why we still running javascript in server?"
kevin_thibedeau 7 hours ago [-]
For a service that has its tentacles all over the internet, you'd think they would prefer native code for the cost savings.
255kb 1 days ago [-]
It seems VC money is not really compatible with open source
mahboi 1 days ago [-]
Maybe they all learned their lesson from Docker giving away the entire product for free
brazukadev 23 hours ago [-]
I hope so. So far it mostly killed projects.
agp2572 1 days ago [-]
This shows that there was no money to be made in their business model and they had to sell to make up for the years or losses accumulated.
amber71de 1 days ago [-]
Does anyone know how many paying Deploy customers there were? The post only offers migration help to paying customers and gives them six months, which makes me think the number is small enough to hand-hold. Millions of runtime downloads and a few hundred accounts on a paid plan can both be true, and only the second one pays for a team.
aravindputrevu 1 days ago [-]
Last year it was bun, and now it is - Deno!
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
SenHeng 1 days ago [-]
People need to eat and pay rent. Can’t survive on just goodwill.
This is a real bummer. Work never adopted Deno but I love their model, security posture, and the standard library. I've been less interested in typescript recently, but it has turned into the default for frontend.
On the plus side, cloudflare will get access to some fantastic talent, who can hopefully put their effort into building a better web.
wg0 1 days 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.
afavour 1 days ago [-]
I'll sound smug saying it but this is always, always inevitable from the moment Deno took VC investment. Either it was going to be successful enough to take over everything (and it wasn't going to be) or it would end up acquired/shut down.
I know Node is boring but it's not going anywhere.
dabinat 1 days ago [-]
We’re in an interesting time for developer tooling. It’s easier than it’s ever been to develop new tools, but harder to monetize or maintain them. We need to figure out what sustainable OSS looks like in the AI age.
bicepjai 1 days ago [-]
Genuine question. Why are companies buying our runtimes ? What is the advantage ? Maintaining open source and having more adoption in specific softwares like runtimes and programming languages helps keep software more robust and reliable right ? Am I getting something wrong.
culi 1 days ago [-]
In this specific case, it's probably just aqui-hiring. There's a ton of incredible talent at Deno and Cloudflare can pay them a lot more
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
Quothling 1 days ago [-]
> With Bun I think it was basically a marketing ploy.
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.
hbn 1 days ago [-]
I think in a case like Bun they're also potentially buying the pre-built goodwill associated with the project.
thayne 1 days ago [-]
I there was also an acquihire component to bun as well.
mattvr 1 days ago [-]
In this case, they're explicitly not buying the runtime. They're killing the runtime.
sandelz 1 days ago [-]
A bit worried what will become of https://github.com/denoland/rusty_v8 as it still is the best maintained (?) and featured binding of V8 for rust.
rough-sea 1 days ago [-]
rusty_v8 isn't going anywhere - we'll keep maintaining it and will be working towards integrating it into workerd
sandelz 1 days ago [-]
Awesome, thanks for the reply!
jerleth 14 hours ago [-]
I tried out deno desktop to build a desktop app and I liked it.
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.
garganzol 22 hours ago [-]
If Deno just took payments or at least donations, it would have thousands, or even tens of thousands of paying customers. Instead, they preferred to submit to VC and chase beehives on Deno Deploy territory.
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.
kentonv 1 days ago [-]
Please be sure to read the post on Cloudflare's blog, it's not just fluff:
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.
patcon 1 days ago [-]
I do appreciate that it's not explicitly anti-competitive, but as a biochemist who spent a lot of time thinking about living systems, I am a bit concerned about a budding ecology that has perhaps collapsed <3
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.
mark_and_sweep 1 days ago [-]
Who decided that the Deno runtime would be abandoned? Was this Cloudflare's or Deno's decision? And why?
rough-sea 1 days ago [-]
It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. 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.
mark_and_sweep 12 hours ago [-]
Thanks for your response, ry. It's hard to put into words how much I appreciate your work, both on Node and Deno. Honestly, you saved me from a career as a Java dev. :) I've been using Node since 2013 and Deno since 2018 (when it was still written in Go)... I used both first for hobby projects and scripting and later, when they matured, also at work.
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...
jflatow 22 hours ago [-]
Why let it get sucked into the gravity well of node compatibility then? How can the community carry it forward without you? Will CloudFlare release the name/assets, or it will have to be forked?
jflatow 3 hours ago [-]
FWIW I think the project is likely highly maintainable with relatively small economic commitment. I would be willing to contribute. If anyone wants to discuss how we keep it going past the next year, please let me know.
skybrian 24 hours ago [-]
You still need a runtime for your CLIs though. How does local development work for celld and workerd? Are you moving back to Node for that?
NetOpWibby 6 hours ago [-]
...well, who decided to embrace Node compatibility?!
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.
> 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
smt88 1 days ago [-]
I don’t know that many people reading this particular thread care whether this is a good business decision for Cloudflare.
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.
chrysoprace 1 days 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 1 days 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).
vmg12 1 days ago [-]
If this was done to kill celld as a runtime that would be unfortunate.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
I'm really happy to hear this. Congrats to everyone involved.
ForHackernews 1 days ago [-]
Sounds like the opposite: They are killing Deno to work on celld
meredithbloom 15 hours ago [-]
Deno was dead the moment they went all in with being compatible with Node.
Meanwhile, Bun's only raison d'etre is the lack of TCO in V8.
ksajadi 19 hours ago [-]
The first thing I look at the next time I look at a project like Deno would be its governance structure and if it can be bought by a large company. Imagine if what happened here (or MySQL) happens to Postgres!
singularity2015 1 days ago [-]
Deno did bring lot of good ideas and hope some of them will flow into Node, especially full typescript type stripping, package less imports to name a few.
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.
ContinuityLab 21 hours ago [-]
Big acquisition, but I hope Deno's runtime doesn't get slowly tied to Cloudflare's specific Workers primitive instead of staying standard platform-agnostic.
gen2brain 1 days ago [-]
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
n_e 1 days ago [-]
> what should I choose and why?
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.
jerf 1 days ago [-]
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
gen2brain 1 days ago [-]
Yeah, after I posted I realized that Go remark was not correct, but again, I am confused how do you combine all that. JS I can read and understand (well, understand), I have seen it already, TS, I compile TS to JS right, and then I can choose any of the current available runtimes to run that code, correct? And final fat binary that is deployed has what, whatever runtime I choose to be?
Huh, I think I guessed that right, I do use such apps, but never bothered to understand how they are actually packed.
mschuster91 1 days ago [-]
> Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code.
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].
Yes, everything I have is pinned that way too. That's why I said "when it is done", even in my limited experience and contact with TS it is not currently a suitable replacement, and I'm not a particularly hard user of the tool chain. (I am having a hard time phrasing this in a way that I'm completely sure can't be potentially read as snarky or short-tempered, so I guess I'll just go with the clumsy direct statement that I'm agreeing with you and continuing the thought from my own experience, not trying to disagree.)
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
gen2brain 1 days ago [-]
Well, that "Go crap" needs some explanation. The reason I am not involved in JS is because I mostly use Go for backend, and I am happy I have no relation with frontend at all. And even that is just small part of my job and what I do daily (Radius, Diameter, etc.).
But, I never heard about Go crap (in that context maybe), or experienced any crap there, it is just nice and simple. What are the issues?
mschuster91 1 days ago [-]
Many of the "rewrite it in Rust/Go/whatever fad" projects that have cropped up have been done with the assistance of AI, especially because both languages are a pretty heavy divergence if you're used to C, C++, Java or JavaScript.
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.
sensanaty 1 days ago [-]
There's basically no reason not to just go with Node as 99% of projects out there do
croes 1 days ago [-]
Isn’t the whole node npm ecosystem now with AI a greater risk as before?
thunderfork 1 days ago [-]
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
CuriouslyC 1 days ago [-]
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
alexfortin 1 days ago [-]
More or less the same but I dropped Bun after Anthropic acquisition so I now default to PNPM and Vitest, which is ok.
seanw444 1 days ago [-]
While it may as well be the same thing, the Anthropic acquisition isn't what turned me off of Bun, it was the vibe-coded Rust refactor. As soon as that happened I dropped Bun. Deno was what I ended up more interested in (Deno Fresh seemed really cool too), but I guess it's just back to Node/PNPM for me now as well. What is going on anymore...
alexfortin 18 hours ago [-]
Yeah same for me actually, I mentioned the acquisition more as a temporal cue than an actual reason, even though they are strictly related in the end: Anthropic acquires Bun to prove their argument, that they have the most awesome LLM technology that can rewrite such a complex product from Zig to Rust for $reasons.
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.
CrimsonRain 1 days ago [-]
There's just one worthy of using for fresh project: Bun.
Deno was never going to be a thing anyways.
WorldMaker 1 days ago [-]
Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.
CrimsonRain 1 days ago [-]
Bun's rewrite has been a massive success, unprecedented even.
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.
lioeters 1 days ago [-]
Bun is dead. It's a skin-walker wearing the appearance of its former self. They screwed the community when they got acquired.
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.
CrimsonRain 1 days ago [-]
Screwed who actually? How? Dead? lol.
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.
SkyeCA 1 days ago [-]
Just use Node. Community led and supported by the Linux Foundation.
righthand 1 days ago [-]
Why not the standard NodeJS? Well supported and not heavily influenced by acquisition or trends like bun is?
CrimsonRain 24 hours ago [-]
If Deno and Bun were not kicking NodeJS's behind, we'd not see any of the improvements in the ecosystem in last few years. Node has been stagnant for a long time.
mschuster91 1 days ago [-]
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?
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.
WorldMaker 1 days ago [-]
I'd throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.
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.
nozzlegear 1 days ago [-]
I'd just go with Node, it supports TS natively now.
bel8 1 days ago [-]
NodeJS just strips TS types and prays that it runs as JS. It's not a native support by any means.
For example it doesn't support enums.
Bun and Deno do the real thing.
rslsts 1 days ago [-]
> prays that it runs
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.
flohofwoe 1 days ago [-]
"deno run" also just strips the types. The type checker is 'opt-in' now.
Don't know what Bun does though.
nozzlegear 1 days ago [-]
Oh for real? I thought the latest versions ran actual typescript.
kevinfiol 1 days ago [-]
Well, it does technically in that to "run TypeScript" all you have to do is strip the types, and execute the remaining JavaScript. This is what Node does, but it doesn't do any typechecking. You can always include TypeScript as a dependency to do the actual type checking for you.
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.
brlewis 21 hours ago [-]
>I thought the latest versions ran actual typescript.
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.
K0IN 1 days ago [-]
I was a big fan of deno, so much that I migrated all my cf worker to demo, cause you can run the same engine in there cloud and local/selfhost - perfect no vender lockin(like with cloud flare workers), it's so sad to see it gets shelved.
clarkarch 10 hours ago [-]
gets acquired and then kill the project, nothing's new
holografix 23 hours ago [-]
What happens to Supabase?
saltcod 12 hours ago [-]
(Supabase employee)
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.
makifoxgirl 1 days ago [-]
I still remember this cute drawing from years ago outlining the things Ryan regret about Node
Man the "cute girly sketchbook doodle summarizing a programming thing" is a throwback to a bygone era. I saw that and immediately knew "this is from the late 2010s"
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.
1 days ago [-]
zicohacks 20 hours ago [-]
Even if official development ends next year, the pressure Deno put on Node to modernize TypeScript support and standards was worth it
wiseowise 1 days ago [-]
So is dead for all intents and purposes. And this would’ve happened to Bun if it hadn’t found its killer app (Claude Code).
Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.
sbinnee 24 hours ago [-]
I wouldn’t have imagined cloudflare acquiring Deno. But AI got into both of them and somehow now it makes sense? It’s wild. Anyhow congrats to Deno team.
chaosharmonic 1 days ago [-]
Well this is fucking depressing.
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?
WorldMaker 1 days ago [-]
It probably does get that advantage that it has had fewer supply chain attacks than npm.
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.
chaosharmonic 1 days ago [-]
I personally see it as valuable for similar reasons -- plus the ability to just import via web if a package is compatible with browsers, and it being open source and free for the community to fork and rebuild in case something like this goes south.
rough-sea 1 days ago [-]
JSR keeps running - the infrastructure is moving to CF
chaosharmonic 1 days ago [-]
That I saw, I was more curious what motivated them to keep it
RossH 24 hours ago [-]
Really sad to see this. I've built projects on the Deno runtime and to see it end in 45 words...
I guess the positive is that at least Deno pushed Node.js to evolve.
sheept 1 days ago [-]
I’ve been using Deno’s permission system as a sandboxed replacement for ‘python -c’ for my agents. Hopefully a better supported runtime (in any language) adds a similar permissions system in the near future.
prtmnth 15 hours ago [-]
This news made me rethink about building on Bun. It's a bit iffy now.
mattvr 1 days ago [-]
Inevitable for a project like this when you take VC money, unfortunately.
ofirg 1 days ago [-]
If your company does not own an ecmascript runtime ngmi
mysterydip 1 days ago [-]
I just learned of Deno yesterday when setting up some software for the first time. I wonder how many applications depend on it behind the scenes?
pmkary 1 days ago [-]
What is it with everyone buying runtimes? — P.S. Deno always felt like it is going to be abandoned, you can't build your work on this much shaky ground...
drewbitt 1 days ago [-]
This is sad. I was a heavy user of Deno, though I recognized its likely downfall when they laid off a large part of their team in the last year.
xena 1 days ago [-]
Well this sucks. My blog is based on deno as I wasn't a fan of node.js at the time. I guess I'm gonna have to rewrite my blog engine.
dev_l1x_be 10 hours ago [-]
What is the value prop of Deno?
oofdere 1 days ago [-]
Well this is very stupid. Why not move Deno to be based on workerd or something? or vice versa? throwing it away is such a waste.
bluegatty 1 days ago [-]
Wow. Just about to choose Deno for something. That not only makes me rethink Deno but ... rethink a lot of things ...
fraywing 1 days ago [-]
This is mostly to be expected.
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
dzonga 1 days ago [-]
my recent comment [0]: was deno was the only other tech player building a proper serverless platform to bring Cloudflare workers in an open source manner.
the CF blog post suggests that is what the Deno team will be working on: combining workerd and celld for true self hostable workers/DOs
kingcauchy 1 days ago [-]
Does Cloudflare already use Deno under the hood then? Like the Anthropic -> Bun aquisition
tietjens 1 days ago [-]
Does this mean that celld is dead? No more open source durable objects?
Throwaway123129 1 days ago [-]
Can we rename title to "Deno is winding down" ? It's not joining cloudflare. the people are
mbStavola 1 days ago [-]
No idea why CF wouldn't just have them to continue working on Deno indefinitely...
brachkow 1 days ago [-]
Because Deno turned into some quirky serverless technology.
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
notnullorvoid 1 days ago [-]
Deno is a excellent and quirky severless, server, CLI, library, and GUI technology.
CF workerd is only one out of those 5.
mbStavola 1 days ago [-]
I mean, sure, but this doesn't preclude CF from keeping a few people around who can work on the runtime while everyone else does... whatever CF wants them to do.
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.
notnullorvoid 1 days 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.
Extremely disappointing...
paaloeye 1 days ago [-]
It's only OpenAI which doesn't have an in-house modern runtime
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.
Defletter 21 hours ago [-]
Curious to see whether, in five or so years, we'll see another talk by Ryan Dahl announcing a new JS runtime: doen!
ecares 1 days ago [-]
10 things I regret about Deno talk incoming
low_tech_punk 1 days ago [-]
anthropic + bun vs cloudflare + deno, could it be counter move for building from agent sandbox that runs on the edge?
melonpan7 1 days ago [-]
Cloudflare really be buying up everything
crsv 1 days ago [-]
Grats on the bag.
zergrush 1 days ago [-]
never used deno or paid much attention to it despite all the fancy marketing.
i always wondered how they were making money
dpc94 1 days ago [-]
Disappointing news to see it shut down, but maybe the writing was on the wall after they laid off some of their folks.
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.
Gotta say the fate of Deno has been pretty disappointing I had high hopes for it
1 days ago [-]
olex01 15 hours ago [-]
so workers would support deno ?
culi 1 days ago [-]
Can't believe they bought out Vite and now Deno. All our toolchains are getting bought out by military contractors
HeadOfProbing 1 days ago [-]
Deno was a good idea in the Old World of software development before LLMs, and simply doesn’t make sense anymore.
oblio 1 days ago [-]
Why? We probably need more sandboxing, not less.
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.
hollowturtle 1 days ago [-]
I warn you to not try to argue with ai shilling people
oblio 1 days ago [-]
I'll be fine, I outlasted the NoSQL and cryptocurrency people :-)
Pesthuf 1 days ago [-]
I think it makes more sense to use the kernel‘s’s sandboxing utilities (like seccomp, SELinux, namespaces, prctl and eBPF) than to rely on the process to try to isolate itself purely in userspace which will always have holes.
mattlondon 13 hours ago [-]
For me Deno jumped the shark when they started trying to be backwards compatible with node and the npm dumpster fire.
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
dgellow 1 days ago [-]
Congrats to the team! Sad to see deno go away, it’s a really great tool
zmj 1 days ago [-]
This is awesome. The Cloudflare platform is great; being able to run more of it locally is a definite plus.
ravenstine 1 days ago [-]
Man, this year has been nothing but bad news for me. This is disappointing, and really makes me question what is the point if even open source is now this easily enshittified or "killed by [insert big tech co here]." I've spent years now using Deno nearly exclusively for new projects, and saw it as the most sane JS server runtime. This also makes me hesitant to use anything with Ryan Dahl's name on it ever again.
csiegert 1 days ago [-]
I’m disappointed that they discontinue the Deno runtime. It really is a joy to use.
I think they ran out of money and joining Cloudflare was their only remaining option.
1 days ago [-]
classified 1 days ago [-]
R.I.P.
galaxyLogic 1 days ago [-]
"entire Deno team is joining Cloudflare .."
Whom did they work for before?
its-summertime 1 days ago [-]
Disappointing. Everything I want to express about this is impolite.
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
asar 1 days ago [-]
really wondering what role celld played in the negotiations
Congrats. But also terrible news for the ecosystem; this project was a bit doomed from the start, and they acknowledge it multiple times (implicitly), but nice to have competition, I guess.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
hoppp 1 days ago [-]
Bun is claude code now. Not gonna touch it.
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
culi 1 days ago [-]
It's sad how it worked out. Bun really stole Deno's momentum. Deno's foundational trust model really feels like its what the JS community needs. There were so many genuine improvements over Node that I don't think Node can ever just adopt
hoppp 1 days ago [-]
And now if you heard it, Deno is dead. 1 more year of support and they all got hired to work at cloudflare instead
dreamcompiler 22 hours ago [-]
I still find it breathtaking that anybody ever thought it was a good idea to develop a web server in a single-threaded language. And apparently huge numbers of people still do.
gnarbarian 19 hours ago [-]
this makes me so angry. I've literally spent months working on my tui. I hope to god deno keeps going.
> 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.
gxcsoccer 1 days ago [-]
Cloudflare is playing a big game ...
Jgrubb 1 days ago [-]
Honestly, this motion right here is the death of open source - the rug pull. I no longer can trust any open source project won't get bought up and sunsetted. I'm glad open tofu and valkey and Linux exist to serve as a counter example but this makes me sad.
oblio 1 days ago [-]
It's not the death of open source. It will probably be the death of small company open source. Either 100% community/non profit or 100% big corporation and users check corporate alignment with project goals.
sophacles 44 minutes ago [-]
This is not the first small company with a popular opensource project that was acquired. Its not the first time such an acquisition resulted in the shuttering of the flagship product. Its not even the first time the shuttering was announced at acquisition (vs the acquirer letting the product just slowly atrophy away).
I doubt it will be the last time.
vachina 1 days ago [-]
Honestly with AI just build it yourself.
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.
rfgplk 1 days ago [-]
This. Internally as of about two months ago I use _zero_ open source code in any of my projects. Anything that I was still relying on was 100% rewritten with an LLM. The only hard dependency remaining is the Linux kernel itself which I predict I'll be able to replace in a few months. The current rewrite is functional except for networking and wider driver support.
wosined 1 days ago [-]
> Deno sells out
cmrdporcupine 1 days ago [-]
I read it more as:
> 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.)
victorbjorklund 1 days ago [-]
RIP
ramesh31 1 days ago [-]
So both major (and the only meaningful) possible Node alternatives have been absorbed into proprietary monoliths in the last year. We all know how well the Joyent years went, RIP to open source innovation at this point.
ecares 1 days ago [-]
Node is still there
Surac 12 hours ago [-]
Another open source killed
collide6 1 days ago [-]
Holy shit, I used to work on the Workers Runtime Team and I'm surprised!
tonymet 1 days ago [-]
how about the IP? will the future open source project be DENO or will they have to come up with another permutation.
(I've trademarked ENDO , feel free to DM me for a license)
sharts 21 hours ago [-]
what’s so great about it?
jpmonette 1 days ago [-]
huhyyy
cyanydeez 1 days ago [-]
is this Cloudflare signalling they're going to hard pivot to being an AI company?
notnullorvoid 1 days ago [-]
No if that were true they wouldn't be stopping development of Deno, which as it stands sits in the best position for codemode given it's granular sandboxing.
kentonv 1 days ago [-]
workerd has also had granular sandboxing all along... I actually coined the term "code mode" in this blog post:
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.
guipsp 1 days ago [-]
Servers, sure. Not necessarily your servers tho
kentonv 1 days ago [-]
workerd is open source, you can run it on your own servers.
xena 12 hours ago [-]
Do you have an example of how to do this with an example nontrivial durable objects app?
cyanydeez 1 days ago [-]
hard pivot to ai confirmed.
kentonv 1 days ago [-]
I think it's well-known that we've been pretty focused on AI agent infrastructure for a while...
asgr 1 days ago [-]
</3
rvz 1 days 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.
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.
vollbrecht 1 days ago [-]
Isn't bun also written in rust, so can you clarify what your point is here?
rvz 1 days ago [-]
Deno wasn't doing well and was repeatedly outperformed in downloads and raw performance when Bun was written in Zig, and even before Bun got acquired by Anthropic.
My point is, even if Bun stayed on Zig, Deno still struggled to compete regardless of the language used.
tommica 1 days ago [-]
I'd guess Deno failed because of the original decision of not supporting node_modules, instead went with a different way of handling dependencies. Else the native typescript support would most likely had pushed them to bigger success past nodejs.
Though nodejs was even then quite solid in it's position, so maybe it would not have made a difference.
nullstyle 1 days ago [-]
What a shame. Guess me and the clankers will be maintaining a fork now
zengid 1 days ago [-]
i guess bun won?
xyst 1 days ago [-]
can yall stop selling out to cloudflare? The continued consolidation of the internet/tech is wild.
blondie9x 22 hours ago [-]
Unreal. Another open source project eaten up by the giants of big tech.
rfgplk 1 days ago [-]
Sorry, but even factoring in that this acquisition carries over the existing customer base and goodwill, this is still **** (censored because I aim to stay polite). Deno is factually speaking a one to two week project at this point (proven by the numerous JS runtimes already on the market). I genuinely do not see how this makes any sense whatsoever. If Cloudflare was seeking to hire the team behind Deno they could have done it at a fraction of the price paid. This, naturally, assumes they did pay anything and I can't be bothered to look up the exact $$$ amounts.
csiegert 1 days ago [-]
I think Deno’s VC money ran out (see the layoffs a few months ago) and Cloudflare offered a stable, well paying job, maybe with stock options.
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.
racl101 1 days ago [-]
uh oh
b319 15 hours ago [-]
[flagged]
pmkelly4444 1 days ago [-]
[flagged]
stzhyzh 16 hours ago [-]
[flagged]
liberian 9 hours ago [-]
[dead]
massimodeluisa 1 days ago [-]
[flagged]
patcon 1 days ago [-]
[dead]
1 days ago [-]
igl 13 hours ago [-]
[dead]
jnagaraj2109 12 hours ago [-]
[flagged]
spprashant 1 days ago [-]
[dead]
grougnax 1 days ago [-]
[dead]
sick_of_slop 1 days ago [-]
[dead]
1 days ago [-]
oh_ok_lol 1 days ago [-]
[flagged]
weird-eye-issue 1 days ago [-]
Cloudflare is a publicly traded company.
officialchicken 1 days ago [-]
There is nothing that requires a VC to sell part or all of their shares when an IPO occurs. And you can read their S1[0] to verify.
> There is nothing that requires a VC to sell part or all of their shares when an IPO occurs
Okay, but I never said there was, so nice strawman argument
At this point they are already up 1000% on their investment
oh_ok_lol 1 days ago [-]
No people on the Boards of both companies? Sorry for being cynical. Seen so much funny stuff in this industry. Good for Deno. Better choice given the talent behind it than Bun, IMHO.
rvz 1 days ago [-]
...And the VCs who invested in Deno will be getting their return from Cloudflare acquiring it, since they are "not allowed to lose".
They would rather have Deno pursue an acquisition instead of shutting down and losing their investment.
The only questionable detail about this announcement is it was for an undisclosed amount. Make of that what you will.
weird-eye-issue 1 days ago [-]
> not allowed to lose
I mean that's just not how it works, most VC investments go to zero and they know that.
oh_ok_lol 1 days ago [-]
So what am I supposed to do, just congratulate them and avoid any critical thought so as not to get downvoted into negative territory on my first day commenting on HM after 5 years of staying away for this exact reason?
4729738210 1 days ago [-]
[flagged]
AtNightWeCode 1 days ago [-]
It was pretty naive to stand in front of that NodeJS train.
buffer_overlord 13 hours ago [-]
Deno is crap so is the StrongLoop team that started it
culi 1 days ago [-]
Welp. All tech eventually gets bought out by military contractors or grows big enough to become one.
stack_framer 1 days ago [-]
Wow, so React Native and Deno both effectively have nails in their coffins. I wonder what's next.
brabel 1 days ago [-]
What happened to React Native? Is it going to be discontinued as well?? We have quite a few customers using it, so we provide a SDK for it. Could be interesting if we can retire that.
dvdyzag 22 hours ago [-]
Probably is that Shopify shocking betrayal about going back to Kotlin and Swift, acknowledging AI coding is there giving the upper hand.
hoppp 1 days ago [-]
So Cloudflare killed Deno
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.
pier25 1 days ago [-]
> So Cloudflare killed Deno
Uh no. The lack of users killed Deno.
hoppp 1 days ago [-]
Platforms like supabase or netlify use deno for serverless functions, so they should have been supporting it more.
pier25 1 days ago [-]
Aren't Supabase or Netlify customers of Deno Deploy?
This is actually awesome news believe it or not. I'm excited b/c i think there's a lot of potential in the world w/ deno's team being on solid footing w/ cloudflare.
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.
danw1979 1 days ago [-]
What ? They are literally stopping development in a year.
culi 1 days ago [-]
You think the open source community will be able to continue deno? Did you miss the part where they're stopping development on it?
rattray 1 days ago [-]
As a bystander, I'm excited by this. I don't know what it'll be, but I have a sense some interesting, powerful, and secure new ways of shipping code could come from this marriage...
akagusu 1 days 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?
bilalq 1 days ago [-]
Time and again, staying on the mainstream node/npm stack continues to be the validated choice. I've seen this happen with io.js, bun, and deno. The situation has been similar for yarn/bun and most alternatives on the package manager side.
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.
So unless someone else picks up development, Deno will no longer be supported.
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!
I have great news for you, then. You are free to pick up the project for free and rake in all that free sponsorship cash.
Do you think this is a reasonable investment of your time?
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.
To jest, businesses can be successful without sustainability. Instagram definitely was.
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.)
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
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.
Which is forever in the tech industry.
Unfortunately Node still can't do something like this out of the box (AFAIK at least):
Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.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.
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.
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.
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.
https://supabase.com/compute
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!!
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 ?
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'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 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 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.
I don't. What do you mean?
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.
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.
Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.
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".
https://docs.deno.com/api/deno/
If only those that boast online how X is greater than Y in every single thread, actually paid even a Starbucks coffee to X.
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?
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
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?
https://docs.deno.com/runtime/fundamentals/security/
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.
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.
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.
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.)
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.
built-in permission system for filesystems and etc
just forbid writing to important folders like ~/.ssh
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.)
This is actually a good decision though.
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?
They should hire a few devs to develop it then.
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.
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.
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.
See https://github.com/denoland/deno/discussions/9811
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.
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.)
For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.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.
https://github.com/oven-sh/bun/releases
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.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
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.
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
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
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)
[1] https://x.com/KentonVarda/status/2108559594691690663
[2] https://edgejs.org/
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!
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!
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.
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).
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
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.
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.
What would they miss out on? A bunch of PRslop? The "open source community" is now dead.
At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.
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.
"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.
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?
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?
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.
IMHO, it shouldn't be allowed.
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.
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
https://github.com/ubernaut/exotui
https://ubernaut.github.io/exotui/
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
I'm sure they'll have a migration path to the cloudflare platform in 12 month.
Isn't that what FLOSS is all about?
From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.
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.
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 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.
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.
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.
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
- typescript support - built in linting - built in package manager command - built in transpiler/bundler
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.
[1] https://news.ycombinator.com/item?id=50023277
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.
> "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.
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.
https://github.com/phoenixframework/durable_server
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...
- 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?
GitHub -> Microsoft, or is this too old
replit is NOT aquired.
- Marimo -> CoreWeave
- Continue -> Cursor (xAI)
Yes open source tooling is gulped by AI companies.
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
https://x.com/deno_land/status/2108543358197207048 (https://archive.is/H4GLt)
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?
1: https://peps.python.org/pep-0723/
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.
of course i’m only talking about deno, the technology not deno, the cloud service.
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.
Again, thanks to the MIT license.
vs
Download, prompt, test, prompt, wait because of 5 hour limit, prompt, test, run
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.
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.
[1] https://bunny.net/docs/scripting/
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.
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...
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.
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.
What's happening to JS platforms? I thought Deno has a much better approach to building a platform.
https://theoatmeal.com/comics/exposure
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.
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.
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.
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.
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.
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.
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.
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.
> 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
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.
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.
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
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.
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.
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].
[1] https://github.com/TypeStrong/ts-loader/issues/1671
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
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.
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.
Deno was never going to be a thing anyways.
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.
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.
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.
For example it doesn't support enums.
Bun and Deno do the real thing.
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.
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.
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.
https://imgur.com/a/XFAMzOV
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.
Another reason why standards matter. Think twice before you bet on that VC funded horse, folks.
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.
I guess the positive is that at least Deno pushed Node.js to evolve.
After Deno did layoffs we saw a consistent decline in announcements and innovation.
Sad day, but unsurprising.
will they continue that work ?
[0]: https://news.ycombinator.com/item?id=49977056
otherwise this is a proper acquisition. t
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
CF workerd is only one out of those 5.
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.
Extremely disappointing...
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 always wondered how they were making money
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.
https://dbushell.com/2026/03/20/denos-decline-and-layoffs/
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.
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
I think they ran out of money and joining Cloudflare was their only remaining option.
Whom did they work for before?
I guess I can say that this means Deno won't ever have a much needed Python 3 moment.
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.
https://github.com/ubernaut/exotui
https://ubernaut.github.io/exotui/
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.
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.
> 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.
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.
> 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.)
(I've trademarked ENDO , feel free to DM me for a license)
https://blog.cloudflare.com/code-mode/
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.
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.
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.
[0] https://www.sec.gov/Archives/edgar/data/1477333/000119312519...
Okay, but I never said there was, so nice strawman argument
At this point they are already up 1000% on their investment
They would rather have Deno pursue an acquisition instead of shutting down and losing their investment.
The only questionable detail about this announcement is it was for an undisclosed amount. Make of that what you will.
I mean that's just not how it works, most VC investments go to zero and they know that.
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.