Heff

Can you give an example of a player/feature combo where this is the case? For general player features there's not really an excuse for only working in one browser, but features like Casting can be browser dependent because the browser has to expose that functionality. Other interesting prototypes rely on a new API called Web Codecs that isn't fully supported everywhere.

In the core JS of Video.js v10 we're building without the assumption of there even being a browser involved so we can point to future JS-based platforms like React Native.

This is great. Keep it coming.

Thank you!

Absolutely! The community has always been the strongest part of the project.

In the new version the core player itself is built as many composable components rather than one monolithic player, so we're going to invite more people to contribute their "plugins" to the core repo as more of those composable components. Versioning plugins and keeping them up to date has always been a challenge, so we're thinking this will help keep the whole ecosystem working well together.

The biggest architectural move at multiple layers of the stack was moving from monolithic controller objects to composable, tree-shakeable components, functions and state slices. Less trade-offs and more taking advantage of modern JS bundlers.

Full rewrite and an intentional architecture to allow for composability and tree shaking, meaning the player bundle only ever includes the features you're using.

Something AI has done for Video.js is allow us to set our sights higher, with the about the same size team. Specifically aiming for idiomatic components and patterns for each popular JS framework (React, Svelte, Vue, React Native), not just web component wrappers (though I still love web components on their own).

I’m not sure which user we’re talking about, but it’s up to the video.js user to decide if and when they use ads. Just like it’s up to YouTube. Video can get expensive, so some video wouldn’t exist without some form of monetization.

Fair point, we could answer that more directly on the site. Besides the comparison were there other things that make it seem oriented to people already familiar with it?

Generally, the video tag is great and has come a very long way from when Video.js was first created. If the way you think about video is basically an image with a play button, then the video tag works well. If at some point you need Video.js, it'll become obvious pretty quick. Notable differences include:

* Consistent, stylable controls across browsers (browsers each change their native controls over time)

* Advanced features like analytics, ABR, ads, DRM, 360 video (not all of those are in the new version yet)

* Configurable features (with browsers UIs you mostly get what you get)

* A common API to many streaming formats (mp4/mp3, HLS, DASH) and services (Youtube, Vimeo, Wistia)

Of course many of those things are doable with the video tag itself, because (aside from the iframe players) video.js uses the video tag under the hood. But to add those features you're going to end up building something like video.js.

All solid feedback, thanks! I'm making sure these get captured as issues. Otherwise we're closely tracking feature parity with Plyr (and other players) and our goal is to have full parity by GA, aiming for the middle of the year.