Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

Original Article ↗ Hacker News Discussion ↗

A major new beta release of the open-source Video.js player rewrites the 16‑year‑old project into a composable, tree‑shakeable architecture that can be up to 88% smaller than previous versions. Commenters explore why a dedicated player still matters versus the native HTML `<video>` tag — citing consistent UI, streaming formats like HLS/DASH, plugin ecosystems, accessibility and ads — and how the new design aims for idiomatic integrations across React, web components and eventually other frameworks. There is also practical debate on self‑hosting video (vs. platforms like Vimeo), chunking and serving streams efficiently, and the trade-offs of web components, browser support and long-term plugin maintenance.

Overall reception

  • Many commenters are enthusiastic about the v10 rewrite and the 88% size reduction, planning to try it or migrate from older versions / other players (e.g., Plyr).
  • Some relief from people wanting control over their own hosting (VPS/CDN + self‑hosted player instead of platforms like Vimeo).
  • A few users note past frustrations with older Video.js versions and are cautiously optimistic about v10.

Architecture, size, and design goals

  • v10 is effectively a new player, not backwards compatible with v8; migration will require work.
  • Major change: move from monolithic controller objects and a custom component system to a composable, tree‑shakable architecture with a headless core and pluggable renderers.
  • Size win comes from “all and only what you use” tree‑shaking, using existing frameworks/custom elements instead of a bespoke UI layer, and splitting core from DOM.

Frameworks, web components, and integration

  • v10 targets React first but is designed to support Svelte, Vue, and even React Native later; custom elements are the interim cross‑framework solution.
  • There is a nuanced discussion on web components: attractive in theory but painful in practice (styling, SSR, hydration, framework glue). v10 aims for a middle ground: headless core + framework‑specific layers.
  • Some confusion over whether it’s a “web component” vs “React player”; clarification that HTML custom elements are part of the story, but bundlers/tree‑shaking are key.

Streaming formats and hosting

  • Strong emphasis on HLS and DASH as the right answer for “just HTTP chunks” over RTP/RTMP or custom chunking.
  • HLS is favored pragmatically due to Apple ecosystem and growing browser support; DASH has advantages for long‑running streams and manifest size.
  • Advice includes using HLS/DASH segmenters (ffmpeg), serving static chunks via standard HTTP/CDNs, and ensuring MP4 faststart for simple non‑ABR use.

Use cases vs native <video>

  • For simple, non‑streaming MP4 with native controls, the <video> tag is sufficient.
  • Video.js is positioned for:
    • Consistent, stylable cross‑browser controls.
    • Multiple formats (MP4, HLS, DASH) and third‑party services (YouTube, Vimeo) under one API.
    • Advanced features: analytics, ABR, ads, DRM, 360, etc.
  • Some argue plain <video> + hls.js is enough; maintainers acknowledge this and frame Video.js as optional higher‑level tooling.

Plugins, ecosystem, and roadmap

  • v10 de‑emphasizes old “plugin” style in favor of composable components and store extensions (state slices, middleware, UI pieces).
  • Plan to port popular plugins and encourage contributions within the core repo to reduce versioning drift.
  • YouTube/Vimeo and other media elements are being integrated via existing custom elements.

Accessibility, UX, and feedback

  • Users request better mobile controls (volume, seek buttons), playback rates <1x, theming/accent colors, and clearer demos/docs.
  • Accessibility feedback includes issues with high‑contrast mode, keyboard handling for volume and PiP, and desire for first‑class transcripts/captions in demos.
  • Subtitle rendering: currently uses native captions for size/legal reasons; a non‑native, opt‑in renderer is planned.

Miscellaneous

  • Some tension around ad support: one side sees ads as user‑hostile, the other as optional and necessary for monetization.
  • AI tools reportedly helped the team aim higher (multiple idiomatic framework integrations) with a small team.