9 ms·

Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

648 points by Heff 6mo ago

What do you do when private equity buys your old company and fires the maintainers of the popular open source project you started over a decade ago? You reboot it, and bring along some new friends to do it. Video.js is used by billions of people every month, on sites like Amazon.com, Linkedin, and Dropbox, and yet it wasn’t in great shape. A skeleton crew of maintainers were doing their best with a dated architecture, but it needed more. So Sam from Plyr, Rahim from Vidstack, and Wes and Christain from Media Chrome jumped in to help me rebuild it better, faster, and smaller. It’s in beta now. Please give it a try and tell us what breaks.

esprehn 6mo ago
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?
- rahim_alwer 6mo ago
  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.
hikaru_ai 6mo ago
[dead]
lexro_ai 6mo ago
[flagged]
- cpillsbury 6mo ago
  Hey there, core contributor here! Starting with the last one first, since that's the easiest - VJSv10 is basically a completely new player, so no backwards compatibility planned (think Mac <=OS9 vs. OSX). We're aiming to port some of the popular plugins though and have discussed other things like migration guides and the like. For the primary question - this is a tough one, specifically because v10 is a completely new, ground up architecture. Part of this will be feature parity - v8 does many things/handles many cases that v10 doesn't do yet. That may seem like that is an unfair comparison, and, in some sense, that's true. However, this is in fact part of the ethos of our new architecture: by building a highly composable, loosely coupled player framework with well defined architectural "seams"/contracts, you can more easily pull in "all and only what you need for your use case" (a phrase I've been bandying about). While v8 allows for some of this, it's still much harder and you still end up pulling in stuff you probably don't need for a lot of use cases. Another one is the UI layer - v8 ended up building an entire component implementation. At the time of building, it kind of had to. v10, on the other hand, can "stand on the shoulders of giants", building on top of e.g. custom elements, or React, or any future frameworks we decide to target (and our architecture makes that comparatively easy as well). I do suspect that once we hit true feature parity, the numbers will be much closer for "the kitchen sink." The thing is, few people (if any) need the kitchen sink. Thanks for the tough question!
nakodari 6mo ago
Absolutely love what you and your friends have built. Great work! Will give it a spin.
- rahim_alwer 6mo ago
  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 :)
  - jen729w 6mo ago
    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.
    - KingMob 6mo ago
      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.
    - pjc50 6mo ago
      You absolutely can do that with videojs, it's very easy. Might need to consider bandwidth and the usual mitigation against scrapers if you're serving video unauthenticated.
sam_goody 6mo ago
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?
thedanbob 6mo ago
Very nice! I switched off video.js some time ago because it kept giving me trouble. Looking forward to trying this new version.
- rahim_alwer 6mo ago
  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.
michaelsalim 6mo ago
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.
- Heff 6mo ago
  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.
grzes 6mo ago
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
- bananadonkey 6mo ago
  I've used https://yet-another-react-lightbox.com/ https://yet-another-react-lightbox.com/ in anger and it's great, very extensible too.
  - spankalee 6mo ago
    That only works in React though.
- Heff 6mo ago
  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. https://videojs.org/docs/framework/react/concepts/presets https://videojs.org/docs/framework/react/concepts/presets
rcakebread 6mo ago
I just happened to try v10 yesterday for HLS and it's looking great so far.
- rahim_alwer 6mo ago
  Awesome to hear!
leontloveless 6mo ago
[dead]
jjcm 6mo ago
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.
- derefr 6mo ago
  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?
  - pjc50 6mo ago
    You certainly can just add it to a <script> tag and then not do any of that.
- mmcclure 6mo ago
  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. [1] https://github.com/muxinc/media-chrome https://github.com/muxinc/media-chrome
zacharyozer 6mo ago
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.
- Heff 6mo ago
  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!
  - theMMaI 6mo ago
    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!
devnotes77 6mo ago
[dead]
gorbiesRedScar 6mo ago
this is lovely work
- rahim_alwer 6mo ago
  Thank you!
nulltrace 6mo ago
[flagged]
- cpillsbury 6mo ago
  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/dom/store/features/fullscreen.ts https://github.com/videojs/v10/blob/main/packages/core/src/d...).
  - cpillsbury 6mo ago
    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.
    - nulltrace 6mo ago
      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.
- blanched 6mo ago
  Please stop posting AI-generated comments. Your post history is full of them.
  - nulltrace 6mo ago
    Just a dev who's built the stuff I talk about. Pretty sure you already know that though, buddy.
    - efilife 6mo ago
nchmy 6mo ago
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!
- Heff 6mo ago
  Drop a note in discussions or issues! Would love to hear what you’re working with. https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions
