Steve Heffernan built Video.js in 2010 to solve the Flash-to-HTML5 transition. Now, 16 years later, he has rewritten it from scratch, merged it with three other major open source video players, and shipped a beta that produces bundles 88% smaller than the version it replaces. The project landed on Hacker News on March 26, 2026, with the headline: I took back Video.js after 16 years and we rewrote it to be 88% smaller.

The rewrite is technically interesting. The team structure behind it is unusual. The specific decisions that produced the 88% reduction are worth understanding in detail because they generalize to any JavaScript library that has accumulated a decade of architectural debt.

The Team Behind the Rewrite

Video.js v10 is not just a Video.js rewrite. It merges four separate open source projects with a combined 75,000 GitHub stars and tens of billions of monthly video plays: Video.js (the original, the most widely deployed web video player, used on Amazon, LinkedIn, and Dropbox), Plyr (known for its clean API and beautiful default skin, created by Sam Potts), Vidstack (which introduced Radix-like composition and framework-native components to video), and Media Chrome (which made custom video players as simple as writing HTML via web components).

The four projects converged because their maintainers reached similar conclusions independently. Current video players are architected for a world that no longer exists. They were built before React had hooks, before TypeScript became the default for serious projects, before the framework diversity of modern frontend development made a single-stack assumption untenable. Mux, the video infrastructure company where Heffernan works, stepped in to provide sustained development resources for the merger.

Sam Potts of Plyr handles visual design for v10. Rahim Alwer of Vidstack brought the composition model. The Media Chrome team contributed the web component architecture philosophy. The result is a player that treats framework integration as a first-class concern rather than an afterthought bolted on via a separate API layer.

How the 88% Reduction Actually Works

The headline number requires a specific comparison. The 88% reduction compares the default Video.js v10 bundle against the default Video.js v8.x bundle. This comparison is honest but needs context to be meaningful.

The largest single contributor to the size reduction is a deliberate architectural decision: adaptive bitrate streaming (ABR) support was unbundled from the default build. ABR handles HLS and DASH formats, the protocols used for streaming video with variable bitrate based on network conditions. This is the feature a streaming platform like Netflix requires. It is the feature most Video.js installs do not actually use.

Previous versions included ABR in the default bundle whether users needed it or not. V10 ships without it. This single decision accounts for a substantial portion of the size reduction. It is worth being explicit about because it means the 88% comparison is not purely an efficiency story: it is partly a scope story. The v10 default bundle does less than the v8 default bundle by design.

Even with ABR excluded from both sides of the comparison, v10 is still 66% smaller than v8. That gap reflects genuine architectural improvements. The team removed IE and legacy browser support, eliminated the internal UI component framework that v8 maintained separately from the host application’s framework, and fundamentally redesigned the extension model.

V8 was monolithic. Customizing it required stepping outside the player’s internal abstraction layer into a parallel UI framework that did not share conventions with whatever React or Vue application was hosting it. V10 is composable. A developer using React gets React components. A developer using TypeScript gets full type coverage without a separate type-stubs package. A custom compiler the team built translates skins from a React plus Tailwind source into any combination of JavaScript and CSS frameworks, eliminating the framework impedance mismatch that made customization painful in earlier versions.

The Technical Decisions Behind the Reduction

Three specific decisions drove the size improvement beyond removing ABR.

First, the team dropped all IE and legacy browser support. Supporting older browsers requires polyfills, transpilation targets, and fallback implementations that add weight without benefiting the overwhelming majority of users. V10 targets evergreen browsers exclusively and uses modern JavaScript APIs (Intersection Observer, ResizeObserver, Web Animations API) that were not universally available when Video.js was first built.

Second, the internal event system was replaced with native DOM events. The previous player maintained a custom event emitter layer for cross-browser compatibility. Modern browsers expose sufficient native event APIs that this layer is no longer necessary. Removing it eliminates a non-trivial internal dependency that every customization and plugin had to navigate.

Third, the plugin and extension model was redesigned around web standards rather than custom abstractions. Previous plugins had to interact with Video.js internal APIs that had no correspondence to anything in the wider JavaScript ecosystem. V10 plugins work through standard DOM and web component interfaces, which means the interoperability cost drops significantly and plugins become easier to maintain across major version updates.

The Repo, Timeline, and Licensing

The v10 beta is live at github.com/videojs/v10 under the Apache 2.0 license. General availability is targeted for mid-2026. Migration guides for v8.x, Plyr, Vidstack, and Media Chrome are planned alongside the GA release. Ads support is planned for later in 2026, with the maintainers noting that ads are complicated and have been given their own timeline.

The project remains fully open source with a Technical Steering Committee for governance. Mux provides sustained development funding without controlling the project’s direction, which is a more sustainable structure than a single-maintainer project that Video.js was effectively becoming before Mux stepped in.

Limitations to Know Before Migrating

V10 is not backward-compatible with v8 by design. The architectural improvements that make it better also make it a migration project rather than a version bump. The migration guides are planned but not yet published as of the beta release.

The plugin ecosystem for v10 is early. The 75,000 combined GitHub stars from the four merged projects represent community scale, but specific plugins that organizations depend on from the v8 ecosystem may not have v10 equivalents yet. Organizations with heavy plugin customization should follow the beta progress closely before committing to a migration timeline.

The 88% size reduction applies to the default bundle without ABR. Organizations that use HLS or DASH streaming will include the streaming engine, which adds significant weight back. The v10 streaming engine is also being rewritten, but the target comparison for ABR-enabled deployments is the 66% reduction against v8 without ABR, not the headline 88%.

What This Project Teaches

The Video.js v10 story is a clean case study in what successful open source library maintenance requires after the first decade. The original author retains institutional knowledge of why specific decisions were made. The original architecture reflects constraints that no longer exist. Users have built significant infrastructure on the existing API. A ground-up rewrite is the only path that addresses all three, and it requires both the original author’s participation and sustained organizational support.

Projects that attempt rewrites without the original author lose institutional context and repeat old mistakes. Projects that attempt rewrites without organizational support stall at the prototype stage. Video.js v10 had both. The four-project merger gave the rewrite a larger addressable audience from day one, reducing the adoption problem that kills ambitious open source rewrites when the benefit is diffuse but the cost is concentrated.

The broader lesson applies to any JavaScript library built during the browser compatibility era of 2010 to 2016. The typical sources of bloat in libraries from that period fall into three categories: polyfills for browser features that are now universally supported, internal abstraction layers for behaviors that browsers now standardize, and bundle assumptions that include all functionality regardless of what any given consumer actually uses. V10 addresses all three by starting from a blank file and asking which of the original 100% was actually solving a current problem.

For developers evaluating video player choices in mid-2026, the recommendation is to follow the beta progress but not migrate production players until migration guides are published and the plugin ecosystem matures. The architectural improvements are real. The migration cost is also real. Both need to be weighed together.