Hacker News Reader

Comment by tech234a | Hacker News Reader

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.

View on HN

QuickJS works fine for yt-dlp and is way smaller: less than 1 MB vs 34 MB + its many dependencies for Deno.

See https://github.com/denoland/deno/discussions/9811

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).

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?

I believe the parent comment is saying the js runtime doesnt affect the speed of downloads, thats all c/c++/rust code

When downloading huge media files, the only speed you're being limited by is your bandwidth.

Everything else is completely negligible.

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.

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.

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.

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.”

> 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?

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)

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.

> (...) 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?

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.)

  +------------+--------------+
  | Week of    | Main commits |
  +------------+--------------+
  | 2026-04-13 |           88 |
  | 2026-04-20 |           95 |
  | 2026-04-27 |          200 |
  | 2026-05-04 |           25 |
  | 2026-05-11 |           50 |
  | 2026-05-18 |          148 |
  | 2026-05-25 |           77 |
  | 2026-06-01 |           70 |
  | 2026-06-08 |           37 |
  | 2026-06-15 |           60 |
  | 2026-06-22 |          153 |
  | 2026-06-29 |          102 |
  | 2026-07-06 |          137 |
  | 2026-07-13 |          213 |
  | 2026-07-20 |          210 |
  | 2026-07-27 |          185 |
  | 2026-08-03 |          164 |
  | 2026-08-10 |          316 |
  | 2026-08-17 |          284 |
  | 2026-08-24 |          196 |
  | 2026-08-31 |          157 |
  | 2026-09-07 |          119 |
  | 2026-09-14 |          154 |
  | 2026-09-21 |          123 |
  | 2026-09-28 |           68 |
  | 2026-10-05 |           21 |
  +------------+--------------+
  | Total      |        3,452 |
  +------------+--------------+

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.

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.

> 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.

Is this what you call productive.

https://github.com/oven-sh/bun/releases

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.

Here's a table that counts features in that way:

  Month        Main  Released
  -----------  ----  -----------------
  2025-01        20  24 (1.1.43-1.2.2)
  2025-02         5  5 (1.2.3-4)
  2025-03        11  14 (1.2.5-8)
  2025-04        15  15 (1.2.9-11)
  2025-05        19  8 (1.2.12-15)
  2025-06         5  15 (1.2.16-17)
  2025-07         5  3 (1.2.18-19)
  2025-08        21  20 (1.2.20-21)
  2025-09        14  24 (1.2.22-23)
  2025-10         1  1 (1.3.0-1)
  2025-11         6  7 (1.3.2-3)
  2025-12 (A)    17  14 (1.3.4-5)
  2026-01        13  16 (1.3.6-8)
  2026-02         2  1 (1.3.9-10)
  2026-03         9  9 (1.3.11)
  2026-04         4  2 (1.3.12-13)
  2026-05 (R)     9  5 (1.3.14)
  2026-06         7  0 (none)
  2026-07         9  0 (none)
  2026-08        13  29 (1.4.0)
  2026-09         9  6 (1.4.1-2)
  2026-10 *       5  11 (1.4.3)

  Pre-acq      11.1  12.4
  Post-acq      9.0  8.4
  Rust          9.4  8.0

Full details of what feature was added when in this gist: https://gist.github.com/simonw/93709c3b3f70f5c703ddde91b9922... (plus the script to generate it)

Reply on news.ycombinator.com