EGreg 6mo ago
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/Q/web/js/tools/video.js 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?
- Heff 6mo ago
  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. [1] https://github.com/muxinc/media-elements https://github.com/muxinc/media-elements
  - EGreg 6mo ago
    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).
    - colonCapitalDee 6mo ago
openclaw01 6mo ago
[dead]
taosx 6mo ago
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?
- rahim_alwer 6mo ago
  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.
gnulinux996 6mo ago
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.
- KingMob 6mo ago
  It's still mandatory for all but the newest iOS devices, which don't support MediaSourceExtensions.
  - Heff 6mo ago
    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. [1] https://caniuse.com/http-live-streaming https://caniuse.com/http-live-streaming [2] https://www.mux.com/blog/low-latency-hls-part-2 https://www.mux.com/blog/low-latency-hls-part-2
    - Retr0id 6mo ago
      How do you actually use HLS in the form of a native browser feature? Can you just put the m3u8 in the video src?
      - pjc50 6mo ago
        Yes, doing that works perfectly. If you use videojs it will automatically use native support if present.
- cpillsbury 6mo ago
  Core VJS contributor here and builder of players and playback engines for too long (aka before HLS and MPEG-DASH were a thing). As others mentioned, the support matrix for HLS is very typically the proximate, pragmatic reason why folks will reach for HLS over DASH in a "pick one" situation. You're right that HLS is particularly bad for 24/7, long lived DVR/"EVENT" (to use HLS jargon) streams (fine for live, and there are some "cheats" you can do for EVENT to help there) compared to MPEG-DASH's <SegmentTemplate>-based "dynamic" MPEG usage. Outside of that, though, the standards themselves have different pain points and tradeoffs. Some things are "cleaner"/"less presumptuous" in DASH, but DASH also has a lot of design details that were both "design by committee" (aka different competing interests resulting in a spec that has arguably too many ways to do the same thing) and overrepresented by server-side folks (so many playback complexities/concerns/considerations weren't thought through). It is also sometimes not constrained enough, at least by default (things like not guaranteeing time alignment across media representations). For what it's worth, I think there are lots of pain points from the HLS design decisions as well, but focusing on DASH here just given the framing of your question. On the flip side, if you stay within certain bounds, the difference between HLS and DASH simply become text files: one XML manifest (MPD) for DASH and a few playlists (M3U8s) for HLS. There's a lot of effort being made to this end, including: https://cdn.cta.tech/cta/media/media/resources/standards/cta-5005-a-final.pdf https://cdn.cta.tech/cta/media/media/resources/standards/cta... and the CMAF-HAM-inspired model (https://github.com/streaming-video-technology-alliance/common-media-library/tree/main/libs/cmaf-ham https://github.com/streaming-video-technology-alliance/commo... from CML and https://github.com/videojs/v10/blob/main/packages/spf/src/core/types/index.ts https://github.com/videojs/v10/blob/main/packages/spf/src/co... in our own playback engine library), just to name a few.
naseemali925 6mo ago
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.
- rahim_alwer 6mo ago
  Hey there, I'm on the Video.js team! Sounds like your context provider approach is already in the right ballpark! Some background: our store[1] which was inspired by Zustand[2] is created and passed down via context too. This is the central state management piece of our library and where we imagine most devs will build on for extending and customizing to their needs. Updates are handled via simple store actions like `store.play()`, `store.setVolume(10)`, etc. Those actions are generally called in response to DOM events. On the events side of things, rather than registering event listeners directly, in v10 you'd subscribe to the store instead. Something like `store.subscribe(callback)`, or in React you'd use our `usePlayer`[3] hook. The store is the single source of truth, so rather than listening to the underlying media element directly, you're observing state changes. --- So far with v10 we haven't been thinking about "plugins" in the traditional sense either. If I had to guess at what it would look like, it'd be three things: 1. Custom store slices[4] so plugins can extend the store with their own state and actions 2. A middleware layer that plugs into the store's action pipeline so a plugin could intercept or react to actions before or after they're applied, similiar to Zustand middleware, or even in some ways like Video.js v8 middleware[5] 3. UI components that plugins can ship which use our core primitives for accessing the store, subscribing to state, etc. I believe that'd cover the vast majority of what plugins needed in v8. We haven't nailed down the exact API yet but that's the direction we're leaning towards. We're still actively working on both the library and our docs so I don't have somewhere I can link to for these just yet (sadly)! We're likely targeting sooner, but GA (end of June) is the deadline. I should also add... one thing we prototyped early on that may return: tracking end-to-end requests through the store. A DOM event triggers a store action like play, which calls `video.play()`, which then waits for the media event response (play, error, etc.). It worked really well and lines up nicely with the middleware direction. [1]: https://github.com/videojs/v10/tree/main/packages/store https://github.com/videojs/v10/tree/main/packages/store [2]: https://github.com/pmndrs/zustand https://github.com/pmndrs/zustand [3]: https://videojs.org/docs/framework/react/reference/use-player https://videojs.org/docs/framework/react/reference/use-playe... [4]: https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#slices-pattern https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#sli... [5]: https://legacy.videojs.org/guides/middleware/ https://legacy.videojs.org/guides/middleware/
bl4kers 6mo ago
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
- Heff 6mo ago
  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.
  - robin_reala 6mo ago
    If we’re doing feedback, then: - On Mac with Increase Contrast turned on in accessibility settings the control bar ends up being white-on-light-grey - When focusing the volume control with a keyboard, you can only mute or un-mute, not use up or down to adjust the volume. To do that you have to tab again into the volume slider field - Don’t seem to be able to enter picture-in-picture mode with the keyboard - Purely from a first class citizen point of view, it’d be nice to have all the accessibility options (transcripts, etc) shown in the homepage demo
    - Heff 6mo ago
      This is great. Keep it coming.
rendaw 6mo ago
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?
- nshelia 6mo ago
  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.
  - truetraveller 6mo ago
    Okay, what about non-streaming vid? I think the vanilla html5 <video> tag is solid, correct?
    - nshelia 6mo ago
      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
    - phantomathkg 6mo ago
      If all you want is a fix non-streaming, video, yes. Video tag just work. Video.js is catered for those required streaming.
- Heff 6mo ago
  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.
efilife 6mo ago
Seeking on the main https://videojs.org/ 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
- rahim_alwer 6mo ago
  Hey there, on the Video.js team. What browser and version did you run into this on?
  - efilife 6mo ago
    114, Ungoogled Chromium to be specific. Happy to share more info if you need it
    - rahim_alwer 6mo ago
      I have that ticketed up for you [1], and I'll look into it tomorrow. Thank you! [1]: https://github.com/videojs/v10/issues/1120 https://github.com/videojs/v10/issues/1120
rezmason 6mo ago
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 https://github.com/morhetz/gruvbox
- jxmesth 6mo ago
  Any idea what the website's built with? I really like the design/UI tbh
  - Cthulhu_ 6mo ago
    The HTML generator meta tag (f11 to open dev tools) says it's Astro: https://astro.build/ https://astro.build/
  - deleted 6mo ago
    [deleted]
  - deleted 6mo ago
    [deleted]
  - deleted 6mo ago
    [deleted]
  - genezeta 6mo ago
    As the sibling comment mentions, it's Astro: https://github.com/videojs/v10/tree/main/site https://github.com/videojs/v10/tree/main/site
    - nihiven 6mo ago
      Looks cool, reminds of a VHS box. Also nails the look of 70s decor that was everywhere when I was growing up in the 80s/90s.
- deepriverfish 6mo ago
  it's also available in vscode
BatteryMountain 6mo ago
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.
unit149 6mo ago
[dead]
suoer 6mo ago
[flagged]
BatteryMountain 6mo ago
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)?
- nickmyersdt 6mo ago
  [dead]
