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

Original Article ↗ Hacker News Discussion ↗

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.