Back around the same 2015 time frame I think I was being very optimistic and stubborn when it came to Web Components. I very much wanted them to work, but didn't really get anything into production until around 2020. There was a v2 of the web component spec between then and now, but I'm not an expert in what changed. Now I'm seeing web components everywhere, especially in media players. i.e. Apple's web player.

I'm glad you like the controller architecture. The original version just had every element pointing directly to the media element, and the controller cleaned up a lot. Highly recommend it, at least compared to what I was doing.

A video editor UI I think is natural extension of the Media Chrome suite. I'd love to hear what else might be helpful there if you want to post an issue in the repo.

I can deeply empathize with your hesitation to adopt something like media chrome based on future flexibility and size. I'll give you 3 points that would sell me on it. :) 1. You can only include the UI components you need, which is at least a major difference from other web video players when it comes to size. 2. We have some of the most experienced player devs working on it, including for things like accessibility and upcoming internationalization. 3. We're working hard to make it super configurable between slots, css parts, and css vars.

Of course we'll never beat the file size of completely custom software, but I feel like it'll come pretty close once all the basic features are built in.

Thanks for the heads up on the elements license!

Thanks! "Brilliant" might be giving us too much credit. We're mostly just paying attention to how devs are using video and trying to solve problems in that space. Next-video.dev is another example I'm proud of.

Some of what you're seeing on the open source player front is that we already kind of have to support those projects anyway. We're player agnostic, so our customers use a lot of open source, including projects that aren't actively being maintained.

I think we're benefitting right now from being one of a very few dev-focused video companies that's also actively contributing to open source.

Thank you! If you still experience friction when trying to build your own theme, then our job isn't done. So let us know!

Good feedback, thanks! There's a related issue in the media chrome repo here: https://github.com/muxinc/media-chrome/issues/957

The situation is a little complex with "hot keys" for controlling the video in general (after clicking on the video), accessibility controls for each component, and then general accessibility expectations for the whole page. For example, should we capture the up and down arrows to always control volume when the player is in focus, or should we not do that because people expect that for scrolling the page.

All that said, we definitely have some iteration ahead of us on this front so thanks again for the input.

Thank you for the feedback! I'm not quite sure I'm following, though. By the wizard do you mean the framework/element picker within a theme? Would you want the wizard there to be something where you can put in a URL for a subtitle track and we'll add it to the generated tag?

If you're seeing something weird around subtitle syntax then there's probably a documentation issue somewhere (or I'm misunderstanding your question). Subtitles themselves should work with a standard `<track>` in the media element, and the only other place we touch them is via the captions button/menu to toggle those tracks.

One small bit of feedback: you should look into using adoptedStyleSheets. They're very well supported now, and give a nice perf boost for repeated elements. You can fall back to <style> in the shadow root if the user's browser doesn't support them.

Thank you! One of the devs working on the Peacock player now helped build a lot of Media Chrome, so who knows what may come of that.

To give them some credit, I thought the multi-screen view they built across their players was pretty novel.

Web components and iframes are not mutually exclusive. Web components off ease of use and page styles and events integration, iframes offer a much stronger encapsulation boundary. You can use a web component to host and load an iframe even.

A few advantages of web components if you don't need the security boundary of iframes: - Web components can naturally resize to their content where iframes can't. - Some page styles inherit, like `color`, `font-family` and all CSS custom properties, so they can look more integrated. - Web components can fire events. - Web components can have slots to project content from the use site into. - Web components are much lighter weight than iframes.

Good question. There’s a good post from Lea Verou worth reading. https://lea.verou.me/blog/2024/wcs-vs-frameworks/

I think anything meant to be like a widget is a good fit. But an iframe you have the option of putting an app behind it while a web component is purely front end code. So maybe that’s a limitation for you. We at least plan to wrap iframes in web components for a nicer embed API.

That's fair. I think we have a little polish work still to do on that one. :)

lol, we'll put it on the list! And obviously PRs welcome. :)

Reelplayer! The first web video player that I (and many others) ever used.

It's a bit of fun. Relax.

I totally agree that this is very heavy compared to the original player, but that's probably not the point... maybe it's just for fun... ;-)

Yeah, we admittedly have some performance improvements on the site itself. It’s brand new so that will come. The themes themselves are performant, though I don’t know how to compare that to the original Winamp. Thanks for the feedback!