- Xenoamorphous 6mo ago
  Maybe look at MPE-DASH?
- pjc50 6mo ago
  Just convert it to HLS, which is naturally chunked at 1-2 second intervals, and serve all the pieces from nginix. No dynamic content needed. I do this with videojs and it works great. Added bonus of HLS is that my LG TV supports it natively from <video> tags.
- panstromek 6mo ago
  If you don't need to switch versions at runtime (ABR), you don't even need to chunk it manully. Your server has to support range requests and then the browser does the reasonable thing automatically. The simplest option is to use some basic object storage service and it'll usually work well out of the box (I use DO Spaces with built-in CDN, that's basically it).
  - pjc50 6mo ago
maniacsudip 6mo ago
[dead]
maniacsudip 6mo ago
[dead]
progx 6mo ago
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.
- Heff 6mo ago
  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.
mitul005 6mo ago
[flagged]
rsmtjohn 6mo ago
[flagged]
- efilife 6mo ago
  LLM
- pieterhg 6mo ago
  Top reply on an HN thread is an AI bot, what a time @dang
- deleted 6mo ago
  [deleted]
EdgeNRoots 6mo ago
88% reduction is wild. Did most of that come from eliminating dependencies or rewriting core components from scratch?
- k4rli 6mo ago
  Opening the article and reading beyond the title would answer that question.
- Heff 6mo ago
  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.
