- Réécrit entièrement après 16 ans, Video.js v10 renaît avec une taille de bundle réduite de 88 % et une architecture adaptée aux environnements de développement modernes
- Prend en charge React, TypeScript et Tailwind comme citoyens de première classe, avec une UI par défaut soignée et une structure documentaire pensée pour l’IA
- Le nouveau Streaming Processor Framework (SPF) permet de construire un moteur de streaming modulaire en n’assemblant que les fonctions nécessaires, pour atteindre un allègement à 12 % de la taille de HLS.js
- Grâce à une architecture basée sur la composition et à un système de skins React/Web Components, il est possible de remplacer ou supprimer librement l’UI et les fonctionnalités
- La sortie officielle est visée pour 2026, avec l’ambition d’évoluer vers une plateforme média open source de nouvelle génération grâce au développement collaboratif avec l’IA et à un écosystème de presets extensible
Présentation de la bêta de Video.js v10
- La bêta de Video.js v10.0.0 est une réécriture complète après 16 ans, fruit d’une collaboration entre plusieurs projets open source comme Video.js, Plyr, Vidstack et Media Chrome
- L’écosystème réunit au total 75 000 étoiles sur GitHub et des milliards de lectures mensuelles ; il a été repensé pour des méthodes de développement modernes et un environnement de développement assisté par l’IA
- Les principaux objectifs sont une réduction de 88 % de la taille du bundle, la prise en charge native de React, TypeScript et Tailwind, une UI par défaut soignée et une structure documentaire pensée pour l’IA
Réduction de la taille du bundle et amélioration des performances
- Le lecteur Video.js v10 de base affiche une réduction de 88 % de la taille du bundle par défaut par rapport à la v8, et encore 66 % de réduction même sans la fonction ABR (Adaptive Bitrate)
- Exemple : v8 de base 260.5kB (minified) → lecteur vidéo HTML v10 97.4kB (minified), version React 62.0kB
- Avec l’introduction du nouveau Streaming Processor Framework (SPF), il devient possible de composer un moteur de streaming modulaire ne contenant que les fonctions nécessaires
- Pour un usage HLS simple, v10+SPF représente 19 % de la taille de fichier de v8+VHS
- Le moteur SPF lui-même ne fait que 12 % de la taille de HLS.js-light (38.5kB minified), optimisé pour un traitement ABR simple
- SPF est compatible avec tous les moteurs existants comme HLS.js, Shaka et dash.js ; si des fonctions complexes comme le DRM ou la publicité ne sont pas nécessaires, une réduction extrême du poids devient possible
Architecture basée sur la composition
- La v10 adopte une structure de composants séparant State, UI et Media, permettant de remplacer ou supprimer chaque élément indépendamment
- La fonction
createPlayer() accepte un tableau features afin de n’inclure que les fonctionnalités nécessaires
- Exemple : si les fonctions audio ne sont pas requises, le code
volume et mute n’est pas inclus dans le bundle
- Pour supprimer l’UI, il suffit de ne pas charger de skin — ce qui permet d’exclure complètement tout code inutile
- Un exemple React minimal fonctionne avec moins de 5kB (gzipped) et n’inclut qu’un simple bouton lecture/pause
Personnalisation de l’UI et système de skins
- La v10 propose un système de skins basé sur React et Web Components, et adopte une structure d’unstyled UI primitives inspirée notamment de Base UI et Radix
- Chaque composant UI génère un seul élément HTML, permettant un contrôle direct
- Le curseur de la timeline, autrefois contrôlé via des pseudo-éléments CSS dans la v8, est désormais exposé dans la v10 comme un véritable élément DOM, ce qui simplifie le style
- La bêta inclut deux skins
- Skin par défaut : esthétique semi-transparente (frosted), animations fluides
- Skin minimal : base épurée pour la personnalisation
- Le design des dialogues d’erreur est également unifié entre les skins, pour une meilleure cohérence visuelle
Système de presets
- La v10 introduit la notion de preset selon l’usage, avec des modèles de lecteur prêts à l’emploi combinant skin, fonctions et configuration média
- Video preset : pour la vidéo web classique
- Audio preset : pour l’audio seul, comme les podcasts
- Background video preset : pour les vidéos d’arrière-plan, sans contrôles ni audio
- Les presets offrent un point de départ rapide tout en permettant de remplacer tous les composants, sans sacrifier l’extensibilité
- D’autres presets sont prévus, notamment pour l’éducation, les formats courts et les plateformes pour créateurs
Conception pensée pour l’IA
- La v10 vise une structure dans laquelle des agents IA peuvent participer au développement
- Des composants non abstraits et des unstyled UI primitives améliorent la compréhension du code
- Un fichier llms.txt est fourni pour faciliter la navigation dans la documentation, avec des versions par framework
- Toute la documentation est fournie au format Markdown, afin que l’IA puisse y accéder directement sans contexte HTML superflu
- Un ensemble de compétences IA dans le dépôt doit à terme aider les développeurs utilisateurs
Guide d’utilisation de la bêta
- L’API n’est pas encore stabilisée et certaines interfaces peuvent encore changer avant la sortie officielle
- Pour l’instant, l’accent est mis sur la lecture de base sur site web ; l’accessibilité, les sous-titres et la prise en charge de divers formats sont possibles, mais des fonctions comme le menu de réglages ne sont pas encore implémentées
- Les retours via GitHub Issues et Discord sont activement collectés
- Il est recommandé aux utilisateurs des versions précédentes d’attendre la publication du guide de migration avant de basculer
Feuille de route
- Objectif de sortie officielle (GA) à la mi-2026
- Parité fonctionnelle visée avec Plyr, Vidstack et Media Chrome
- La prise en charge de la publicité est prévue pour le second semestre 2026
- Un guide de migration et des presets supplémentaires sont prévus
1 commentaires
Avis Hacker News
Pour ceux que ça intéresse, le thème de couleurs de coloration syntaxique de ce site est « gruvbox »
Personnellement, je l’adore, mais il m’a fallu pas mal de temps pour l’identifier
lien GitHub de gruvbox
Je n’ai jamais utilisé video.js, mais j’ai eu l’impression que le site et la pub s’adressaient à des gens déjà familiers avec ça
En le lisant, je me demandais surtout quelle était la différence avec la balise vidéo HTML. C’est juste une histoire de contrôles différents ?
La balise vidéo est devenue plutôt bonne aujourd’hui, mais Video.js se démarque par un style cohérent entre navigateurs, des fonctions avancées (analytics, DRM, vidéo 360, etc.) et la prise en charge de différents formats de streaming (HLS, DASH, etc.)
Au final, on peut l’implémenter avec la balise vidéo seule, mais on finit alors par recréer quelque chose qui ressemble à Video.js
Si on a besoin d’un lecteur stable ou de fonctions de streaming fiables, mieux vaut utiliser Video.js
Pour info, j’ai créé un lecteur TV broadcast pour la Géorgie, avec prise en charge depuis les Smart TV LG de 2009 jusqu’aux navigateurs les plus récents
C’est important à cause de l’adaptation dynamique du débit. Le cache est aussi plus efficace
Je me demande si la situation a changé récemment autour de WebVTT
J’avais essayé autrefois de personnaliser le rendu des sous-titres, et c’était extrêmement difficile
Je me demande pourquoi ce n’est pas distribué sous forme de Web Component
À mes yeux, c’est un cas d’usage parfait — des contrôles intégrés à un objet sémantique
On a fini par résoudre ça avec un shim pour React, mais ça a créé d’autres problèmes
Avec VJS 10, on a trouvé un compromis avec une architecture cœur headless + couche de rendu
Ça permet de prendre en charge à la fois les composants React et les Web Components
lien GitHub de media-chrome
À cause des bugs du Shadow DOM ou de la compatibilité entre frameworks, on finit par passer plus de temps sur l’environnement que sur le lecteur lui-même
La plupart des utilisateurs ne se soucient pas de ce genre de choses. À mon avis, une simple bibliothèque JS + API propre est bien meilleure
Mais si React est utilisé, c’est grâce au tree-shaking, qui permet de n’inclure que le code nécessaire
Dans le HTML classique, ce type d’optimisation reste difficile, donc la pipeline de build joue en quelque sorte le rôle de générateur de Web Components
J’ai essayé de remplacer par Video.js mon lecteur audio qui utilisait Plyr, mais il y avait quelques écarts fonctionnels dans la configuration par défaut
Pas de vitesse de lecture en dessous de 1x, pas de réglage du volume sur mobile, pas de bouton de recherche, personnalisation des couleurs difficile, peu de démos, etc.
On vise actuellement la parité fonctionnelle (feature parity) avec Plyr et d’autres, avec un objectif de GA vers le milieu de l’année
Je ne connais pas très bien l’hébergement vidéo, mais j’ai déjà utilisé des lecteurs vidéo HTML5
Je me demande s’il faut créer côté serveur un endpoint qui fournit directement les chunks vidéo
Si je découpe avec ffmpeg par blocs de 2 Mo, où vaut-il mieux mettre ça ? CDN ? serveur maison ?
Quelle configuration est la meilleure pour que Video.js fonctionne de la façon la plus fluide possible ?
Ça fonctionne bien avec Video.js, et même sur les TV LG la lecture basée sur les balises est possible
Il suffit que le serveur prenne en charge les requêtes Range, et le navigateur gère le reste
J’utilise une combinaison stockage objet + CDN comme DO Spaces, et ça fonctionne très bien
Il faut gérer l’encodage et le découpage en segments en une seule étape (par exemple avec le formateur dash de ffmpeg)
Pour aligner la durée des segments audio et vidéo, le calculateur GOP est utile
En général, on encode plusieurs résolutions à partir d’une source de haute qualité, puis on envoie le tout sur S3 ou équivalent avec un manifeste HLS/DASH
Le lecteur retrouve ensuite toutes les ressources nécessaires à partir d’une seule URL de manifeste
Le billet de blog était vraiment très bien écrit
J’ai été impressionné par cette façon d’expliquer qui respecte le lecteur comme un expert. J’aimerais voir plus d’annonces produit de ce genre
Félicitations Steve !
À l’époque où je travaillais chez JW Player, j’avais été impressionné par la simplicité de Video.js et son système de thèmes
J’espère que cette version rencontrera aussi un grand succès
J’avais beaucoup aimé discuter avec l’équipe JW à FOMS et dans diverses conférences
La vidéo reste toujours un domaine très actif, donc reviens quand tu veux
Ce chiffre de 88 % est impressionnant
Je me demande quel a été le plus gros levier d’amélioration — probablement le système de plugins
J’aimerais aussi savoir si des intégrations majeures ont été cassées pendant la réécriture
Je me demande quels ont été les changements d’architecture pendant la réécriture, et quels compromis cela a impliqués par rapport à l’ancien design de Video.js