In case anyone's wondering, this website's syntax highlighting color scheme is called "gruvbox", which I quite like but took an embarrassingly long time to track down
Just want to say, thanks for the comprehensive blog post and not treating the reader like children. You did a great job explaining the differences & changes. I wish more product/project releases were done this well.
I've never used video.js, and the site/advertising seems to be fairly oriented towards people who have used it or are familiar with it.
I had one question I couldn't answer reading the site: what makes this different from the native html video element?
AFAICT just the transport controls?
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.
it just doesn’t work in every environment. every browser version has it’s own issues and edge cases. If you need stable video player or want streaming features you should use it.
P.S i built movie streaming and tv broadcasting player for country of Georgia and supported environments from 2009 LG Smart TVs to modern browsers.
Okay, what about non-streaming vid? I think the vanilla html5 <video> tag is solid, correct?
you think it’s solid until you want customization and old browser support. it should work fine if you just want to autoplay a small size mp4 file on mute
Out of curiousity, why not distribute this as a webcomponent? It's a perfect use case for it - a semantic object that has built in controls / chrome.
Ah...you're scratching at some scabs with this totally reasonable question.
We learned some tough lessons with media-chrome[1] and Mux Player, where we tried to just write web components. The React side of things was a bit of a thorn, so we created React shims that provided a more idiomatic React experience and rendered the web components...which was mostly fine, but created a new set of issues. The reason we chose web components was to not have to write framework-specific code, and then we found ourselves doing both anyway.
With VJS 10 I think we've landed on a pretty reasonable middle ground. The core library is "headless," and then the rendering layer sits on top of it. Benefit is true React components and nice web components.
Is it not a web component, per se? Per the article, all the React stuff does seem to bake down to HTML Custom Elements, that get wired up by some client-side JS registering for them. That client-side JS is still a "web component", even if it's embedded inside React SPA code bundle, no?
If you mean "why do I need React / any kind of bundling; why can't I just include the minified video.js library as a script tag / ES6 module import?" — I'm guessing you can, but nobody should really want to, since half the point here is that the player JS that registers to back the custom elements, is now way smaller, because it's getting tree-shaken down to just the JS required to back the particular combination of custom elements that you happen to use on your site. And doing that requires that, at "compile time", the tree-shaking logic can understand the references from your views into the components of the player library. That's currently possible when your view is React components, but not yet possible (AFAIK) when your view is ordinary HTML containing HTML Custom Elements.
I guess you could say, if you want to think of it this way, that your buildscript / asset pipeline here ends up acting as a web-component factory to generate the final custom-tailored web-component for your website?
Probably not base case but a quick test to replace my audio player (currently using Plyr) turned up the following gaps for me, at least with the out-of-the-box code.
1. No playback rates under 1
2. No volume rocker on mobile
3. Would appreciate having seek buttons on mobile too
4. No (easily apparent) way to add an accent color, stuck with boring monochrome
5. Docs lacked clear example/demo/playground so I wasn't sure what it would look like until implemented
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.
Congrats Steve! I haven't touched video since I was at JW Player a million years ago, but I always inspired by the simplicity of video.js (especially the theming).
Hope this new iteration is exceptionally successful.
Oh hi Zach! Blast from the past. Hope you’re doing well and thanks for the well wishes. Always enjoyed chatting you and the JW team at FOMS and conferences. The water’s warm back here in video tech if you ever want to jump back in!
The feature-array approach to createPlayer is smart. We did something similar splitting a monolith into per-feature packages and the hardest part wasn't the split itself, it was figuring out where the boundaries go. Two features look independent until you realize they share some piece of state that neither wants to own. Curious how they handle cross-feature state deps here.
Hey VJS core contributor here. We definitely feel that concern and we also don't yet have a silver bullet formalized. I suspect we'll need some kind of alternate implementations or feature augmentation at some point. We're currently doing things in a bit more ad hoc way, such as the interrelationship between PiP and Fullscreen (see, e.g.: https://github.com/videojs/v10/blob/main/packages/core/src/d...).
One other thing to note: because the features are "composed", we at least have a lot of flexibility here that makes me feel pretty good about the fundamentals and not "coding ourselves into a corner" here.
Yeah the composability buys you a lot of room. One central store with events, inject it into each feature, and they stay decoupled without painting yourself in.
Please stop posting AI-generated comments. Your post history is full of them.
Just a dev who's built the stuff I talk about. Pretty sure you already know that though, buddy.
What?
I just happened to try v10 yesterday for HLS and it's looking great so far.
Awesome to hear!
This is amazing. We also kind of created a Player context provider and was using it to maintain/mutate player state globally. If its possible to also share any examples related to player events and new way to register plugins in V10, that would also help better understand the overall picture.
I was just lamenting the other day about the size of video.js, which is used in my legacy web app, and looking for a way to improve that. Very keen to explore how we could migrate to v10!
Drop a note in discussions or issues! Would love to hear what you’re working with.
I am curious, why would anyone pick HLS over Dash in these days?
Granted, my knowledge on the matter is rather limited, but I had some long running streams (weeks) and with HLS the playlist became quite large while with dash, the mpd was as small as it gets.
It's still mandatory for all but the newest iOS devices, which don't support MediaSourceExtensions.
This is true, and the whole iOS/iPadOS/tvOS ecosystem supports HLS natively making it much easier to work with on that platform. In addition, Chrome recently added support for HLS[1] (and not DASH), so the native browser support for HLS is getting pretty wide.
HLS also has newer features that address the growing manifest issues you were seeing. [2]
All that said, I think a lot of people would feel more comfortable if the industry's adaptive streaming standard wasn't completely controlled by Apple.
How do you actually use HLS in the form of a native browser feature? Can you just put the m3u8 in the video src?
Looking great. I'll give it a try later on once things stabilize a bit. In the meantime, does anyone know what's going on in this space? Seems to me like a lot is changing over the past year. Eg: react-player new version, taken over by Mux. And also I did realize Video.js is sponsored by Mux. And also seemingly different companies working together.
OP and Mux co-founder here so have all the context on this. A lot has changed. Mux stepped in to help maintain React Player a few years ago. It wasn't getting frequent updates and Mux has a vested interest in the whole OSS player ecosystem (even if we didn't built it) because Mux Video (hosting) is player agnostic, and we get support requests for all of them. @luwes from Mux did the work to get to the new version, while making it possible to use Media Chrome media elements with React Player and consolidating some development efforts. We're still a tiny player team so that was important.
There are no immediate plans to deprecate React Player and I think it holds a special place in the ecosystem, but there will be overlap with video.js v10 and if there's specific features you care about or feel are missing, or if you think we're doing a bad job, please voice it here.
It was a similar story with Vidstack and Plyr, with Mux first sponsoring the projects. That's how I met Rahim and Sam, and how we got talking about a shared vision for the future of players.
Very nice! I switched off video.js some time ago because it kept giving me trouble. Looking forward to trying this new version.
Thank you! I’m on the Video.js team, and we’d love for you to try the library out and share your feedback. We’re especially eager to hear from developers who used or tried v8 in the past.
We’re taking a new approach to the library with a lot of new concepts, so your feedback would help us a ton during Beta as we figure out what’s working well and what isn’t.
This is very cool, but I'm confused why the React player is smaller than the HTML player. What's actually in the size comparison there?
It’s largely because (1) the React runtime is not bundled so it’s technically not apples to apples, (2) the Web Component includes CSS as well since we’re using Shadow DOM.
Basically few kB for CSS and few kB for a thin “framework” layer for managing attr to prop mapping, simple lifecycle, context, and so on.
Are there any plans to support other frontend frameworks? If I wanted to use it today in something like svelte how should I go about it?
We are designing with the goal of supporting more frameworks like Svelte and Vue specifically, even as far as React Native! We just don’t know when exactly yet but a large part of our approach in v10 is to make sure we can deliver the best possible experience to each frontend framework. It’s important for us that the integrations don’t feel like wrappers but truly idiomatic.
In the meantime, we’re hoping our custom elements will act as a good stopgap. Most frameworks including Svelte support them well, and we’re pouring love into the APIs so they feel good to use regardless of which framework.
If you’re interested in peeking under the hood, architecturally we’re taking a similar approach to TanStack and separating out a shared core from the beginning, but with one added step of splitting out the DOM as well to aid in supporting RN one day.
Absolutely love what you and your friends have built. Great work! Will give it a spin.
I'm on the Video.js team, just wanted to say thank you! Means a lot and we'd be eager to hear your experience trying it out. Feel free to drop a GitHub issue or discussion post if you ever get a chance :)
From me, this is a massive relief after we just deployed a bunch of videos to Vimeo. The next week they were bought.
I'm a one-man operation. In the order of hundreds of videos served a week. All I want is control over my own destiny. If this and a VPS can do that, that'll be amazing. Thank you for doing this.
If you need more than a VPS can provide (like a real CDN), you can check us out on Swarmify.com. It might be overkill for your use case, though.
We'll be moving to videojs 10 when it hits GA.
Very nice. Good Luck!
Did the private equity buy the domain videojs.org (did it take control of the project and you somehow regained control after selling) or was this domain (and the project) always under your control?
Seeking on the main https://videojs.org/ page doesn't work for me on chromium.
Throws Uncaught (in promise) TypeError: AbortSignal.any is not a function on volume-slider-data-attrs.BOpj3NK1.js
Hey there, on the Video.js team. What browser and version did you run into this on?
114, Ungoogled Chromium to be specific. Happy to share more info if you need it
I have that ticketed up for you [1], and I'll look into it tomorrow. Thank you!
can anyone recommend me good, battle-tested "slider" solution for playing videos as well as displaying images from single gallery? ideally capable of handling huge galleries (hundreds of items) with lazy loading
Not a today answer, but this is something I'm excited to build within the new Presets concept of video.js v10, where we can build specific "video interfaces" beyond a standard player using the composable architecture.
I've used https://yet-another-react-lightbox.com/ in anger and it's great, very extensible too.
That only works in React though.
this is lovely work
Thank you!
Serious question. We currently have this tool in our framework, that we use to play videos from youtube, vimeo, and a whole lot of other sites:
https://github.com/Qbix/Platform/blob/main/platform/plugins/...
We currently already use video.js, and our framework us used all over the place, so we’d be the perfect use case for you guys.
How would we use video.js 10 instead, and for what? We would like to load a small video player, for videos, but which ones? Only mp4 files or can we somehow stream chunks via HTTP without setting up ridiculous streaming servers like Wowsa or Red5 in 2026?
That's great! It looks like you have a pretty extensive integration with the prior version of Video.js, so migrating will take some work, but I think worth it when you can make the time. That said, for Beta it works with browser-supported formats and HLS, with support for services like Youtube and Vimeo close behind as we migrate what we haver in the Media Chrome ecosystem[1]. So if that's what you need maybe hold your breath for a few weeks.
What are you supporting today that requires Wowza or Red5? The short answer is Video.js is only the front-end so it won't help the server side of live streaming much. I'm of course happy to recommend services that make that part easier though.
Thank you for your feedback. Yep I definitely understand that Video.js is just the front end. I want to avoid using Wowza / Red5 and just want to serve chunks of video files, essentially, buffering them and pasting them to the "end of the stream" laying down tracks ahead of the video.js train riding over those tracks.
So I'm just wondering whether we can do streaming that way, and video.js can "just work" to play the video as we fetch chunks ahead of it ("buffering" without streaming servers, just basic HTTP range requests or similar).
You should check out HLS and DASH. If you're already familiar and you're not using them because they don't meet your requirements, then apologies for the foolish recommendation. If not, this could solve your problem.