swaminarayan 6mo ago
What were the biggest architectural changes in the rewrite, and what tradeoffs did you make compared to the old Video.js design?
- Heff 6mo ago
  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.
M4v3R 6mo ago
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.
- c16 6mo ago
  Absolutely the case for me. Small fun projects that would take a few hours to round off a feature can now be done in an hour. Why wouldn't i finish it off?
- Heff 6mo ago
  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).
- dang 6mo ago
  (We detached this subthread from https://news.ycombinator.com/item?id=47514723 https://news.ycombinator.com/item?id=47514723 so it wouldn't go down with that ship)
fede_dp 6mo ago
[dead]
rdevilla 6mo ago
[flagged]
- tomhow 6mo ago
  Please don't do this here.
tuukkah 6mo ago
Has the WebVTT story changed? I once tried to customize the subtitle rendering but it seemed too difficult.
- Daiz 6mo ago
  I would also be interested in this. Subtitle presentation is something where browsers are still generally very bad at out of the box, so having good subtitle rendering support built directly into the library would make a lot of sense to me. As someone with a lot of knowledge on this subject, I would be very much willing to help at least draft design documents for something like this, if not more.
  - cpillsbury 6mo ago
    Hey there, core contributor here! This came up during our beta effort. We very likely will be having an opt-in, non-native subtitles rendering implementation. I know at least a few team members that really want it, which adds to the likelihood that we'll add it eventually. The short version of why we started with native subtitles - bundle size and legal compliance, with a dash of prioritization and a sprinkle of hope that some looming laws will motivate browser owners to prioritize improvements. If you want to see our design decision artifact on the topic, we try to make a lot of them public (also to help the robots these days) - https://github.com/videojs/v10/blob/main/internal/decisions/captions.md https://github.com/videojs/v10/blob/main/internal/decisions/...
    - tuukkah 6mo ago
      That's great news. Thank you for sharing the resource!
wei03288 6mo ago
[dead]
Serhii-Set 6mo ago
[flagged]
ronak_parmar 6mo ago
Great Work, Loved the approach.
- Heff 6mo ago
  Thank you!
moci 6mo ago
[dead]
leontloveless 6mo ago
[dead]
dylan604 6mo ago
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?
- Heff 6mo ago
  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.
  - dylan604 6mo ago
    There have been other video players that attempt to be more "professional" adding things like audio meters and other tools. These are using parts of JS that is not available anywhere except in Chrome. After digging in, there's a lot of audio related things that Chrome is trying to do that FF/Safari are not. We have mp4 files with multiple audio streams that Chrome exposes ability to select from while FF/Safari do not. Creating waveforms on the fly from a video source also becomes problematic. We've also had issues getting frame accuracy when navigating the video stream. There's some sort of "security" that randomizes/rounds the returned value of currentTime that I cannot wrap my head around as how that is security related. Lots of effort spent on getting stock HTML5 video element to be frame accurate.
    - cpillsbury 6mo ago
      Core contributor here! FYI these kinds of cases are definitely on my mind. One of the nice things about our overarching architecture is we (or someone else, even you!) can add/extend for these kinds in a way that doesn't deeply "bake them in" to core use cases but still makes it completely possible to add. From "soup to nuts" (to extend my food metaphors), we've built VJS in a "highly composable" manner, which means we can, say, add state features, add UI for those state features, extend media renderers to expose those features to the state (if/when needed), etc. etc. If you want to start a discussion picking a concrete Chrome-only API, I'd encourage it (https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions). I don't know if/when we'll prioritize these things as part of the "core library", given our higher priorities of "feature parity" and core functionality, but we're already well situated for these kinds of cases (I'm sure we'll encounter and need to figure out some wrinkles along the way, but I'm confident these will generally be tractable).
moi2388 6mo ago
Cool. The video tag with ads. Thats what we need /s
01jonny01 6mo ago
It would be good if videoJS had youtube embed api and documentation like Plyr has
- Heff 6mo ago
  In the works! You should be able to use the existing <youtube-video-element> [1] with the HTML side of v10 today, but we're working on porting over the other media elements into the new architecture for better React support. [1] https://www.npmjs.com/package/youtube-video-element https://www.npmjs.com/package/youtube-video-element [2] https://github.com/muxinc/media-elements https://github.com/muxinc/media-elements
  - 01jonny01 6mo ago
    It will be interesting to see how you handle acces to youtube player settings and cc. This is where other player wrappers fall down. Plyr did a good job of removing the branding via some clever css, but its annoying you cannot access settings and cc. One idea for a cc button is to always have cc on and then toggle the height styling to show/hide it
jacobgkau 6mo ago
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.
- Heff 6mo ago
  Drop a note in the discussions some time. I'd love to hear about what you're doing and even help migrate when the time is right for you. https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions
mc007 6mo ago
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 :)
- luwes 6mo ago
  VJS contributor here. It still matters for the page load time and start up time of the video which could be important to engage the user quick enough depending on the use case. We hint at this in the home page under the v10 is built different title. By importing the player bundle with the same import path via ESM in your bundle build it should deduplicate automatically. Hope this helps!
ruthven-elara 6mo ago
[dead]
devnotes77 6mo ago
[dead]
derodero24 6mo ago
[flagged]
johnwhitman 6mo ago
[flagged]

648 points by Heff 6mo ago

esprehn 6mo ago

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?

rahim_alwer 6mo ago
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.

hikaru_ai 6mo ago

[dead]

lexro_ai 6mo ago

[flagged]

cpillsbury 6mo ago
Hey there, core contributor here! Starting with the last one first, since that's the easiest - VJSv10 is basically a completely new player, so no backwards compatibility planned (think Mac <=OS9 vs. OSX). We're aiming to port some of the popular plugins though and have discussed other things like migration guides and the like. For the primary question - this is a tough one, specifically because v10 is a completely new, ground up architecture. Part of this will be feature parity - v8 does many things/handles many cases that v10 doesn't do yet. That may seem like that is an unfair comparison, and, in some sense, that's true. However, this is in fact part of the ethos of our new architecture: by building a highly composable, loosely coupled player framework with well defined architectural "seams"/contracts, you can more easily pull in "all and only what you need for your use case" (a phrase I've been bandying about). While v8 allows for some of this, it's still much harder and you still end up pulling in stuff you probably don't need for a lot of use cases. Another one is the UI layer - v8 ended up building an entire component implementation. At the time of building, it kind of had to. v10, on the other hand, can "stand on the shoulders of giants", building on top of e.g. custom elements, or React, or any future frameworks we decide to target (and our architecture makes that comparatively easy as well). I do suspect that once we hit true feature parity, the numbers will be much closer for "the kitchen sink." The thing is, few people (if any) need the kitchen sink. Thanks for the tough question!

nakodari 6mo ago

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

rahim_alwer 6mo ago
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 :)
- jen729w 6mo ago
  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.
  - KingMob 6mo ago
    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.
  - pjc50 6mo ago
    You absolutely can do that with videojs, it's very easy. Might need to consider bandwidth and the usual mitigation against scrapers if you're serving video unauthenticated.

sam_goody 6mo ago

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?

thedanbob 6mo ago

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

rahim_alwer 6mo ago
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.

michaelsalim 6mo ago

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.

Heff 6mo ago
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.

grzes 6mo ago

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

bananadonkey 6mo ago
I've used https://yet-another-react-lightbox.com/ https://yet-another-react-lightbox.com/ in anger and it's great, very extensible too.
- spankalee 6mo ago
  That only works in React though.
Heff 6mo ago
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. https://videojs.org/docs/framework/react/concepts/presets https://videojs.org/docs/framework/react/concepts/presets

rcakebread 6mo ago

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

rahim_alwer 6mo ago
Awesome to hear!

leontloveless 6mo ago

[dead]

jjcm 6mo ago

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.

derefr 6mo ago
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?
- pjc50 6mo ago
  You certainly can just add it to a <script> tag and then not do any of that.
mmcclure 6mo ago
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. [1] https://github.com/muxinc/media-chrome https://github.com/muxinc/media-chrome

zacharyozer 6mo ago

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.

Heff 6mo ago
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!
- theMMaI 6mo ago
  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!

devnotes77 6mo ago

[dead]

gorbiesRedScar 6mo ago

this is lovely work

rahim_alwer 6mo ago
Thank you!

nulltrace 6mo ago

[flagged]

cpillsbury 6mo ago
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/dom/store/features/fullscreen.ts https://github.com/videojs/v10/blob/main/packages/core/src/d...).
- cpillsbury 6mo ago
  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.
  - nulltrace 6mo ago
    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.
blanched 6mo ago
Please stop posting AI-generated comments. Your post history is full of them.
- nulltrace 6mo ago
  Just a dev who's built the stuff I talk about. Pretty sure you already know that though, buddy.
  - efilife 6mo ago

nchmy 6mo ago

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!

Heff 6mo ago
Drop a note in discussions or issues! Would love to hear what you’re working with. https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions

EGreg 6mo ago

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/Q/web/js/tools/video.js 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?

Heff 6mo ago
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. [1] https://github.com/muxinc/media-elements https://github.com/muxinc/media-elements
- EGreg 6mo ago
  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).
  - colonCapitalDee 6mo ago

