VideoJS v10 - Big changes coming; input requested

[heff]

Hello VideoJS community! 👋

I’m here with an update on VideoJS v10, which will be a major revamp of the project. As we plan and build, the steering committee would love to hear any input on how you’d like to see the project improve or just change moving forward.

May 17, 2025 will be 15 years since I pushed the first version to Github, and wow have we achieved a lot:

• Millions of websites over time have used VideoJS (source Builtwith)
• Billions of end-users every month of just the CDN-hosted copy (source Fastly stats)
• 38,700 Github stars
• 928 amazing contributors to VideoJS itself
• And 573 plugins

It’s been the greatest privilege to be associated with this project and community, both of which have grown much bigger than I ever expected.

Fifteen years is a long time in Javascript land. In 2010 jQuery was just becoming the most popular library, ES5 had limited support, and Internet Explorer 8 was the most used browser. I started VideoJS to help bridge from Flash video to HTML5 video. It was actually first a tutorial on my personal blog, explaining how to build video player controls with HTML/CSS/JS, which I then rolled into a library after some people showed interest.

We’ve of course evolved VideoJS over time (remember that Closure Compiler phase?), but the tools web developers use today are much different from when the project was started. React, Typescript, and Tailwind are the most common defaults compared to the semantic HTML/CSS and vanilla JS of 2010. We think that warrants taking a big step back and considering how the project is and is not still serving the needs of modern JS, and making changes in v10 that will help VideoJS live on another 15 years. Some topics already on our minds include:

• First-class support for React and other component frameworks
• First-class TypeScript Experience
• Flexible and easily customizable UI components
• Modern styling and themes
• Bundle size, composability, and SSR
• Considerations for AI driven-development
• Playback engine improvements

Drop a note in the comments if you have thoughts on those or other topics for us to consider. 🙏

Media Chrome, too

With VideoJS I wanted people to customize their players in interesting ways, so myself and other contributors spent a lot of time making the CSS and APIs of VideoJS as accessible as we could within the limits of the platform. While I’m proud of that effort I think it had minimal success, with most VideoJS users opting for the default theme. I assume that’s because not many people had the time or interest to learn VideoJS-specific components.

With that in mind, in 2019 I went on a side quest to build Media Chrome using Web Components. I saw the opportunity to make player components that felt like simple HTML and also could be used across many JS frameworks without framework-specific wrappers. While I’ve been a web component evangelist for many years now and still consider myself one, if you’ve kept up with JS news you know they’re not clearly the silver bullet for cross-framework compatibility that I hoped. While Media Chrome continues to grow in popularity itself, this is a good moment to consider the direction ahead for both projects. I’ve always hoped they’d come together, and that’s the current plan, without specific details yet.

Corporate Shepherding

What makes this a good moment is the recent changes in the VideoJS world. Since 2012, Brightcove has been the Corporate Shepherd of VideoJS after acquiring my previous company, Zencoder. They've provided resources and support that helped the project flourish over the years. With recent organizational shifts, the Technical Steering Committee (TSC) has approved Mux (my current company) stepping in as the new Corporate Shepherd going forward.

I’m of course biased, but this feels like a natural fit as we look toward VideoJS's next chapter. I’ll be happy to spend more of my own time on VideoJS, and so will other player devs on the Mux team. Mux is all about video tech for developers, and we're passionate about supporting open source tools that make video development more accessible. The TSC is excited about this new partnership and the momentum it'll bring as we modernize VideoJS for today's dev landscape.

What’s Next

VideoJS is currently at v8 and we're going to reserve v9 for iterative API-breaking changes while we plan and build v10. Here's the roadmap we’re aiming for:

• Q2 2025 (Now - June): Community feedback gathering and v10 planning phase
• Q3 2025 (July - September): Release v9 with any iterative API-breaking changes to prepare for v10
• Q4 2025 (October - December): Alpha/beta releases of v10 with core architecture changes
• Q1 2026 (January - March): v10 stable release

This timeline gives us enough runway to reimagine VideoJS for modern development while ensuring we don't rush the process. We want to get this right.

Drop comments in this discussion if you have any feedback on where you'd like to see the project go next. 🙏

Cheers!
-heff

[gradyplayer]

I am not a JS developer, but as an outsider, it seems like a bad plan to re-write with the intention of React or any currently popular JS framework as a "first class" supported entity; a good abstraction layer that could be used to write a high quality interface to any framework seems like a better plan - but that is an uninformed comment from someone that doesn't know anything about the problem space...

[gkatsev]

I agree. I think that piece stems from meeting people where they're at. So, if they use react, they should be able to use video.js without any headaches. This, historically, has been an issue for Video.js.
I think that web components is likely a good direction because they're the new building block for the web. Plus, at this point, all these frameworks should have native support for them. Though, it may still warrant specific wrappers to account for various intricacies.
Additionally, a modular codebase that you can pick and choose what you want to include is helpful here as well.

[heff]

