Video.js v10: el reproductor de video de código abierto 88% más pequeño

• Video.js v10, reescrito por completo después de 16 años, reduce el tamaño del bundle en un 88% y renace con una estructura adaptada a los entornos modernos de desarrollo
• Ofrece soporte de primera clase para React, TypeScript y Tailwind, además de una UI predeterminada estéticamente cuidada y una estructura de documentación amigable para IA
• Con el nuevo Streaming Processor Framework (SPF) implementa un motor de streaming modular que permite combinar solo las funciones necesarias, logrando una reducción de peso de hasta el 12% frente a HLS.js
• Con una arquitectura basada en composición y un sistema de skins con React/Web Components, permite reemplazar o eliminar libremente la UI y las funciones
• Apunta a un lanzamiento oficial en 2026 y sigue evolucionando como una plataforma de medios de código abierto de próxima generación mediante desarrollo colaborativo con IA y un ecosistema de presets escalable

---

Resumen de la beta de Video.js v10

• La beta de Video.js v10.0.0 es una reescritura total tras 16 años, y es resultado de la colaboración entre varios proyectos de código abierto como Video.js, Plyr, Vidstack y Media Chrome
• Participó un ecosistema con 75 mil estrellas en GitHub y miles de millones de reproducciones mensuales, y fue rediseñado considerando prácticas modernas de desarrollo y un entorno de desarrollo asistido por IA
• Los objetivos principales son reducir el tamaño del bundle en un 88%, ofrecer soporte de primera clase para React, TypeScript y Tailwind, una UI predeterminada atractiva y una estructura de documentación amigable para IA

Mejoras en tamaño del bundle y rendimiento

• El reproductor base de Video.js v10 reduce el tamaño base del bundle en un 88% frente a v8; incluso al eliminar la función ABR (Adaptive Bitrate), la reducción sigue siendo del 66%
  • Ejemplo: v8 base 260.5kB (minified) → reproductor HTML de video en v10 97.4kB (minified), y la versión React 62.0kB
• Con la introducción del nuevo Streaming Processor Framework (SPF), es posible construir un motor de streaming modular combinando solo las funciones necesarias
  • Para uso simple de HLS, v10+SPF equivale al 19% del tamaño de archivo de v8+VHS
  • El motor SPF en sí tiene el 12% del tamaño de HLS.js-light (38.5kB minified), optimizado para manejo simple de ABR
• SPF es compatible con todos los motores existentes como HLS.js, Shaka y dash.js, y permite una reducción extrema de peso cuando no se requieren funciones complejas de DRM o anuncios

Arquitectura basada en composición

• v10 adopta una estructura de componentes que separa State, UI y Media, de modo que cada elemento puede reemplazarse o eliminarse de forma independiente
  • La función createPlayer() recibe un arreglo features e incluye solo las capacidades necesarias
  • Ejemplo: si no se necesita audio, el código de volume y mute no se incluye en el bundle
• Para quitar la UI, basta con no cargar el skin, lo que permite excluir por completo el código innecesario
• Un ejemplo mínimo en React funciona con menos de 5kB (gzipped) e incluye solo botones básicos de reproducir/pausar

Personalización de UI y sistema de skins

• v10 ofrece un sistema de skins basado en React y Web Components y adopta una estructura de unstyled UI primitives inspirada en Base UI y Radix
  • Cada componente de UI genera un único elemento HTML, permitiendo control directo
• En v8, el control del timeline se manejaba con pseudo-elementos de CSS, pero en v10 se ofrece como un elemento real del DOM, simplificando el estilo
• La beta incluye dos skins
  • Skin predeterminado: estética semitransparente (frosted) y animaciones suaves
  • Skin minimalista: una base sencilla para personalización
• También se unificó el diseño de los diálogos de error del skin, mejorando la calidad visual

Sistema de presets

