yt-dlp Drops Bun Support — And Open Source Is Sending a Signal

In open source, the word deprecate carries more weight than it sounds. When a tool like yt-dlp — downloaded millions of times, embedded in countless workflows — formally drops support for a runtime, that’s not a routine housekeeping note. It’s a signal. And yt-dlp’s recent decision to deprecate Bun support has surfaced doubts about next-gen JavaScript runtimes that have been quietly accumulating for a while.

Why yt-dlp Pulled the Plug

yt-dlp started as a youtube-dl fork and is now the de facto standard for video downloading. The core is Python, but a slice of plugins and adjacent tooling lean on JavaScript runtimes — and Bun was on the supported list.

Then the maintainers gave up. The reason: inconsistent runtime behavior. Code that ran fine on Node.js broke in unexpected ways on Bun, and every version bump introduced fresh edge cases. The moment debugging user environments started costing more than Bun support was worth, the math made itself.

The Shadow Behind “Fast”

Bun arrived in 2022 with speed as its calling card. Faster cold starts than Node, a bundler built in, native TypeScript. A single benchmark chart was enough to shake the developer community — Hacker News and Reddit threads ran for days.

But benchmarks aren’t production trust. Projects like yt-dlp have to behave identically across Windows, macOS, Linux — and a sprawl of distros and architectures within each. In that world, predictable beats fast. Bun’s compatibility layer is good enough that “most Node.js code runs,” but that’s not the same promise as “every case behaves identically.” For large OSS projects shipping to heterogeneous users, that gap is fatal.

Is This Really Just a Bun Problem?

The interesting part is that this decision implicates more than one runtime. Deno walked a similar path — launched with ambition, then pivoted toward stronger Node.js compatibility once reality set in. The wall next-gen runtimes keep hitting is straightforward: catching up to 20 years of npm ecosystem inertia is harder than the pitch decks suggest.

yt-dlp’s call is also an honest admission: we don’t have the bandwidth to babysit an unproven runtime. For OSS projects with thin maintainer benches, supporting something untested compounds in cost. When a user files “doesn’t work on Bun,” just triaging whether it’s yt-dlp’s bug or Bun’s bug is its own project.

This Doesn’t Mean Bun Is Dead

Don’t read this wrong. Bun is still actively developed, and for greenfield full-stack projects, internal tools, or simple API servers, it’s a legitimate choice. Controlled environments, pinned dependencies, a known deployment target — that’s where Bun’s speed turns into real leverage.

What the yt-dlp case clarifies is the edge of that envelope. As the runtime underneath a general-purpose tool used by tens of thousands of people in unpredictable setups, it’s not there yet. Production-ready isn’t a label you earn by shipping 1.0. It’s the residue of years of users beating on your runtime in environments you never imagined.

The Takeaway

yt-dlp dropping Bun isn’t a failure of next-gen runtimes — it’s open source doing what open source does, stress-testing new tech until the marketing burns off. Underneath the benchmark theater, the question that always wins is the boring one: does this thing behave the same way tomorrow as it did yesterday, on a machine I’ll never see?

What’s running your stack right now? Ever adopted something because it was “fast,” then spent twice as long debugging the runtime as you saved on execution? Sometimes the most boring choice is the most rational one.