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

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

648 points by Heff 78 days ago | hide | past | favorite | 137 comments 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.

| zacharyozer 77 days ago | next [–] 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 77 days ago | parent | next [–] 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 77 days ago | root | parent | next [–] 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!

| rendaw 77 days ago | prev | next [–] 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?

| Heff 77 days ago | parent | next [–] 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.

| QuantumGood 77 days ago | root | parent | next [–] Part of what makes AI useful to me is getting though the layers of "what the hell is this, exactly" that slow you down when you jump more than one level beyond your domain knowledge. I think every knowledge container (document, website, what have you) should have a "what the hell is this" link /rich tooltip /accordion section /whatever by default.Of course, AI explanations often also fail at this unless you give them "ELI5" or other relevant prompting (I'm looking at you Perplexity).

| phist_mcgee 77 days ago | root | parent | next [–] I love a github repo's readme.md that only uses jargon and contains no intro paragraph on what the thing is or how it is to be used.

| ramon156 76 days ago | root | parent | next [–] Or it prints out the whole Stack, LOC, proj structure, like its in any way useful to me.

Advanced features like [...] adsI understand the use-case for this, but I find it working against the spirit of free software, which is bringing control back to the user.

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

| bheadmaster 77 days ago | root | parent | next [–] The user who uses the software running in his browser.

| dylan604 77 days ago | root | parent | next [–] In this case, you're talking about the browser user, and not the dev user of video.js, but I feel like you know this and are just trying to rail against ads in a manner that's just not relevant.If someone providing video content wants to run ads as part of making the video available to you, that's up to them. It's also up to you if you want to attempt to view the video without those ads or skip watching altogether. But to the dev of video.js, you're personal choices of consuming AVOD content are irrelevant.

| dylan604 77 days ago | root | parent | next [–] the OS of an ad platform is totally not important. I fail to see how this is relevant at all.

| nshelia 77 days ago | parent | prev | next [–] 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 77 days ago | root | parent | next [–] Okay, what about non-streaming vid? I think the vanilla html5

| nshelia 77 days ago | root | parent | next [–] 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

| pjc50 77 days ago | parent | prev | next [–] Most browsers don't support HLS or DASH.(And why does that matter? Dynamic bitrate adjustment. The chunks are slightly easier to cache as well.)

| RobotToaster 77 days ago | root | parent | next [–]

Most browsers don't support HLS or DASH.Most can via media source extensions.

| pjc50 77 days ago | root | parent | next [–] But that's not native. That's how videojs+HLS.js works, it plugs in the MSE to handle HLS.

| rezonant 77 days ago | root | parent | next [–] Using plain video element plus HLS.js is not complicated or difficult.

| cpillsbury 77 days ago | root | parent | next [–] Hey, core contributor here! If a plain video element plus hls.js is all you need to accomplish your goals, we wouldn't ever try to convince you otherwise. In fact, our "HlsVideo" media renderer is backed by hls.js, and Rob Walch has done Herculean feats maintaining and updating that playback engine. If, however, you don't simply want what's provided from the built in

| rezonant 77 days ago | root | parent | next [–]

We definitely aren't trying to convince anyone to use our free, open source library that doesn't need it.Could've fooled me...

| dbbk 77 days ago | root | parent | next [–] Is there a reason you're being an asshole?

| rezonant 76 days ago | root | parent | next [–] Being an asshole? For saying "could have fooled me" to one of the 6 posts on a brand new account heavily advertising video.js benefits in response to my post mentioning that the video element is already both powerful and easy to use, and that adding HLS.js to add HLS support to it for browsers that don't support it natively is dead simple?I guess your threshold for calling someone an asshole is a bit low.I don't have a problem with using video.js for the reasons the parent poster mentioned, but HTML5 video is insanely easy to implement, and there's no reason to take on a dependency like this if you don't need something beyond what the web platform already gives you.

| armandososa 76 days ago | parent | prev | next [–]

what makes this different from the native html video element?You don't realize how blessed you are to not know the answer to that question and to never ever have to say "Screw it, I'll just use video.js".

| bl4kers 77 days ago | prev | next [–] 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 12. No volume rocker on mobile3. Would appreciate having seek buttons on mobile too4. No (easily apparent) way to add an accent color, stuck with boring monochrome5. Docs lacked clear example/demo/playground so I wasn't sure what it would look like until implemented

| Heff 77 days ago | parent | next [–] 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 77 days ago | root | parent | next [–] 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 77 days ago | root | parent | next [–] This is great. Keep it coming.

| jjcm 77 days ago | prev | next [–] 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.

| mmcclure 77 days ago | parent | next [–] 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

| derefr 77 days ago | parent | prev | next [–] 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 77 days ago | root | parent | next [–] You certainly can just add it to a