openclaw01 6mo ago

[dead]

taosx 6mo ago

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?

rahim_alwer 6mo ago
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.

gnulinux996 6mo ago

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.

KingMob 6mo ago
It's still mandatory for all but the newest iOS devices, which don't support MediaSourceExtensions.
- Heff 6mo ago
  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. [1] https://caniuse.com/http-live-streaming https://caniuse.com/http-live-streaming [2] https://www.mux.com/blog/low-latency-hls-part-2 https://www.mux.com/blog/low-latency-hls-part-2
  - Retr0id 6mo ago
    How do you actually use HLS in the form of a native browser feature? Can you just put the m3u8 in the video src?
    - pjc50 6mo ago
      Yes, doing that works perfectly. If you use videojs it will automatically use native support if present.
cpillsbury 6mo ago
Core VJS contributor here and builder of players and playback engines for too long (aka before HLS and MPEG-DASH were a thing). As others mentioned, the support matrix for HLS is very typically the proximate, pragmatic reason why folks will reach for HLS over DASH in a "pick one" situation. You're right that HLS is particularly bad for 24/7, long lived DVR/"EVENT" (to use HLS jargon) streams (fine for live, and there are some "cheats" you can do for EVENT to help there) compared to MPEG-DASH's <SegmentTemplate>-based "dynamic" MPEG usage. Outside of that, though, the standards themselves have different pain points and tradeoffs. Some things are "cleaner"/"less presumptuous" in DASH, but DASH also has a lot of design details that were both "design by committee" (aka different competing interests resulting in a spec that has arguably too many ways to do the same thing) and overrepresented by server-side folks (so many playback complexities/concerns/considerations weren't thought through). It is also sometimes not constrained enough, at least by default (things like not guaranteeing time alignment across media representations). For what it's worth, I think there are lots of pain points from the HLS design decisions as well, but focusing on DASH here just given the framing of your question. On the flip side, if you stay within certain bounds, the difference between HLS and DASH simply become text files: one XML manifest (MPD) for DASH and a few playlists (M3U8s) for HLS. There's a lot of effort being made to this end, including: https://cdn.cta.tech/cta/media/media/resources/standards/cta-5005-a-final.pdf https://cdn.cta.tech/cta/media/media/resources/standards/cta... and the CMAF-HAM-inspired model (https://github.com/streaming-video-technology-alliance/common-media-library/tree/main/libs/cmaf-ham https://github.com/streaming-video-technology-alliance/commo... from CML and https://github.com/videojs/v10/blob/main/packages/spf/src/core/types/index.ts https://github.com/videojs/v10/blob/main/packages/spf/src/co... in our own playback engine library), just to name a few.

naseemali925 6mo ago

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.

rahim_alwer 6mo ago
Hey there, I'm on the Video.js team! Sounds like your context provider approach is already in the right ballpark! Some background: our store[1] which was inspired by Zustand[2] is created and passed down via context too. This is the central state management piece of our library and where we imagine most devs will build on for extending and customizing to their needs. Updates are handled via simple store actions like `store.play()`, `store.setVolume(10)`, etc. Those actions are generally called in response to DOM events. On the events side of things, rather than registering event listeners directly, in v10 you'd subscribe to the store instead. Something like `store.subscribe(callback)`, or in React you'd use our `usePlayer`[3] hook. The store is the single source of truth, so rather than listening to the underlying media element directly, you're observing state changes. --- So far with v10 we haven't been thinking about "plugins" in the traditional sense either. If I had to guess at what it would look like, it'd be three things: 1. Custom store slices[4] so plugins can extend the store with their own state and actions 2. A middleware layer that plugs into the store's action pipeline so a plugin could intercept or react to actions before or after they're applied, similiar to Zustand middleware, or even in some ways like Video.js v8 middleware[5] 3. UI components that plugins can ship which use our core primitives for accessing the store, subscribing to state, etc. I believe that'd cover the vast majority of what plugins needed in v8. We haven't nailed down the exact API yet but that's the direction we're leaning towards. We're still actively working on both the library and our docs so I don't have somewhere I can link to for these just yet (sadly)! We're likely targeting sooner, but GA (end of June) is the deadline. I should also add... one thing we prototyped early on that may return: tracking end-to-end requests through the store. A DOM event triggers a store action like play, which calls `video.play()`, which then waits for the media event response (play, error, etc.). It worked really well and lines up nicely with the middleware direction. [1]: https://github.com/videojs/v10/tree/main/packages/store https://github.com/videojs/v10/tree/main/packages/store [2]: https://github.com/pmndrs/zustand https://github.com/pmndrs/zustand [3]: https://videojs.org/docs/framework/react/reference/use-player https://videojs.org/docs/framework/react/reference/use-playe... [4]: https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#slices-pattern https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#sli... [5]: https://legacy.videojs.org/guides/middleware/ https://legacy.videojs.org/guides/middleware/

bl4kers 6mo ago

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

Heff 6mo ago
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.
- robin_reala 6mo ago
  If we’re doing feedback, then: - On Mac with Increase Contrast turned on in accessibility settings the control bar ends up being white-on-light-grey - When focusing the volume control with a keyboard, you can only mute or un-mute, not use up or down to adjust the volume. To do that you have to tab again into the volume slider field - Don’t seem to be able to enter picture-in-picture mode with the keyboard - Purely from a first class citizen point of view, it’d be nice to have all the accessibility options (transcripts, etc) shown in the homepage demo
  - Heff 6mo ago
    This is great. Keep it coming.

rendaw 6mo ago

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?

nshelia 6mo ago
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.
- truetraveller 6mo ago
  Okay, what about non-streaming vid? I think the vanilla html5 <video> tag is solid, correct?
  - nshelia 6mo ago
    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
  - phantomathkg 6mo ago
    If all you want is a fix non-streaming, video, yes. Video tag just work. Video.js is catered for those required streaming.
Heff 6mo ago
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.

efilife 6mo ago

Seeking on the main https://videojs.org/ 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

rahim_alwer 6mo ago
Hey there, on the Video.js team. What browser and version did you run into this on?
- efilife 6mo ago
  114, Ungoogled Chromium to be specific. Happy to share more info if you need it
  - rahim_alwer 6mo ago
    I have that ticketed up for you [1], and I'll look into it tomorrow. Thank you! [1]: https://github.com/videojs/v10/issues/1120 https://github.com/videojs/v10/issues/1120

rezmason 6mo ago

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 https://github.com/morhetz/gruvbox

jxmesth 6mo ago
Any idea what the website's built with? I really like the design/UI tbh
- Cthulhu_ 6mo ago
  The HTML generator meta tag (f11 to open dev tools) says it's Astro: https://astro.build/ https://astro.build/
- deleted 6mo ago
  [deleted]
- deleted 6mo ago
  [deleted]
- deleted 6mo ago
  [deleted]
- genezeta 6mo ago
  As the sibling comment mentions, it's Astro: https://github.com/videojs/v10/tree/main/site https://github.com/videojs/v10/tree/main/site
  - nihiven 6mo ago
    Looks cool, reminds of a VHS box. Also nails the look of 70s decor that was everywhere when I was growing up in the 80s/90s.
deepriverfish 6mo ago
it's also available in vscode

BatteryMountain 6mo ago

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.

unit149 6mo ago

[dead]

suoer 6mo ago

[flagged]

BatteryMountain 6mo ago

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

nickmyersdt 6mo ago
[dead]
Xenoamorphous 6mo ago
Maybe look at MPE-DASH?
pjc50 6mo ago
Just convert it to HLS, which is naturally chunked at 1-2 second intervals, and serve all the pieces from nginix. No dynamic content needed. I do this with videojs and it works great. Added bonus of HLS is that my LG TV supports it natively from <video> tags.
panstromek 6mo ago
If you don't need to switch versions at runtime (ABR), you don't even need to chunk it manully. Your server has to support range requests and then the browser does the reasonable thing automatically. The simplest option is to use some basic object storage service and it'll usually work well out of the box (I use DO Spaces with built-in CDN, that's basically it).
- pjc50 6mo ago

