Steve Heffernan hasn't touched Video.js in any meaningful way since the early 2010s. He built it, released it into the wild, and watched as it became one of the most ubiquitous video players on the web—embedded on sites from Wikimedia to... well, thousands of places most users never think about. Then he moved on.
Until now.
What he's unveiled isn't a patch, or even a major version bump in the traditional sense. It's a tear-it-all-down-and-start-over rebuild. Video.js v10, announced in beta this March, delivers the same core functionality as its predecessor in 88% less JavaScript. The old default player? 75.2 kB gzipped. The new one: 25.1 kB.
And no, that's not compression sleight of hand or minification wizardry. It's architectural surgery.
The Weight of Streaming
The reduction gets more striking when you factor in adaptive bitrate streaming—the tech that lets video quality adjust on the fly based on your connection speed. Video.js v8, bundled with its built-in VHS engine for handling HLS streams, came in at 202.7 kB gzipped. Version 10, using a new engine called SPF, clocks in at 38.7 kB for standard HTML implementations. React users can get it down to 31.6 kB.
That's 19% of the original, according to the project's own benchmarking. A minimal React playback demo—just the "hello world" of video—runs under 5 kB gzipped now.
How does that stack up? The team published comparison tables against other major players. Plyr with HLS.js: 188.5 kB. Media Chrome with HLS.js: 202.9 kB. Vidstack with HLS.js: 238.1 kB. Even looking at just the streaming engines in isolation, SPF's 12.1 kB footprint sits well below HLS.js-light's 103.4 kB or a custom Shaka build at 115.0 kB.
Whether those numbers hold up in production across varied use cases remains to be seen—beta software and all that. But the direction is clear.
Four Projects Walk Into a Bar
Here's where it gets interesting. This isn't just Video.js slimming down. It's the consolidation of four separate open-source video player projects: Video.js, Plyr, Vidstack, and Media Chrome. Combined, those repos have collected 75,000 GitHub stars. They power tens of billions of video plays every month, if the estimates are anywhere close.
Mux, the video infrastructure company where Heffernan now works, is bankrolling the effort. The company announced its formal backing last October, noting they were aiming for a mid-2026 general release.
Sam Potts—creator of Plyr, known for its obsessive attention to interface polish—is handling the design work for v10's default and minimal skins. In a November blog post he titled "Sweating the pixels," Potts laid out how Plyr's philosophy would inform the new interface: refined controls, thoughtful animations, the kind of micro-interactions most users never consciously notice but definitely feel. The goal, he wrote, is making the migration from Plyr to Video.js v10 "as smooth as possible."
Which, translation: they're trying not to piss off the existing user bases of four different projects.
How'd They Do It?
Two big shifts explain the weight loss.
First, adaptive bitrate streaming is no longer bundled by default. In v8, the VHS engine came along for the ride whether your use case needed it or not. Now you only load what you use.
Second: SPF, or Streaming Processor Framework. Instead of shipping a monolithic streaming engine, SPF is built from composable functional components that snap together into purpose-built engines. For straightforward on-demand ABR scenarios, this produces dramatically smaller bundles. For more complex needs—live streaming, DRM, exotic codecs—v10 still plays nice with HLS.js, Shaka Player, and dash.js.
Everything's decoupled now. State management, UI components, media handling—all separate, all composable. There's a createPlayer function that accepts a features array, pulling in only what's specified. UI primitives ship unstyled. Skins can be ejected entirely and controlled in your own codebase.
It's the kind of modular architecture that makes engineers nod appreciatively and product managers worry about migration complexity.
What Developers Need to Know
Fair warning: this is a ground-up rewrite, which means the API surface is different. Heffernan didn't sugarcoat it in his March announcement: "APIs are not yet stable, and the feature set is still limited."
But what's there works. Accessible captions are supported. Most formats and services function correctly—at least according to early testing.
The project ships with first-class support for React, TypeScript, and Tailwind, which tells you something about what the team thinks modern web development looks like in 2026. Documentation includes examples for both HTML custom elements and React components. Installation follows standard patterns for @videojs/react and the core library.
There's also a notable focus on AI-assisted development—not AI features in the player itself, but tooling to help developers build players using AI coding assistants. The repo includes llms.txt files, Markdown versions of documentation that respond to specific headers, and what they're calling "AI skills." Heffernan framed it as "the foundation for the next significant transition to AI-augmented features and development."
Whether that's prescient or just buzzword-friendly remains an open question.
What Comes Next
The beta shipped roughly a month later than the original February target mentioned in earlier project updates. General availability is still penciled in for sometime mid-2026, though anyone who's shipped software knows how those dates tend to slip.
Migration guides are in the works for users of Video.js v8, Plyr, Vidstack, and Media Chrome. Ads support—a make-or-break feature for many commercial deployments—is on the roadmap for later this year. The team's soliciting feedback through GitHub issues and Discord as the API stabilizes.
It's unusual to see this in open source: an original creator returning after a decade and a half, not to tinker at the margins or shepherd pull requests, but to demolish and rebuild from first principles. Wikimedia switched to Video.js back in 2022. Countless other sites run it without thinking twice.
Now those same deployments have a path to something fundamentally lighter—assuming they're willing to migrate when v10 is production-ready. And assuming "production-ready" arrives on schedule, which in software is always the real question.
