Video.js v10: How One Developer Rewrote 16 Years of Code to Be 88% Smaller

Video.js v10: How One Developer Rewrote 16 Years of Code to Be 88% Smaller
Video.js v10: How One Developer Rewrote 16 Years of Code to Be 88% Smaller

Open Source Tools — March 26, 2026

Video.js v10: One Developer Rewrote
16 Years of Code. 88% Smaller.

Steve Heffernan built Video.js in 2010, took it back, and rewrote it from scratch with four open source teams. The result: 88% smaller default bundles, first-class React support, and a case study in what it takes to fix a library powering tens of billions of video plays per month.

88%
Bundle Reduction
Default bundle 88% smaller than v7. Tree-shaking finally works correctly.
16 yrs
Legacy Rewritten
2010 to 2026. Complete ground-up rewrite. No backward compat ballast.
React
First-Class Support
Native React integration. No more wrapper hacks or lifecycle management workarounds.
10B+
Monthly Plays
Video.js powers tens of billions of video plays per month. This upgrade affects real infrastructure.

Sources: Video.js v10 release notes; Steve Heffernan GitHub; npm download stats; March 2026.

Video.js v10.0.0 beta shipped in March 2026, a ground-up rewrite of the web’s most-used open-source video player. Steve Heffernan, who built the original Video.js 16 years ago, led the rebuild alongside the creators of four other major player projects: Sam Potts (Plyr, 29,000 GitHub stars), Rahim Alwer (Vidstack), and the Media Chrome team from Mux. The combined projects represent 75,000 GitHub stars and tens of billions of monthly video plays. The result: an 88% smaller default bundle, first-class React and TypeScript support, composable unstyled UI primitives, and a custom compiler that translates skins across JavaScript and CSS frameworks. GA is targeted for mid-2026.

Video.js powers video playback on Amazon.com, LinkedIn, Dropbox, and thousands of other sites. When Brightcove was acquired in 2025, the Video.js contributors on their team were let go. The project needed new stewardship or it would slowly become incompatible with the web around it. Mux (Heffernan’s company) stepped in as the new corporate shepherd and turned what could have been a maintenance-mode handoff into the largest open-source video player consolidation in web history.

Why a Rewrite Was Necessary

The original Video.js was built in 2010 to help the transition from Flash to HTML5 video. The web development stack of 2010 (semantic HTML, vanilla JS, jQuery-era CSS) bears no resemblance to the React/TypeScript/Tailwind ecosystem developers work in today. Video.js v8, the last major version before the rewrite, reflected that era: a monolithic core that tried to support everything out of the box, proprietary component APIs that did not integrate with modern frameworks, and a default bundle that weighed close to a megabyte.

The problem was not just Video.js. Every major open-source web video player (Plyr, Vidstack, Media Chrome) faced the same architectural limitations. Each had independently solved pieces of the puzzle: Plyr built beautiful design and ease of use, Vidstack brought Radix-like composition and framework-native components, and Media Chrome made custom video players as simple as writing HTML attributes. None of them had enough engineering capacity to solve all the problems simultaneously. The rewrite combined the best architectural decisions from all four projects into a single codebase.

How the Architecture Changed

Video.js v10 adopts a composable component architecture inspired by BaseUI, shadcn/ui, and Radix. Everything is built on unstyled UI primitives (buttons, sliders, menus) that handle behavior without imposing design. Framework-specific components wrap these primitives to provide idiomatic experiences: native React components for React apps, standard HTML elements for vanilla projects, with Svelte and Vue planned next.

The most technically interesting feature is the custom skin compiler. Skins are authored in a “lingua franca” (React + Tailwind), then compiled into whatever combination of JavaScript and CSS framework the developer uses. If you customize a skin in React, all components render as React components with your chosen CSS framework. This eliminates the decades-old video player problem of needing to step outside your app’s frontend stack to customize the player. The compiler generates optimized output for each target, which is how the default bundle dropped 88% in size.

What Changed Technically

