I love the idea behind this and thank you for making it MIT license.
I just happen to be working on a media app (a video editor) and previously I have built a few video players (in both Flash and HTML/JS). We actually tried to use web components on one player (back in 2015-ish) and they were a constant pain that we eventually discarded in favor of plain old JavaScript. Strangely enough, for my current media app I've been using web components (e.g. a video editor timeline) and so far it is going very well. I'm not sure what changed or if it is just the case that the slow advancement of the web has brought compatibility far enough to make it viable.
I've just skimmed the Media Chrome docs and have only taken a quick glance at the github repo, but I like your design principles and architecture notes. My main concerns about adopting something like this (especially since I have a lot of experience building exactly stuff like this from scratch) are extensibility (e.g. how hard would it be to modify my timeline component to fit into the MediaController paradigm) and file size. One advantage of doing everything oneself is that you have everything you need and nothing more. I'm sure Media Chrome has a lot of stuff I just won't need (but someone else will) - the questions is how much bloat I am taking on for things I won't ever use. And not just components I won't use, but unused features of the components I will use. Sometimes it is just a matter of existing unnecessary functionality getting in the way of a lower-level kind of extensibility.
As an aside, your `media-elements` repo [1] does not have a license file. I see in the package.json that the elements are also MIT but having an explicit LICENSE file is always appreciated.
That being said, this is a very tempting library. At the least I will probably steal the idea to wrap my components in a media-controller like element since I've been using the containing page so far to stich my elements together and I wanted a nicer abstraction.
The Mux marketing strategy is brilliant.
Take over or create new open source projects so that every developer comes across your company in the search for a video package.
Another example I noticed recently is https://github.com/cookpete/react-player
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 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.
Web components are great. You all are doing awesome things with them at Mux!
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.
Iiiinteresting. Some how I'd missed that so far. Thanks for the tip.
Any chance you can do foobar2000?
lol, we'll put it on the list! And obviously PRs welcome. :)
Nicely done. I wish Peacock had used one of these during the Olympics / Paralympics, specifically one that has a visible chapter scrubber like these do. Watching a 6 hour stream with a dozen different matches meant not having any idea who was playing when. Hopefully they'll use one of these players next time around!
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.
If there is an CoolBar grab handle (which is UX hint), it should be functional and not just work as a click site to play the video ;)
That's fair. I think we have a little polish work still to do on that one. :)
Thanks for the link and the work.
I wonder what would be the other uses of web components.
Practical case : at work we want to distribute a subsidies simulator. It's currently an iframe. What would be the advantages of distributing a web component instead of an iframe ?
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.
Great points! We've talked about using iframes when we specifically don't want people to customize things, like single-video embeds.
You can set the CSS properties that you don't want to inherit, you shouldn't need an iframe.
That's true. I think I still like the limits of an iframe as a design constraint, compared to web components where you have to explicitly make those decisions. But really what tips me into iframe land is when using a backend for the HTML page can unlock something you can't do otherwise.
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.
I love MUX so much!
I have always wondered what the point of Web Components was. Do you have a preferred intro to them?
An old version of Winamp will load very quickly and run very well on modest hardware. This webpage does not scroll smoothly on a 2019 Mac Book Pro and there's a long delay in loading the gratuitous, confusing video you have on the page. You have created a massive performance regression for no reason.
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... ;-)
This was one where we almost didn't include it because it's pretty impractical, but...I still love it. Yes, 100% fun.
If people actually like it we should take a performance pass. In our defense, we at least switched out the original bmp files from the first pass we took at hacking this together.
It's a bit of fun. Relax.
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!