Yeah, I think "first-class" is probably too vague of a term and can be interpreted a number of ways. What I meant is that React has always felt like an afterthought in everything from documentation to architecture, and we don't want that to be the case anymore, not just for React but for many popular UI frameworks. I think more recent player projects have done that better, like Vidstack and Player.style.

[mihar-22]

Hey there, I wanted to chime in here too as I'll be unpacking a lot of this with the team in the coming months! I'm mostly speaking for myself here. I'm the author of an open-source player called Vidstack and I'm also currently on the Mux team. We've briefly started to review existing player architectures under our portfolio (quite a few now) as we plan ahead for v10.

I'll second what heff said in that "first-class" is vague here and it doesn't mean we're planning on centering our player architecture solely around React. I'm personally interested in an agnostic-core that would easily plug into Web Components, React, (your favourite framework). Similar to TanStack and some of the work I did in Vidstack (minus some poor decisions). Basically an architecture we can leverage to ship idiomatic primitives and hooks for any framework, not just React.

In my experience, plus what we've seen in the wild with projects like Media Chrome, while Web Components are great in theory and for certain applications, practically speaking they're not ideal for shipping a great universal developer experience. It can feel like another framework target and limited in design. It's quite an in-depth topic and hard to unpack in a comment but happy to answer specifics as we get further along.

In addition, I wouldn't want us to be locked to any single technology, framework, or environment (e.g., DOM). The web has drastically changed over the last decade. I'd like to keep ourselves flexible to how it might further change in the next decade whilst accounting for the past. I think solid abstractions centered around a well-designed core architecture will get us there. Ultimately, staying true to good software design.

This is a heavy topic and I wouldn't expect most to align with me on it immediately, hoping as I share designs and communicate more with community members that it'll become clearer. I'm not against Web Components at all (love certain parts more than others - looking at Custom Elements), I just think they have narrow applications and can't be used as the big hammer to all nails type thing. We can and should definitely still ship them, and we can even build parts of our library with them where we want strong styling encapsulation and a "drop-in" customizable experience (e.g., themes like player.style).

[cjpillsbury]

Yeah @gradyplayer we've been discussing this a lot. What I think we all agree on over at Mux at least is we should not be building a player that presumes React (which folks have been clarifying here). For folks who just need video on a framework-less, vanilla HTML + JS page, they should be able to do that (and for folks using svelte, or vue, or angularjs, etc. etc. they also should be able to use the player). However, we also want to make sure, at least as much as possible, that folks using an application framework can use the player in a way that feels idiomatic to the framework without having to jump through hoops or learn a bunch of stuff that gets in the way of them using, customizing, etc. the player. To do this to its full extent for all app frameworks is a tall ask, so we're heavily leaning towards prioritizing particular frameworks that are popular, hence React as "first class". This doesn't mean we don't/won't care about other app frameworks, but we've found that our web component solution has worked reasonably well for most of those users/use cases.

[itsjamie]

I'd consider determining browser support early in the rewrite, as it will essentially decide who can use VideoJS for what purpose.

Chrome 38 and Chrome 53 are the two big cut-off versions for a lot of the set-top / smart TV market and feature set. Making heavy use of polyfills kills the performance of the applications, so polyfilling up to the base level of support makes supporting the best video features difficult on the platforms.

I understand that it's a small percentage of users who likely care, but for example: video-dev/hls.js#4939

This made it where hls.js could be running alongside a WebGL rendered application at full framerate, to the rAF loop lagging and killing the overall application UX.

---

Essentially, is VideoJS going to target evergreen desktop / mobile users only?

[heff]

I'd love as much guidance as people can give on the specific cutoffs (like @itsjamie has started). I think @littlespex was recommending an even higher Chrome version when we were talking about this IRL yesterday.

Related question, are all new devices shipping today actually supporting the evergreen-ness of the browser they include, or in 10 years are we going to be complaining about Chrome 137 on old devices?

[gkatsev]

Just double checked, the pts/dts changeover was chrome 69 https://developer.chrome.com/blog/media-updates-in-chrome-69/#pts

But yes, TVs tend to not get updated at all. Supposedly, LG's TVs, at least the oled C and G series are supposed to be getting software updated for 3 years, which may include chromium version bumps. But personally, I'm never plugging a personal smart tv into the internet ever again...

So, yes, I expect us to be complaining about older chromium builds in 5 years time, haha. Though, hopefully, the new devices now can be supported by the newer project via transpilation/polyfills.

[cjpillsbury]

"all new devices" is gonna be a tall order, but the heavy hitters like Samsung and LG have gotten better about API compliance, firmware updates, and even aggressive nudges for said updates (even if not always motivated by the things we may want/care about). That said, unless things change, there will likely be a non-trivial number of folks who defer/delay any firmware/software updates until forced (partly understandable, because often enough these updates have negative general performance impacts on older devices). Add to that expectations from businesses, contractual obligations between device manufacturers and streaming providers, and customer expectations/awareness when they say "Top Streaming Service is garbage on (old and unupdated) Major TV Brand!" Sooo... TL;DR - It will plausibly be better but unlikely to ever be a "non-issue", at least in the foreseeable future.

