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

https://github.com/morhetz/gruvbox

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?

Genuinely didn't expect 88% — what was the biggest win? Guessing it was the plugin system since that thing was a mess. Also curious if you broke any of the major integrations during the rewrite or managed to keep them intact.

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)?

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.

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

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.

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.

What were the biggest architectural changes in the rewrite, and what tradeoffs did you make compared to the old Video.js design?

88% reduction is wild. Did most of that come from eliminating dependencies or rewriting core components from scratch?

Awesome! And thank you all for your projects and your hard work!

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.

I just happened to try v10 yesterday for HLS and it's looking great so far.

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!

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.

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.

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.

Very nice! I switched off video.js some time ago because it kept giving me trouble. Looking forward to trying this new version.

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?

Absolutely love what you and your friends have built. Great work! Will give it a spin.

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?

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?

Wow, 88%. Why are you heiling hitler with this HN post?

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

this is lovely work

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

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?

88% smaller is remarkable, but what really stands out to me is the decision to come back after 16 years and actually do the rewrite. Most abandoned projects just stay abandoned.

Video handling on the web is still surprisingly painful in 2026 -- between codec fragmentation, adaptive bitrate, and accessibility requirements. Having a maintained, lightweight player that handles the hard parts is genuinely valuable. Looking forward to trying this on a couple of projects where I am currently using a bloated custom setup.

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[flagged]