• v10 introduce el concepto de presets según el caso de uso, ofreciendo plantillas de reproductor listas para usar que combinan skin, funciones y configuración de medios
  • Video preset: para video web general
  • Audio preset: para audio, como podcasts
  • Background video preset: para video de fondo, sin controles ni audio
• Los presets ofrecen un punto de partida rápido, pero todos los componentes pueden reemplazarse, manteniendo total extensibilidad
• Más adelante se planea agregar presets para educación, contenido short-form y plataformas para creadores

Diseño amigable para IA

• v10 busca una estructura en la que agentes de IA puedan colaborar en el desarrollo
  • Con componentes no abstraídos y unstyled UI primitives, mejora la comprensión del código
  • Ofrece un archivo llms.txt para hacer más eficiente la exploración de la documentación, con versiones por framework incluidas
  • Toda la documentación se ofrece en formato Markdown, para que la IA pueda acceder directamente sin contexto HTML innecesario
  • En el repositorio se prevé soporte futuro al desarrollo de usuarios mediante un conjunto de skills de IA

Guía de uso de la beta

• La API aún no está estabilizada, por lo que algunas interfaces podrían cambiar antes del lanzamiento oficial
• Por ahora se centra en funciones básicas de reproducción para sitios web; aunque puede soportar accesibilidad, subtítulos y varios formatos, menús de configuración y otras funciones aún no están implementados
• Actualmente se está recopilando activamente feedback a través de issues de GitHub y Discord
• A quienes usan versiones anteriores se les recomienda migrar después de que se publique la guía de migración

Hoja de ruta

• Objetivo de lanzamiento oficial (GA) a mediados de 2026
• Se planea alcanzar paridad funcional con Plyr, Vidstack y Media Chrome
• El soporte para funciones de anuncios está previsto para la segunda mitad de 2026
• También se planea ofrecer una guía de migración y presets adicionales

[GN⁺]

Comentarios en Hacker News

• Por si alguien tenía curiosidad, el tema de colores de resaltado de sintaxis de este sitio web es “gruvbox”
  En lo personal me encanta, pero me tomó bastante tiempo averiguarlo
  Enlace de GitHub de gruvbox

  • ¿Alguien sabe con qué tecnología está hecho este sitio web? Me gusta mucho el diseño y la UI
  • Como referencia, este tema también se puede usar en VSCode

• Nunca he usado video.js, pero sentí que el sitio o el anuncio estaban dirigidos a gente que ya lo conoce
  Mientras leía, una cosa que me preguntaba era en qué se diferencia de la etiqueta video de HTML. ¿Solo cambia el controlador?

  • Es una buena observación. El sitio debería explicar esa parte con más claridad
    La etiqueta video hoy en día ya es bastante buena, pero Video.js se diferencia por el estilo consistente entre navegadores, funciones avanzadas (analítica, DRM, video 360, etc.) y soporte para varios formatos de streaming (HLS, DASH, etc.)
    Al final, sí se puede implementar con la etiqueta video, pero si haces eso terminas construyendo algo como Video.js por tu cuenta
  • La etiqueta video no funciona bien en todos los entornos. Hay muchos edge cases según el navegador
    Si necesitas un reproductor o funciones de streaming estables, conviene usar Video.js
    Como referencia, yo hice un reproductor de TV abierta para Georgia que soportaba desde Smart TVs LG de 2009 hasta navegadores modernos
  • La mayoría de los navegadores no soportan HLS ni DASH
    Eso importa por el ajuste dinámico de bitrate. Además, el caché es más eficiente

• Me pregunto si la situación de WebVTT ha cambiado últimamente
  Hace tiempo intenté personalizar el renderizado de subtítulos y fue demasiado difícil

