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.
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.
> 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.
> Considering one of those releases was a full rewrite (...)
I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.
Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.
I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.
Anthropic acquired Bun in December 2025, so there are two questions here: how much did velocity of feature releases change after the acquisition, and how much did they change after the port to Rust?
One potentially useful
way to measure that is to use Bun's TypeScript API definitions as a proxy for "features".
We can look at when those landed on main (which should make them available in a canary release) and when they landed on an actual release.
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.
Yes, if you look at the developer's Twitter account they've shared a large number of projects in the past week, including in-browser recreations of Windows Vista, XP, 2000, ME, 98, 95, 3.1, Mac OS 9, Word, Excel, OneNote, Access, Visio, Adobe Illustrator, Adobe Reader, a Git Client, a CAD program, a video editor, etc. https://x.com/wieslawsoltes
Looking through his work it seems that he has build a whole .net browser based ecosystem [1]. Pretty impressive its own right. However, for his showcase projects I was wondering how he'd prompt to guide these recreations, i.e. what is used as the input, I can't image that he'd describe every tiny detail...
I was wondering how he'd prompt to guide these recreations, i.e. what is used as the input, I can't image that he'd describe every tiny detail...
I thought the same way when I saw some impressive AI-generated videos not long ago, and I suspect the author prompted AI to get a basic idea, and then possibly after many iterations, finished it up with manual editing.
Does "external" contributors effectively mean drive-by contributors? I assume there's still more than a single developer, and it's somehow possible to be admitted as a member of the project if you have some existing public reputation.
Website says: "Ladybird is open source, developed by a small team in the open. You can help by filing bug reports, creating reductions, testing websites, reporting security issues, and sharing technical feedback." [1]
I bet if you contribute in those various other ways for a while, you can probably eventually submit patches. Not as exciting as being able to jump right in, for sure. But it sounds like there's a way in, and I guess you can carry your own patches in a downstream fork in the meantime.
The percentage display is inaccurate but maybe it's really a download progress indicator?
reply