Back in 2019, we set out to solve a problem that had frustrated web developers for years. If you wanted custom video player controls, you had three equally unsatisfying options: live with browser defaults that looked different everywhere and couldn't be styled, accept the minimal customization options from platforms like YouTube or Vimeo, or face the daunting task of building controls from scratch.
We believed there had to be a better way. What if building a beautiful, custom video player could be as simple as writing HTML? What if designers could style video controls using the same CSS skills they already had? What if you could move a button just by changing its position in the markup?
That belief became Media Chrome.
What made Media Chrome different
Media Chrome introduced a radical idea to video player architecture: completely separate the UI layer from the playback engine. This wasn't how video players were typically built, but it unlocked something powerful.
We built this UI layer using Web Components, extending the browser's base HTML functionality. Suddenly, media player controls became simple HTML tags that you could use anywhere:
<media-controller>
<video slot="media" src="video.mp4"></video>
<media-control-bar>
<media-play-button></media-play-button>
<media-time-range></media-time-range>
<media-volume-range></media-volume-range>
</media-control-bar>
</media-controller>This HTML-first approach meant developers could:
- Design like it's native: Use controls like any HTML tag, style them with CSS, manipulate them with JavaScript
- Work framework-free: Compatible by default with React, Angular, Svelte, or vanilla JS
- Stay DRY across players: Use the same controls whether you're working with native <video>, YouTube embeds, or any other player
The response from the community was incredible. Developers loved how familiar the API felt, how quickly they could build something beautiful, and how much functionality came out of the box.
Technical breakthroughs that changed our thinking
Building Media Chrome taught us several lessons that fundamentally shaped how we think about video player architecture.
The <media-controller> pattern: We created a top-level controller that managed state and communication between the media element and all the controls. This dramatically reduced coupling — controls didn't need to know about each other or directly manipulate the video element. They just declared what they needed and responded to state changes.
The MediaStore: For React developers, we built a media store that exposed APIs perfectly suited for React's unidirectional data flow. This wasn't an afterthought — it was recognition that different frameworks have different philosophies, and we should meet developers where they are.
The theme system: We developed a lightweight template syntax with a minimal API footprint for creating Media Chrome themes. These themes could be packaged, shared, and ported between projects. It made "just HTML" even more powerful.
Exposing everything: We learned that when you give developers the building blocks instead of pre-assembled solutions, they build things you never imagined. Every minimal, definable component in the public API became a LEGO brick for creativity.
What we learned (and what we'd do differently)
The "it's just HTML" philosophy was our greatest success. Seeing developers structure their controls in HTML, move components around, and apply CSS with confidence — that validated everything we'd built. The ability to read the HTML and immediately understand what the player would look like was a superpower compared to proprietary configuration APIs.
But we also learned some hard lessons about Shadow DOM. While it provided encapsulation, it created friction for styling and DOM traversal. The growing list of CSS variables needed to pierce through shadow layers increased our API surface and made the developer experience more complex than we wanted. In hindsight, we'd use less Shadow DOM — maybe none at all for some components.
We also realized that some of our composite components, like the time range, hid too much internal structure. Making every piece configurable and exposable would have made the API more flexible without sacrificing ease of use.
One surprise came from a team at Microsoft who used Media Chrome not for its UI capabilities, but for the state management layer it provided for media elements. When your architecture solves problems you didn't even know existed, you know you're onto something.
Bringing Media Chrome principles into Video.js v10
Everything we learned building Media Chrome is now flowing into Video.js v10, amplified and refined:
Complete component exposure: Every minimal, definable component is part of the public API. No more hidden internal structures — if you can conceptualize it as a distinct piece, you can configure and replace it.
Leaner API surface: We're dramatically reducing the styling API, especially around CSS variables. The developer experience gets better when there's less to learn, not more.
Idiomatic framework APIs: Video.js v10 takes the MediaStore concept to the next level. We're building a common core with tailored APIs for each major framework — so React developers get components that feel native to React, Vue developers get composables that feel natural in Vue, and Svelte developers get stores that match Svelte patterns. No more fighting your framework to work with your player.
Markup-First, Shadow DOM optional: The core philosophy remains — whether you're writing HTML, JSX, Vue templates, or Svelte components, your player structure should be declarative and easy to reason about. We're being much more judicious about where Shadow DOM adds value versus where it creates friction, letting you work naturally in your framework's templating system.
Cross-player compatibility: Use the same UI components whether you're working with HLS, DASH, progressive video, or emerging formats. The separation of concerns isn't just elegant — it's liberating.
The power of convergence
Bringing Media Chrome's learnings into Video.js v10 creates something neither could achieve alone. Media Chrome proved that HTML-first architecture works at scale. Video.js brings battle-tested stability, a massive ecosystem, and years of production experience. Together, they're becoming a player that's both powerful and approachable, sophisticated and simple.
This convergence means:
- Designs refined by real-world use flowing to Video.js's massive audience
- More developers experiencing the joy of building custom players without the pain
- A more beautiful web, one player at a time
- Innovation accelerating because we're building from a stronger foundation
For Media Chrome users: Your investment is evolving
If you've built with Media Chrome, here's what this evolution means for you: while Media Chrome as a standalone project will eventually sunset, every idea that made it powerful lives on in Video.js v10 — often in improved form.
Yes, porting code requires effort. We get it. But we're committed to making this transition as smooth as possible:
- Migration guides that walk you through the translation
- Familiar patterns that reduce the learning curve
- Better APIs that often simplify what you're doing now
- Stronger foundation for the long term
This isn't an ending — it's your project graduating to something more powerful.
What's next: Building something extraordinary
We're incredibly excited about this convergence. Media Chrome started with a vision of making custom video players as easy as writing HTML. That vision didn't just prove viable — it revealed architectural principles that are now shaping the future of video on the web.
Video.js v10 takes those principles and runs with them. It's bringing well-scrutinized designs to a wider audience. It's making powerful capabilities accessible to more developers. It's proving that modern, flexible, beautiful video experiences don't require reinventing everything from scratch.
The web deserves beautiful video experiences. Developers deserve tools that enhance their creativity instead of constraining it. Video.js v10, built on Media Chrome's foundational insights, delivers both.
We can't wait to see what you build with it.
Want to get involved? Visit the repo, try the tech preview, and share your feedback. Video.js has always been built by the community, and v10 is no exception.
