Live data from Hacker News

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

videojs.org

11–20 of 170 posts

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

#11

Looking great. I'll give it a try later on once things stabilize a bit. In the meantime, does anyone know what's going on in this space? Seems to me like a lot is changing over the past year. Eg: react-player new version, taken over by Mux. And also I did realize Video.js is sponsored by Mux. And also seemingly different companies working together.

OP and Mux co-founder here so have all the context on this. A lot has changed. Mux stepped in to help maintain React Player a few years ago. It wasn't getting frequent updates and Mux has a vested interest in the whole OSS player ecosystem (even if we didn't built it) because Mux Video (hosting) is player agnostic, and we get support requests for all of them. @luwes from Mux did the work to get to the new version, while making it possible to use Media Chrome media elements with React Player and consolidating some development efforts. We're still a tiny player team so that was important.

There are no immediate plans to deprecate React Player and I think it holds a special place in the ecosystem, but there will be overlap with video.js v10 and if there's specific features you care about or feel are missing, or if you think we're doing a bad job, please voice it here.

It was a similar story with Vidstack and Plyr, with Mux first sponsoring the projects. That's how I met Rahim and Sam, and how we got talking about a shared vision for the future of players.

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

#12

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

Thank you! I’m on the Video.js team, and we’d love for you to try the library out and share your feedback. We’re especially eager to hear from developers who used or tried v8 in the past.

We’re taking a new approach to the library with a lot of new concepts, so your feedback would help us a ton during Beta as we figure out what’s working well and what isn’t.

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

#13
post #2

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

I'm on the Video.js team, just wanted to say thank you! Means a lot and we'd be eager to hear your experience trying it out. Feel free to drop a GitHub issue or discussion post if you ever get a chance :)

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

#15
post #2

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

I'm on the Video.js team, just wanted to say thank you! Means a lot and we'd be eager to hear your experience trying it out. Feel free to drop a GitHub issue or discussion post if you ever get a chance :)

From me, this is a massive relief after we just deployed a bunch of videos to Vimeo. The next week they were bought.

I'm a one-man operation. In the order of hundreds of videos served a week. All I want is control over my own destiny. If this and a VPS can do that, that'll be amazing. Thank you for doing this.

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

#18
post #17

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.

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?

Post reply on HN