[littlespex]

Chrome 70 has changeType which makes juggling source buffers a little easier.

[itsjamie]

@heff here's a quick set of reference resources

LG Web Engine Support Matrix: https://webostv.developer.lge.com/develop/specifications/web-api-and-web-engine

• covers a few of the Smart TV brands, as they're based on webOS.

Samsung Web Engine Support Matrix: https://developer.samsung.com/smarttv/develop/specifications/web-engine-specifications.html

Set-top Boxes:

• https://wpewebkit.org/
  • gstreamer-backed MSE implementation (often) in a WebKit environment, mainly standards compliant now, a lot of devices will be firmware locked like @gkatsev mentioned, but if you can support a 2018 WPE build you'll hit the majority of the market at this point (imo).
  • metrological partners
• Android Based Set Tops (FireTV etc)
  • generally, you can avoid these, they'll use Exoplayer/Media3 likely.

Another aspect that's interesting at least if you were looking at a device testing farm ala Bitmovin, but 4K TVs in the older model years have stronger chipsets, so getting the FHD (720p, 1080p) TV will get you a much more representative case for that model year.

[damanV5]

Can we add missing DASH features https://github.com/videojs/http-streaming/blob/main/docs/supported-features.md ?

[cjpillsbury]

Great callout. Playback Engines like dash.js and hls.js have done a(n understandably) much better job at keeping up with newer spec features. Figuring out an architecture that makes these updates easier and isolatable, and ideally shareable across multiple OSS projects would be ideal imo. The Common Media Library initiative/project (cc @littlespex) and similar approaches are definitely on our minds/radar for trying to make these things better and more maintainable across the community as a whole, but also for the future of things like VJS.

[englishm]

MoQ

I'd love to see, if not immediate MoQ support, at least some consideration given to having a path for adding MoQ support in the future as that ecosystem begins maturing. There are a lot of unknowns still at the "streaming format" layer, and we'll likely want to support multiple packaging formats, but thinking through the types of affordances developers may want could help us co-evolve implementations. Both moq-js and/or moq-encoder-player could be part of how this comes together.

[heff]

👍 Makes sense, and I thought the work done at Qualabs Summer Camp on this front was super cool.

How should we be thinking about this in the player architecture specifically? From the little I know I assume we'll need a dedicated "engine" for it, at the same level of HLS.js. Should we be thinking about swappable networking components or anything else?

[cjpillsbury]

hah I was thinking of you + MoQ @englishm. It's at least on my mind, but would love to do some mind melding here. @heff's thoughts/comment ☝️ are roughly mine as well in the broad strokes.

[littlespex]

I think having first class support for swappable playback engines would go a long way to help address many of the issues being discussed.

[englishm]

I assume we'll need a dedicated "engine" for it, at the same level of HLS.js

Yep, exactly! I'm hoping that moq-js, moq-encoder-player or similar can become something like HLS.js for MoQ. Technically it would be for one (or more) MoQ "streaming format" like "WARP" since the MoQT layer offers a lot of options for how media is packaged and mapped to MoQ Objects, Groups, and SubGroups.

Should we be thinking about swappable networking components or anything else?

It's at least on my mind, but would love to do some mind melding here.

In my mind, the most fruitful brainstorming would likely be around the new affordances MoQ can offer—features like configurable latency targets and prioritization, or even publishing MoQT tracks from the player to some upstream aggregation point for CMCD-like player metrics/logging or even qlog logs for low level diagnostics.

I think could be useful to map out just how developers might want to configure a player to take advantage of these capabilities and then feed that vision back into the specifications now that everything is starting to become more concrete. I think approaching this from the perspective of player UX could especially benefit WARP as it may have subtle implications for what's put in the catalog and how that information is used by players/subscribers.

Secondly, it'd be good to know what type of interface an HLS.js analog for MoQ would ideally provide, taking into account the ways in which it might be different to accommodate exposing these additional capabilities.

[littlespex]

Having first class support for swappable playback engines could go a long way to help address many of the issues being discussed. Media Chrome's custom media elements and Vidstack's media providers are good examples of this. I know VideoJS has the concept of "techs", but I'm only familiar with them at a high level. Would they be a good candidate for this, or would we need something new?

[gkatsev]

yeah, video.js techs are probably the first instance of this on the web :)
I hope we can maintain it is some form in the new version of Video.js

[cjpillsbury]

Given the folks involved (myself included), having a playback engine abstraction is highly likely for any "final form" of VJS 10+. The "tech" architecture may be a bit too presumptuous in some of its moving pieces/"connective tissue" to the rest of VJS, but the core principle of abstraction is at the very least in the right ballpark.

[tsi]

One issue that keeps coming back when dealing with video-players is the bundle size and download time.
There's only this much we can do to reduce the actual size of the full-featured player, but what we can do is introduce some sort of lazy-loading via dynamic imports, tree-shaking for ESM etc.
For example - if we could load the ABR engine lazily, and only for sources that require it, we could save a lot of bytes.