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!
So fun seeing all these familiar names pop up in a single thread, haven't been active in video after leaving Kaltura but have fond memories of FOMS/FOSDEM and meeting all of you!
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.
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
I'm not familiar with video hosting but have played with html5 video player but I have this question: on the servers side, do I have to host a specific endpoint that serves chunks of video? Lets say I take 720p video @ 800mb and I chunk it into 2mb pieces with ffmpeg. So I have a folder somewhere (webserver, cdn, blob storage) with the original 4K video, then generate downscaled versions for 1440p, 1080p, 720p, so I end up with 4 large files, and then for each of those, I chunk them into reasonable sizes that aligns with bitrates / key frames. And then some thumbnail generation. Any advise on what the "best" way would be to chunk/host video files so that videojs runs the best and smoothest? I feel that I should build a very lean/fast chunk & thumbnail server, just one or two endpoints. Or is it best to let the webserver do the lifting? Or off-the-shelf media servers (like in the self-hosting community)?
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.
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?
Sibling comment didn't elaborate, but I think they might be onto something.
It happened to me personally - LLMs and agentic coding tools enabled me to pick up old side projects and actually finish them. Some of these projects were in the drawer for years, and when Sonnet 4 released I gave them another try and got up to speed really quickly. I suspect this happened to many developers.
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
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?
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!
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.
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.
As someone who uses VideoJS on a website with a large video library, and has generally been dismayed at the state of the plugin ecosystem every time I consider doing a major version upgrade of VideoJS, this kind of thing is great to hear.
I see you promoting that the looks are consistent across browsers. I've seen several other video players that are browser dependent because of particular JS features used. Are future features going to remain browser agnostic?
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.
Why does the bundle size matters when playing 3MB+ videos anyway? Curious how I could integrate one of these players without polluting my bundle with duplicates :)
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
137 comments
Hope this new iteration is exceptionally successful.
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?
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.
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.
(And why does that matter? Dynamic bitrate adjustment. The chunks are slightly easier to cache as well.)
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
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?
It happened to me personally - LLMs and agentic coding tools enabled me to pick up old side projects and actually finish them. Some of these projects were in the drawer for years, and when Sonnet 4 released I gave them another try and got up to speed really quickly. I suspect this happened to many developers.
https://github.com/morhetz/gruvbox
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?
Throws Uncaught (in promise) TypeError: AbortSignal.any is not a function on volume-slider-data-attrs.BOpj3NK1.js
I hope the plugin directory get an overhaul too and a prominent place an the webpage. The plugin ecosystem was for me a huge benefit for Video.js
Even though some of them are outdated, they were a good source of inspiration.
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.