maniacsudip 6mo ago

[dead]

maniacsudip 6mo ago

[dead]

progx 6mo ago

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.

Heff 6mo ago
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.

mitul005 6mo ago

[flagged]

rsmtjohn 6mo ago

[flagged]

efilife 6mo ago
LLM
pieterhg 6mo ago
Top reply on an HN thread is an AI bot, what a time @dang
deleted 6mo ago
[deleted]

EdgeNRoots 6mo ago

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

k4rli 6mo ago
Opening the article and reading beyond the title would answer that question.
Heff 6mo ago
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.

swaminarayan 6mo ago

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

Heff 6mo ago
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.

M4v3R 6mo ago

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.

c16 6mo ago
Absolutely the case for me. Small fun projects that would take a few hours to round off a feature can now be done in an hour. Why wouldn't i finish it off?
Heff 6mo ago
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).
dang 6mo ago
(We detached this subthread from https://news.ycombinator.com/item?id=47514723 https://news.ycombinator.com/item?id=47514723 so it wouldn't go down with that ship)

fede_dp 6mo ago

[dead]

rdevilla 6mo ago

[flagged]

tomhow 6mo ago
Please don't do this here.

tuukkah 6mo ago

Has the WebVTT story changed? I once tried to customize the subtitle rendering but it seemed too difficult.

Daiz 6mo ago
I would also be interested in this. Subtitle presentation is something where browsers are still generally very bad at out of the box, so having good subtitle rendering support built directly into the library would make a lot of sense to me. As someone with a lot of knowledge on this subject, I would be very much willing to help at least draft design documents for something like this, if not more.
- cpillsbury 6mo ago
  Hey there, core contributor here! This came up during our beta effort. We very likely will be having an opt-in, non-native subtitles rendering implementation. I know at least a few team members that really want it, which adds to the likelihood that we'll add it eventually. The short version of why we started with native subtitles - bundle size and legal compliance, with a dash of prioritization and a sprinkle of hope that some looming laws will motivate browser owners to prioritize improvements. If you want to see our design decision artifact on the topic, we try to make a lot of them public (also to help the robots these days) - https://github.com/videojs/v10/blob/main/internal/decisions/captions.md https://github.com/videojs/v10/blob/main/internal/decisions/...
  - tuukkah 6mo ago
    That's great news. Thank you for sharing the resource!

wei03288 6mo ago

[dead]

Serhii-Set 6mo ago

[flagged]

ronak_parmar 6mo ago

Great Work, Loved the approach.

Heff 6mo ago
Thank you!

moci 6mo ago

[dead]

leontloveless 6mo ago

[dead]

dylan604 6mo ago

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?

Heff 6mo ago
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.
- dylan604 6mo ago
  There have been other video players that attempt to be more "professional" adding things like audio meters and other tools. These are using parts of JS that is not available anywhere except in Chrome. After digging in, there's a lot of audio related things that Chrome is trying to do that FF/Safari are not. We have mp4 files with multiple audio streams that Chrome exposes ability to select from while FF/Safari do not. Creating waveforms on the fly from a video source also becomes problematic. We've also had issues getting frame accuracy when navigating the video stream. There's some sort of "security" that randomizes/rounds the returned value of currentTime that I cannot wrap my head around as how that is security related. Lots of effort spent on getting stock HTML5 video element to be frame accurate.
  - cpillsbury 6mo ago
    Core contributor here! FYI these kinds of cases are definitely on my mind. One of the nice things about our overarching architecture is we (or someone else, even you!) can add/extend for these kinds in a way that doesn't deeply "bake them in" to core use cases but still makes it completely possible to add. From "soup to nuts" (to extend my food metaphors), we've built VJS in a "highly composable" manner, which means we can, say, add state features, add UI for those state features, extend media renderers to expose those features to the state (if/when needed), etc. etc. If you want to start a discussion picking a concrete Chrome-only API, I'd encourage it (https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions). I don't know if/when we'll prioritize these things as part of the "core library", given our higher priorities of "feature parity" and core functionality, but we're already well situated for these kinds of cases (I'm sure we'll encounter and need to figure out some wrinkles along the way, but I'm confident these will generally be tractable).

moi2388 6mo ago

Cool. The video tag with ads. Thats what we need /s

01jonny01 6mo ago

It would be good if videoJS had youtube embed api and documentation like Plyr has

Heff 6mo ago
In the works! You should be able to use the existing <youtube-video-element> [1] with the HTML side of v10 today, but we're working on porting over the other media elements into the new architecture for better React support. [1] https://www.npmjs.com/package/youtube-video-element https://www.npmjs.com/package/youtube-video-element [2] https://github.com/muxinc/media-elements https://github.com/muxinc/media-elements
- 01jonny01 6mo ago
  It will be interesting to see how you handle acces to youtube player settings and cc. This is where other player wrappers fall down. Plyr did a good job of removing the branding via some clever css, but its annoying you cannot access settings and cc. One idea for a cc button is to always have cc on and then toggle the height styling to show/hide it

jacobgkau 6mo ago

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.

Heff 6mo ago
Drop a note in the discussions some time. I'd love to hear about what you're doing and even help migrate when the time is right for you. https://github.com/videojs/v10/discussions https://github.com/videojs/v10/discussions

mc007 6mo ago

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

luwes 6mo ago
VJS contributor here. It still matters for the page load time and start up time of the video which could be important to engage the user quick enough depending on the use case. We hint at this in the home page under the v10 is built different title. By importing the player bundle with the same import path via ESM in your bundle build it should deduplicate automatically. Hope this helps!

ruthven-elara 6mo ago

[dead]

devnotes77 6mo ago

[dead]

derodero24 6mo ago

[flagged]

johnwhitman 6mo ago

[flagged]