Show HN: Winamp and other media players, rebuilt for the web with Web Components (player.style)
I know Web Components are in a bit of a drama cycle right now. I’m happy to see them get any attention really. I’ve been pretty bullish on them since ~2013 when I started working with them, at least in the context of a widget like a video player. I’ve even given many related talks on them like this one (https://www.youtube.com/watch?v=N6Mh84SRoDg).
I would never push them for a large app or as a full replacement for React, but they’ve been incredible for making video players that are compatible across many contexts, and Player.style is a clear demonstration of that when you get to the step of embedding a theme. Web components really shine for building bits of UI that can be shared between projects. They also are the best way to avoid the long term JS framework thrash that’s a challenge for any developer who works on the web for long enough. One of the best decisions I ever made for Video.js was to not build it with jQuery. Video.js is 15 years old now and still in use, while all the jQuery players are not.
For some added context of this project, when I was building Video.js back in 2010 I put a lot of thought into how other developers would customize the player controls. I was excited to use web technologies (instead of Flash) to build a player and I knew other web devs would be too.
Fast forward 14 years — Video.js has been used on millions of websites including Twitter, Instagram, Amazon, Dropbox, Linkedin and even in United Airlines headrests. In 99.99% of those cases the default Video.js controls were used with little to no customization. So…huge adoption success, utter failure in sparking creativity. In retrospect, asking people to learn a new UI framework just to style their player was too much.
Media Chrome and Player.style are my answer to that friction.
- Media Chrome - A suite of Web Components and React Components that let you easily build a media player UI from scratch, using components you’re already familiar with.
- Player.stye - Themes built with Media Chrome, showing the cross-player and cross-framework flexibility of Media Chrome
Media Chrome is already used on sites like TED.com, Syntax.fm, and anywhere the Mux Player is used. We’ve spent the last few months building some great themes for Player.style. I probably had the most fun recreating the Youtube icon animations from scratch using SVGs and CSS. (Whoever made the originals, nicely done!)
It’s all free and open source, so don’t hesitate to jump in if you’re interested in the project. And of course I’m happy to answer any questions.
64 comments
[ 2.2 ms ] story [ 142 ms ] threadI 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 ?
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.
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.
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.
To give them some credit, I thought the multi-screen view they built across their players was pretty novel.
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
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.
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.
1. https://github.com/muxinc/media-elements
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!
In my last startup I started to build my own video.js theme, and after a few hours realized it probably wasn't worth my time and stuck with the defaults. Going forward these themes would give me a much better starting point to do something more custom.
Thanks for sharing!
When you click on the video itself, the left and right arrow keys work to scrub the video backwards and forwards. Up and down do nothing.
When you click on the scrubber, the left and right arrow keys stop working. Also, the up and down arrow keys start working to rewind/advance the video a different amount of time.
If you click in void space, e.g. on the Winamp example or the blue bar that looks like windows 98 on the Reelplay example - both of these controls stop working, as well as space to play/pause.
Latest chrome on macos.
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.
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.
As for the synthax question, my point is that your script looks like this
And media chorme looks like this<video slot="media" src="./video.mp4" crossOrigin playsInline>
<track label="English" kind="captions" srcLang="en" src="./captions.vtt"></track>
<track label="thumbnails" default kind="metadata" src="./thumbnails.vtt"></track>
</video>
And I just don't know how to interpolate the two
(Edit, checking further, I did manage to mix the two, and I can play subtitles over your demo video, but not over mine so I guess a foolproof sample in the wizard is probably needed :D )
Its refreshing to see this kind of work being done. Right now all the framework authors are going berserk about web-components and spewing "th3y suCk" and "w3bcomp0ents are N0T th3 futUr3!". Just nonsense. WC allow better reusability than ANY react-like framework can, and are universal. You can do pretty much anything with them. The hype train right now seem to be on SSR, and its just mad, like WTF we had server side rendering since the 90s, and then it was all about SPA's, and now they want to basically reimplement PHP era websites with SSR, making you pretty much vendor locked in to nodejs.
I take a WC over a bloated npm installed react project with 2345 dependencies any day. A WC that works today WILL work just as good if not better in 2036. Can your react do that?
Otherwise great project!
One thing that I feel should be mandatory when building applications is setting: `user-select: none;` and only allowing it where it's needed. For example, the reelplay theme bar is selectable
Again, thank you for this wonderful work
The on-demand (JIT) encoding is actual magic in how well it consistently works!
(I work at Mux)
If you don't mind sending a screenshot or other details to support@mux we'll figure out what's happening. Edge cases always seem to reveal themselves when someone else is looking at it.
> 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.