The beta ships with two skins designed by Sam Potts: a default frosted-glass aesthetic and a minimal skin for developers who want a clean starting point. Both feature refined controls, smooth animations, and thoughtful transitions that represent a quality level Video.js has never reached. For 10 years, the error dialog was Heffernan’s “big ugly text X.” The new error dialogs match each skin’s visual language, a detail that seems minor but signals the project’s shifted ambition from “functional” to “beautiful by default.”

TypeScript is first-class. Every component, hook, and utility is fully typed. The API surface is designed for tree-shaking: import only what you need, and the bundler eliminates everything else. The streaming engine is being rebuilt by Qualabs and Cast Labs through a partnership with Mux. Adaptive streaming (HLS/DASH) support is on the roadmap for the release candidate phase. Ads support is planned for later in 2026.

Why This Consolidation Matters

Open Source Video Player Landscape Before and After
Before: Five separate projects (Video.js, Plyr, Vidstack, Media Chrome, Mux Player) each solving overlapping problems with separate codebases, separate maintainers, and separate plugin ecosystems. Users had to choose between beauty (Plyr), composability (Vidstack), simplicity (Media Chrome), or ecosystem (Video.js). No single option excelled at all four.
After: One project combining 15+ years of production insights from all five. The engineering capacity is concentrated. The plugin ecosystem is unified. Migration guides cover all four predecessor projects. The combined community means bug reports, feature requests, and contributions flow to a single codebase instead of being spread thin.
The risk: Consolidation creates a single point of failure. If Mux’s corporate priorities shift, the project depends on one company’s sponsorship. The same Brightcove acquisition that triggered this rewrite could happen to Mux. Open-source projects that depend on a single corporate shepherd are as fragile as the company’s business model.

The AI Connection

Heffernan explicitly frames v10 as the foundation for “the next significant transition to AI-augmented features and development.” This means features like automatic captioning, content-aware thumbnails, intelligent quality selection, and AI-generated video summaries that operate at the player level. In the acknowledgments, Heffernan thanks Claude by name: “I don’t know if you can hear this yet, but we certainly burned through some tokens together.” The rewrite used AI coding tools in development, making Video.js v10 one of the highest-profile open-source projects to publicly acknowledge AI-assisted development.

The HN post (“Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller”) landed on the front page, generating the kind of developer attention that most open-source projects never achieve. The framing worked because it combined nostalgia (16-year-old project), technical ambition (88% smaller), and a compelling narrative (creator returns to save his project). For developers evaluating web video players in 2026, the competitive landscape just simplified. Video.js v10 is the default recommendation unless you have a specific reason to use something else.

Sources: Video.js v10 Beta announcement; Mux blog; GitHub v10 repository; Hacker News discussion; Mux “Five players, one future” technical overview; v10 roadmap documentation.

What Developers Should Know Right Now

The beta is available on GitHub (videojs/v10) and through npm. It is not production-ready. The core playback works, skins render correctly, and the React integration is functional, but streaming engine parity (HLS/DASH) is not yet complete. Ads support is absent. Plugin migration from v8 is not yet documented. The roadmap targets a release candidate with streaming support by mid-year and GA with full v8 feature parity by end of 2026.

For teams currently using Video.js v8, Plyr, Vidstack, or Media Chrome: there is no urgency to migrate. All four projects will continue receiving security patches. But feature development has stopped or slowed on each of them, because the engineers who built them are now building v10. The practical implication: if you start a new project today that needs a video player, evaluate v10 beta. If you have an existing production deployment, wait for GA and the migration guide for your specific player.

The browser support question matters for teams targeting smart TVs, set-top boxes, or embedded devices. v10 targets evergreen desktop and mobile browsers. Older Chrome versions (38, 53) that matter for the connected TV market are not supported. Teams building for those platforms will need to stay on v8 or evaluate alternatives. The rewrite optimized for the 95% of developers building for modern browsers, not the 5% targeting legacy embedded platforms. That is a defensible choice for most applications, but it means v10 is not a universal replacement for v8 in every deployment context.

Discover more from My Written Word

Subscribe now to keep reading and get access to the full archive.

Continue reading