> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> ...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.
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.
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.
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.
> 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?
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.
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
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.
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.
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.
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.
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).
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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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?
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.
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?
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.
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).
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.
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.
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.
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).
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.)
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
> 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.
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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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
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
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)
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.”
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.
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.
> 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.
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.
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.
‘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.)
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.
> 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
> 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
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.
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.
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.
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?
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.
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!
> 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. ;)
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.
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.
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.
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!
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.
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).
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
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
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.
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.
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.
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.
"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.
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.)
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.
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.
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).
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.
> 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/
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.
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.
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.
The worst situation I've encountered is after a large conference when everyone is leaving the hotel at once. An elevator quickly fills up on the way down, but then wastes time stopping at every subsequent floor with a call, even though no one else can fit inside. At each floor the elevator stops, the doors open, the waiting people see it's already packed, the doors close, and this repeats on the next 15 floors before finally reaching the bottom where everyone gets off. If the algorithm could know an elevator is completely full and only stop at its destination floors rather than every floor along the way with a call, it would be far more efficient.
There’s also a strategy to jump the line. Say there’s a talk that just took place on the top floor roof deck of a small ~20 floor building. People who don’t want to wait in line with a hundred people, can take the stairs down one level, call the elevator on the way up to enter the car before it is filled, ride it up one level*, and then ride it all the way down to the ground floor.
To prevent a riot, the building should probably deploy an employee with a fire key to manually operate the elevator.
* Elevators will answer an up button call while it is going to meet a down call from the top floor, but they will answer that call before filling any new down instructions, so you do have to ride to the top first.
Many buildings permit stairwell entry, but limit stairwell exit for fire code (1st) and security reasons (2nd). You'll want to check to see that you can exit at floor n-1 before attempting this, or you'll be riding the stairs all the way down.
I used to work in a shiny new LEED certified government building here in DC. My office was on the second floor. I had to take a elevator every day because the only stairs were for fire use. So frustrating.
Also works for Buses and Trains. Go one stop the opposite way, then go back. This may take a couple minutes longer, but you'll have a seat for the rest of the journey.
I have seen elevators, usually in a big building with a lot of elevators, that do act that way (presumably using weight sensors?). I’ve read that some elevators also have a “kid mode” that does the opposite: if some kid pushes all the buttons as they leave (just for the lolz), the elevator cancels the calls.
It would have to be done by weight. If you had a button to not allow stopping for others, people would abuse it. If it was a camera, security issue. Presumably if somebody is moving a piano or something else heavy it'll be fine
You could also detect when the elevator call button gets pressed again right after the elevator has left a floor. That means someone wasn't able to get on the elevator (and is now waiting for the next one).
I mean this in the nicest way possible. Do you see all these cloud photo/video leaks like from robot vacuums or whatever and think they don't know it can be done locally?
So unless someone else picks up development, Deno will no longer be supported.
reply