That's a really nice implementation. I feel like it should be easy for that to support videos too, if desired. I assume it's just using a media element under the hood.

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.

Oh boy, I could write a book in response to this...

> a section on their site explaining how they are able to undercut everyone in the business and still keep going

This is great feedback that I'm putting on our todo list. We should absolutely have this.

We'll never put pricing out there that we can't handle with our economics, or at least have a clear path to supporting. All of our volume pricing is available publicly, so you should never be bait-and-switched if you're understanding concepts like credits. This is in contrast to some of our competitors that regularly surprise users with new pricing when they hit scale. I hate that so much.

Under the hood we use just-in-time encoding and other advanced optimizations that do give us an edge. Not to mention economies of scale. Writeup to come.

But a challenge comes in customer perception. Some of our customers understand encoding and it's cost, plus the benefits it brings like adaptive streaming and handling user-generated uploads. Many devs are new to video and expect it to cost the same as uploading an MP4 to S3. Some point to our competitors with no encoding costs, and some even point to Youtube as a reason why it should be cheaper. In the past Mux has been labeled as "the expensive option" because we charged for encoding, so we've been working on new pricing shape (some launched already, some to come) that allows you to come in at levels using less encoding that we can support economically, then elect higher levels of encoding costs/values when you understand if they're worth it to you.

We also think video should be more places than it is today, but video is inherently expensive in comparison to many other costs related to building an app, so we see it as our job to keep pushing costs down and shaping pricing so video is accessible to more use cases.

There are use-cases were encoding is a huge cost centre, like with user generated content, and so we wanted to make sure you could still build on Mux with that type of model. The tradeoffs for using free encoding are listed here though: https://docs.mux.com/guides/use-video-quality-levels. The free (basic) encoding still has charges for storage and delivery also. We hope that by helping you reduce costs when getting off the ground we can grow with you.

The on-demand (JIT) encoding is actual magic in how well it consistently works!

(I work at Mux)

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! If you still experience friction when trying to build your own theme, then our job isn't done. So let us know!

Anything frame-accurate or smooth scrubbing has always been a challenge with he abstraction level of the video element. I don't have an exact answer from you, but you might look around the web codecs space, where more performant examples are being built at a lower level. https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

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! Winamp is getting a lot of love (and controversy) right now so it felt worth calling out. But it's not my favorite of the themes in practice. I think that's Sutro, which kind of surprised us by how nice it turned out.

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.

The light framework you're referencing is Lit or Shoelace. Also web components have taken off, just in the enterprise space where most teams are going to be using whatever they prefer whether that's Svelte or React or Vue or Angular - so slotting in web components works.

For everyone else, you start running into the issue of the classic https://xkcd.com/927/ situation. The problem of ever-changing frameworks will always be a constant. People want different things from their frameworks!

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.

Fully flexible color choice is a foot gun. I've definitely made some very ugly themes with that too. The goal is to have very many themes here, including user-submitted ones, so it might be hard to create something that can warn about issues across all of them. But seeing as we have pretty clear foreground and background color settings with primary/secondary I bet we could make something helpful.

It's very much a pick your own palette experience at the moment but it's a good shout, we could show a warning if the colors being picked don't meet accessible contrast values.

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.

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

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

Had to be said :)

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

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!