• Me pregunto por qué no lo distribuyeron como Web Component
  En mi opinión parece un caso de uso perfecto: controles integrados en un objeto con semántica clara

  • Buena pregunta. Antes sufrimos con los problemas de integración con React al intentar hacer media-chrome y Mux Player como Web Components
    Al final lo resolvimos creando un shim para React, pero eso trajo otros problemas
    En VJS 10 encontramos un punto medio con una arquitectura de núcleo headless + capa de renderizado
    Gracias a eso se pueden soportar tanto componentes de React como Web Components
    Enlace de GitHub de media-chrome
  • Los Web Components se ven bien, pero en la práctica consumen mucho tiempo por los problemas de estilos y SSR
    Entre bugs del Shadow DOM y compatibilidad entre frameworks, al final terminas gastando más tiempo en la configuración del entorno que en el reproductor
    A la mayoría de la gente no le importa eso. Creo que simplemente una librería JS + una API limpia es mucho mejor
  • En realidad, como el código de React se compila a HTML Custom Elements, en sentido amplio ya es un Web Component
    Aun así, se usa React porque gracias al tree-shaking solo puedes incluir el código necesario
    En HTML común todavía es difícil lograr esa optimización, así que el pipeline de build termina actuando como una especie de generador de Web Components

• Intenté cambiar mi reproductor de audio, que usaba Plyr, a Video.js, pero encontré varias brechas de funcionalidad en la configuración base
  No hay velocidad de reproducción por debajo de 1x, no se puede ajustar el volumen en móvil, no hay botones de búsqueda, es difícil personalizar colores, faltan demos, etc.

  • Buen feedback. Voy a registrar estos puntos como issues
    Ahora mismo estamos apuntando a la paridad de funciones (feature parity) con Plyr y otros, con la meta de llegar a GA hacia mediados de año

• No sé mucho de hosting de video, pero sí he usado reproductores de video HTML5
  Me pregunto si del lado del servidor hay que crear un endpoint que entregue directamente chunks de video
  Si los dividiera en bloques de 2 MB con ffmpeg, ¿dónde conviene ponerlos? ¿CDN? ¿Servidor propio?
  ¿Qué configuración sería la mejor para que Video.js funcione lo más fluido posible?

  • Simplemente convierte a HLS. Se fragmenta automáticamente en trozos de 1 a 2 segundos y nginx puede servirlos como archivos estáticos
    Va muy bien con Video.js, y hasta en TVs LG permite reproducción basada en etiquetas
  • Si no necesitas cambio de versión en tiempo de ejecución (ABR), tampoco hace falta fragmentar manualmente
    Mientras el servidor soporte solicitudes Range, el navegador se encarga del resto
    Yo uso una combinación de object storage + CDN como DO Spaces y funciona bien
  • Eso sí, los chunks deben empezar con keyframes IDR, así que no es tan simple
    Hay que manejar la codificación y la división en segmentos al mismo tiempo (por ejemplo, con el formateador dash de ffmpeg)
    Para alinear la duración de los segmentos de audio y video, sirve este calculador de GOP
    En general, se codifica en varias resoluciones a partir de una fuente original de alta calidad y luego se sube a algo como S3 junto con un manifiesto HLS/DASH
    El reproductor encuentra todos los recursos que necesita a partir de una sola URL del manifiesto
  • También vale la pena considerar MPE-DASH

• El post del blog está realmente muy bien escrito
  Me impresionó la forma de explicar que respeta al lector como experto. Ojalá hubiera más anuncios de producto así

• ¡Felicidades, Steve!
  Cuando trabajaba en JW Player me impresionaron la simpleza de Video.js y su sistema de temas
  Ojalá esta versión también sea un gran éxito

  • ¡Tanto tiempo, Zach! Qué gusto verte
    Disfruté mucho conversar con el equipo de JW en FOMS y en varias conferencias
    La tecnología de video sigue siendo un campo muy activo, así que ojalá vuelvas cuando quieras

• Ese 88% es sorprendente
  Me pregunto cuál fue el punto de mejora más grande; probablemente el sistema de plugins
  También quisiera saber si en el proceso de reescritura se rompieron integraciones importantes

• Me da curiosidad saber cuáles fueron los cambios de arquitectura durante la reescritura y cuáles fueron los trade-offs frente al diseño anterior de Video.js