- O Video.js v10, completamente reescrito após 16 anos, renasce com 88% de redução no tamanho do bundle e uma estrutura adaptada ao ambiente moderno de desenvolvimento
- Oferece suporte de primeira classe a React·TypeScript·Tailwind, além de UI padrão esteticamente refinada e estrutura de documentação amigável para IA
- Com o novo Streaming Processor Framework (SPF), implementa um motor de streaming modular que permite combinar apenas os recursos necessários, alcançando um nível de leveza equivalente a 12% do HLS.js
- Com arquitetura baseada em composição e sistema de skins com React/Web Components, é possível substituir ou remover livremente a UI e as funcionalidades
- O objetivo é o lançamento oficial em 2026, e o projeto evolui para a próxima geração de plataforma de mídia open source por meio de desenvolvimento colaborativo com IA e um ecossistema de presets escalável
Visão geral do beta do Video.js v10
- O beta do Video.js v10.0.0 é uma reescrita completa após 16 anos, resultado da colaboração entre vários projetos open source, incluindo Video.js, Plyr, Vidstack e Media Chrome
- Um ecossistema com 75 mil estrelas no GitHub e escala de bilhões de reproduções por mês participou do projeto, que foi redesenhado considerando métodos modernos de desenvolvimento e um ambiente de desenvolvimento assistido por IA
- Os principais objetivos são reduzir o tamanho do bundle em 88%, oferecer suporte de primeira classe a React·TypeScript·Tailwind, uma UI padrão esteticamente refinada e uma estrutura de documentação amigável para IA
Redução de bundle e melhorias de desempenho
- O player básico do Video.js v10 teve redução de 88% no tamanho do bundle padrão em relação ao v8, e mesmo com a remoção do recurso ABR (Adaptive Bitrate), a redução ainda é de 66%
- Ex.: v8 padrão 260.5kB (minified) → player de vídeo HTML do v10 97.4kB (minified), versão React 62.0kB
- Com a introdução do novo Streaming Processor Framework (SPF), é possível montar um motor de streaming modular combinando apenas as funcionalidades necessárias
- Em uso simples de HLS, v10+SPF equivale a 19% do tamanho de arquivo de v8+VHS
- O próprio motor SPF tem 12% do tamanho do HLS.js-light (38.5kB minified), otimizado para processamento simples de ABR
- O SPF é compatível com todos os motores existentes, como HLS.js, Shaka e dash.js, e permite leveza extrema quando recursos complexos de DRM e anúncios não são necessários
Arquitetura baseada em composição
- O v10 adota uma estrutura de componentes que separa State, UI e Media, permitindo substituir ou remover cada elemento de forma independente
- A função
createPlayer() recebe um array features e inclui apenas as funcionalidades necessárias
- Ex.: se recursos de áudio não forem necessários, o código de
volume e mute não entra no bundle
- Para remover a UI, basta não carregar a skin — isso permite eliminar completamente código desnecessário
- O exemplo mínimo em React funciona com menos de 5kB (gzipped) e inclui apenas botões simples de play/pause
Customização de UI e sistema de skins
- O v10 oferece um sistema de skins baseado em React e Web Components e adota uma estrutura de unstyled UI primitives inspirada em Base UI e Radix
- Cada componente de UI gera um único elemento HTML, permitindo controle direto
- No v8, a alça da timeline era controlada por pseudo-elementos CSS; no v10, ela é fornecida como um elemento DOM real, simplificando a estilização
- O beta inclui duas skins
- Skin padrão: estética translúcida (frosted), com animações suaves
- Skin minimalista: base simples para customização
- O design do diálogo de erro das skins também foi unificado, melhorando o acabamento visual
Sistema de presets
- O v10 introduz o conceito de preset por finalidade de uso, oferecendo templates de player prontos para uso que combinam skin, funcionalidades e configuração de mídia
- Video preset: para vídeo comum na web
- Audio preset: para áudio, como podcasts
- Background video preset: para vídeo em segundo plano, removendo controles e áudio
- Os presets oferecem um ponto de partida rápido, mas todos os componentes podem ser substituídos, mantendo total extensibilidade
- No futuro, estão previstos presets para educação, short-form e plataformas para criadores
Design amigável para IA
- O v10 tem como meta uma estrutura em que agentes de IA possam colaborar no desenvolvimento
- Componentes sem abstrações excessivas e unstyled UI primitives melhoram a compreensão do código
- Fornece o arquivo llms.txt para navegação eficiente na documentação, incluindo versões por framework
- Toda a documentação é oferecida em formato Markdown, permitindo que a IA acesse o conteúdo diretamente sem contexto HTML desnecessário
- Um conjunto de habilidades de IA no repositório deverá dar suporte ao desenvolvimento dos usuários no futuro
Orientações para uso do beta
- A API ainda não está estabilizada, e algumas interfaces podem mudar até o lançamento oficial
- No momento, o foco está nas funções básicas de reprodução em sites, com possibilidade de suporte a acessibilidade, legendas e diversos formatos, mas menus de configuração e afins ainda não foram implementados
- O projeto está coletando ativamente feedback via GitHub Issues e Discord
- Para usuários de versões anteriores, a recomendação é migrar após a publicação do guia de migração
Roadmap futuro
- Meta de lançamento oficial (GA) em meados de 2026
- Está prevista a obtenção de paridade de recursos com Plyr, Vidstack e Media Chrome
- O suporte a recursos de anúncios está planejado para o segundo semestre de 2026
- Também estão previstos guia de migração e presets adicionais
1 comentários
Comentários do Hacker News
Para quem estiver curioso, o tema de cores do syntax highlighting deste site é “gruvbox”
Pessoalmente, gostei bastante, mas levei um bom tempo para descobrir qual era
link do gruvbox no GitHub
Nunca usei video.js, mas o site e o anúncio pareceram voltados para quem já conhece a ferramenta
Enquanto eu lia, fiquei com uma dúvida: em que isso difere da tag de vídeo do HTML? É só o controlador que muda?
A tag de vídeo hoje em dia já é bem boa, mas o Video.js se diferencia por estilização consistente entre navegadores, recursos avançados (analytics, DRM, vídeo 360 etc.) e suporte a vários formatos de streaming (HLS, DASH etc.)
No fim das contas, dá para implementar com a tag de vídeo, mas aí você acaba recriando algo como o próprio Video.js
Se você precisa de um player ou de streaming confiável, é melhor usar Video.js
Só para referência, eu fiz um player de transmissão de TV para a Geórgia, com suporte desde smart TVs LG de 2009 até navegadores atuais
Isso é importante por causa do ajuste dinâmico de bitrate. O cache também fica mais eficiente
Tenho curiosidade se a situação do WebVTT mudou ultimamente
No passado, tentei customizar a renderização de legendas e foi difícil demais
Fiquei pensando por que isso não foi distribuído como Web Component
Na minha visão, parece um caso de uso perfeito — controles embutidos em um objeto semântico
No fim, resolvemos com um shim para React, mas isso gerou outros problemas
No VJS 10, encontramos um meio-termo com uma arquitetura de core headless + camada de renderização
Com isso, passamos a dar suporte tanto a componentes React quanto a Web Components
link do media-chrome no GitHub
Por causa de bugs de Shadow DOM e compatibilidade entre frameworks, você acaba gastando mais tempo com configuração do ambiente do que com o player em si
A maioria dos usuários não quer se preocupar com isso. Acho que uma biblioteca JS + API limpa é muito melhor
Só que a razão para usar React é que o tree-shaking permite incluir apenas o código necessário
Como esse tipo de otimização ainda é difícil em HTML puro, o pipeline de build acaba funcionando como uma espécie de gerador de Web Components
Tentei trocar meu player de áudio, que usava Plyr, por Video.js, mas senti algumas lacunas de funcionalidade na configuração padrão
Não há velocidade de reprodução abaixo de 1x, não dá para ajustar o volume no mobile, não há botões de navegação, é difícil customizar as cores, faltam demos etc.
No momento, o objetivo é alcançar paridade de recursos (feature parity) com Plyr e similares, mirando o GA em meados deste ano
Não entendo muito de hospedagem de vídeo, mas já usei player de vídeo HTML5
Fiquei na dúvida se é preciso criar, no servidor, um endpoint que entregue diretamente os chunks de vídeo
Se eu dividir com ffmpeg em blocos de 2 MB, onde seria melhor colocar isso? CDN? Servidor próprio?
Qual seria a melhor configuração para o Video.js funcionar da forma mais suave possível?
Funciona bem com Video.js, e em TVs LG também dá para fazer reprodução baseada em tag
Basta o servidor oferecer suporte a requisições Range, e o navegador cuida do resto
Eu uso uma combinação de object storage + CDN, como DO Spaces, e funciona bem
Você precisa fazer a codificação e a segmentação ao mesmo tempo (por exemplo, com o formatador dash do ffmpeg)
Para alinhar o tamanho dos segmentos de áudio e vídeo, a calculadora de GOP é útil
Em geral, você codifica um original de alta qualidade em várias resoluções, depois sobe isso para algo como S3 junto com um manifesto HLS/DASH
O player encontra todos os recursos necessários a partir de uma única URL de manifesto
O post do blog foi muito bem escrito
Gostei especialmente do jeito de explicar que respeita o leitor como especialista. Queria ver mais anúncios de produto assim
Parabéns, Steve!
Quando trabalhei na JW Player, fiquei impressionado com a simplicidade do Video.js e com seu sistema de temas
Espero que esta versão também seja um grande sucesso
Foi muito legal conversar com o time da JW em FOMS e em várias conferências
Tecnologia de vídeo continua sendo uma área super aquecida, então espero que você volte para ela algum dia
Esse número de 88% é impressionante
Fiquei curioso sobre qual foi o maior ponto de melhoria — imagino que tenha sido o sistema de plugins
Também queria saber se recursos importantes de integração deixaram de funcionar durante o rewrite
Tenho curiosidade sobre as mudanças de arquitetura feitas durante o rewrite e quais foram os trade-offs em relação ao design anterior do Video.js