Cloudflare acquires Deno
deno.com931 points by ilreb 8 hours ago
931 points by ilreb 8 hours ago
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.
See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.
QuickJS works fine for yt-dlp and is way smaller: less than 1 MB vs 34 MB + its many dependencies for Deno.
For asynchronous downloading of huge media files, speed should not be a priority?
Afaik it's used more for circumventing anti-bot measures and solving challenges than the download handling itself.
This is accurate (maintainer of downstream project that depends on yt-dlp for archiving operations).
When downloading huge media files, the only speed you're being limited by is your bandwidth.
Everything else is completely negligible.
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
> 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?
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.
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.
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.
You can migrate off deno in a single day. It's not a big deal.
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";
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.
This doesn't seem like a big deal. Don't you just npm install whatever you need and then change the import names?
FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.
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.
Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.
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.)
As long as the competition forced Node to become better then it's all good.
Communities aren't always in competition with one another.
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.
I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.
I went all-in with bun. Did I bet wrong?
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.
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.
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?
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.
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.
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...
How would you set that up?
Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.
One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.
It would be far from a standard solution though.