[HN Gopher] Show HN: Winamp and other media players, rebuilt for...
___________________________________________________________________
Show HN: Winamp and other media players, rebuilt for the web with
Web Components
Hey all, creator of Video.js and co-founder of Mux & Zencoder here.
My team and I built this. I hope you like the themes we've built so
far, and maybe even get inspired to build your own. 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.
Author : Heff
Score : 125 points
Date : 2024-10-08 18:27 UTC (4 hours ago)
(HTM) web link (player.style)
(TXT) w3m dump (player.style)
| maelito wrote:
| 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 ?
| Heff wrote:
| 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.
| spankalee wrote:
| 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.
| Heff wrote:
| Great points! We've talked about using iframes when we
| specifically _don 't_ want people to customize things, like
| single-video embeds.
| spankalee wrote:
| You can set the CSS properties that you don't want to
| inherit, you shouldn't need an iframe.
| Heff wrote:
| 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.
| henning wrote:
| 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.
| afavour wrote:
| It's a bit of fun. Relax.
| Heff wrote:
| 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!
| ale42 wrote:
| 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... ;-)
| mmcclure wrote:
| 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.
| spankalee wrote:
| Web components are great. You all are doing awesome things with
| them at Mux!
| spankalee wrote:
| 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.
| Heff wrote:
| Iiiinteresting. Some how I'd missed that so far. Thanks for
| the tip.
| andrewchilds wrote:
| 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!
| Heff wrote:
| 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.
| dfox wrote:
| 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
| ;)
| Heff wrote:
| That's fair. I think we have a little polish work still to do
| on that one. :)
| tomjen3 wrote:
| I have always wondered what the point of Web Components was. Do
| you have a preferred intro to them?
| theblackdahlia wrote:
| I love MUX so much!
| wallawe wrote:
| 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
| Heff wrote:
| 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.
| solomonb wrote:
| Any chance you can do foobar2000?
| Heff wrote:
| lol, we'll put it on the list! And obviously PRs welcome. :)
| zoogeny wrote:
| 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.
|
| 1. https://github.com/muxinc/media-elements
| Heff wrote:
| 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!
| danslinky wrote:
| Thank you for reminding me of Reelplay. I think.
| Heff wrote:
| Reelplayer! The first web video player that I (and many others)
| ever used.
| dnsbty wrote:
| Player.style is excellent!
|
| 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!
| Heff wrote:
| Thank you! If you still experience friction when trying to
| build your own theme, then our job isn't done. So let us know!
| dpedu wrote:
| There's some weirdness around focus going on here, hopefully this
| comes across as constructive criticism. All of them have the same
| problem:
|
| 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.
| Heff wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-08 23:00 UTC)