- Das nach 16 Jahren vollständig neu geschriebene Video.js v10 wurde mit 88 % kleinerer Bundle-Größe neu für moderne Entwicklungsumgebungen aufgebaut
- React, TypeScript und Tailwind werden erstklassig unterstützt, dazu kommen eine ästhetische Standard-UI und eine KI-freundliche Dokumentationsstruktur
- Mit dem neuen Streaming Processor Framework (SPF) wurde eine modulare Streaming-Engine umgesetzt, bei der sich nur die benötigten Funktionen kombinieren lassen; gegenüber HLS.js wird dabei eine Gewichtsreduktion auf 12 % erreicht
- Mit einer kompositionsbasierten Architektur und einem Skin-System auf Basis von React/Web Components lassen sich UI und Funktionen frei austauschen oder entfernen
- Die offizielle Veröffentlichung ist für 2026 geplant; durch KI-gestützte kollaborative Entwicklung und ein skalierbares Preset-Ökosystem entwickelt sich das Projekt zu einer Open-Source-Media-Plattform der nächsten Generation
Überblick über die Video.js-v10-Beta
- Die Beta von Video.js v10.0.0 ist eine vollständige Neuschreibung nach 16 Jahren und das Ergebnis der Zusammenarbeit mehrerer Open-Source-Projekte wie Video.js, Plyr, Vidstack und Media Chrome
- Ein Ökosystem mit insgesamt 75.000 GitHub-Stars und Milliarden Wiedergaben pro Monat war daran beteiligt; die neue Architektur wurde mit Blick auf moderne Entwicklungsweisen und KI-gestützte Entwicklungsumgebungen entworfen
- Die Hauptziele sind eine 88 % kleinere Bundle-Größe, erstklassige Unterstützung für React, TypeScript und Tailwind, eine ästhetische Standard-UI und eine KI-freundliche Dokumentationsstruktur
Verbesserungen bei Bundle-Größe und Performance
- Der Standardplayer von Video.js v10 ist gegenüber v8 bei der Basis-Bundle-Größe um 88 % kleiner, und selbst ohne ABR-Funktion (Adaptive Bitrate) beträgt die Reduktion noch 66 %
- Beispiel: v8 standardmäßig 260.5kB (minified) → v10 HTML-Videoplayer 97.4kB (minified), die React-Version 62.0kB
- Durch die Einführung des neuen Streaming Processor Framework (SPF) lässt sich eine modulare Streaming-Engine zusammenstellen, in der nur benötigte Funktionen kombiniert werden
- Bei einfachem HLS-Einsatz liegt v10+SPF im Vergleich zu v8+VHS bei 19 % der Dateigröße
- Die SPF-Engine selbst ist mit 12 % der Größe von HLS.js-light (38.5kB minified) für einfache ABR-Verarbeitung optimiert
- SPF ist mit bestehenden Engines wie HLS.js, Shaka und dash.js vollständig kompatibel; wenn keine komplexen DRM- oder Werbefunktionen benötigt werden, ist eine extreme Gewichtsreduktion möglich
Kompositionsbasierte Architektur
- v10 nutzt eine Komponentenstruktur mit getrennten Bereichen für State, UI und Media, sodass sich einzelne Elemente unabhängig austauschen oder entfernen lassen
- Die Funktion
createPlayer() nimmt ein features-Array entgegen und bindet nur die benötigten Funktionen ein
- Beispiel: Wenn keine Audiofunktionen benötigt werden, werden
volume- und mute-Code nicht ins Bundle aufgenommen
- Um die UI zu entfernen, muss einfach nur kein Skin geladen werden — unnötiger Code lässt sich vollständig ausschließen
- Ein minimales React-Beispiel läuft mit weniger als 5kB (gzipped) und enthält nur einfache Play/Pause-Buttons
UI-Anpassung und Skin-System
- v10 bietet ein Skin-System auf Basis von React und Web Components und übernimmt eine Struktur aus unstyled UI primitives, inspiriert unter anderem von Base UI und Radix
- Jede UI-Komponente gibt ein einzelnes HTML-Element aus und lässt sich dadurch direkt kontrollieren
- Während der Timeline-Handle in v8 noch über CSS-Pseudoelemente gesteuert wurde, steht er in v10 als echtes DOM-Element zur Verfügung, was das Styling vereinfacht
- In der Beta sind zwei Skins enthalten
- Standardskin: halbtransparente „frosted“-Ästhetik mit weichen Animationen
- Minimal-Skin: eine schlichte Basis für Anpassungen
- Auch das Design der Fehlerdialoge wurde über die Skins hinweg vereinheitlicht und verbessert so die visuelle Qualität
Preset-System
- v10 führt das Konzept von Presets nach Einsatzzweck ein und bietet damit sofort nutzbare Player-Templates, die Skin, Funktionen und Medienkonfiguration kombinieren
- Video preset: für allgemeine Webvideos
- Audio preset: für reine Audioinhalte wie Podcasts
- Background video preset: für Hintergrundvideos, ohne Steuerung und Audio
- Presets bieten einen schnellen Einstiegspunkt, lassen aber gleichzeitig den Austausch aller Bestandteile zu und bleiben vollständig erweiterbar
- Künftig sind zusätzliche Presets für Bildung, Shortform-Inhalte und Creator-Plattformen geplant
KI-freundliches Design
- v10 verfolgt das Ziel, eine Struktur zu schaffen, in der KI-Agenten aktiv mitentwickeln können
- Nicht abstrahierte Komponenten und unstyled UI primitives verbessern die Verständlichkeit des Codes
- Zur effizienteren Navigation in der Dokumentation wird eine Datei llms.txt bereitgestellt, inklusive frameworkspezifischer Versionen
- Die gesamte Dokumentation wird im Markdown-Format bereitgestellt, sodass KI direkt ohne unnötigen HTML-Kontext darauf zugreifen kann
- Über ein AI Skill Set im Repository soll künftig auch die Entwicklung durch Nutzer unterstützt werden
Hinweise zur Beta-Nutzung
- Die API ist noch nicht stabilisiert, bis zur offiziellen Veröffentlichung sind Änderungen an einzelnen Schnittstellen möglich
- Aktuell liegt der Fokus auf grundlegender Wiedergabe für Websites; Barrierefreiheit, Untertitel und verschiedene Formate sind möglich, Einstellungsmenüs und Ähnliches sind jedoch noch nicht umgesetzt
- Feedback über GitHub-Issues und Discord wird aktiv gesammelt
- Nutzern bestehender Versionen wird ein Umstieg nach Veröffentlichung des Migrationsleitfadens empfohlen
Weitere Roadmap
- Die allgemeine Verfügbarkeit (GA) wird für Mitte 2026 angestrebt
- Eine Funktionsgleichheit mit Plyr, Vidstack und Media Chrome ist geplant
- Unterstützung für Werbefunktionen ist für die zweite Jahreshälfte 2026 vorgesehen
- Ein Migrationsleitfaden und zusätzliche Presets sind geplant
1 Kommentare
Hacker-News-Kommentare
Falls sich das jemand fragt: Das Syntax-Highlighting-Farbthema dieser Website ist „gruvbox“
Mir persönlich gefällt es sehr, aber es hat ziemlich lange gedauert, bis ich das herausgefunden habe
gruvbox GitHub-Link
Ich habe video.js noch nie benutzt, aber die Seite bzw. die Werbung wirkte auf mich so, als richte sie sich an Leute, die damit ohnehin schon vertraut sind
Beim Lesen habe ich mich vor allem gefragt, worin eigentlich der Unterschied zum HTML-
video-Tag liegt. Geht es nur um andere Steuerelemente?Das
video-Tag ist heutzutage ziemlich gut, aber Video.js hebt sich durch konsistentes Styling über Browser hinweg, erweiterte Funktionen (Analytics, DRM, 360-Grad-Video usw.) und Unterstützung für verschiedene Streaming-Formate (HLS, DASH usw.) abLetztlich kann man vieles auch mit dem
video-Tag umsetzen, aber dabei baut man am Ende im Grunde selbst etwas wie Video.jsvideo-Tag funktioniert nicht in jeder Umgebung zuverlässig. Je nach Browser gibt es viele Edge CasesWenn man einen stabilen Player oder Streaming-Funktionen braucht, ist Video.js die bessere Wahl
Zur Einordnung: Ich habe einen TV-Broadcast-Player für Georgien gebaut, der alles von LG-Smart-TVs aus dem Jahr 2009 bis zu aktuellen Browsern unterstützt hat
Das ist wichtig wegen der dynamischen Bitratenanpassung. Auch das Caching ist effizienter
Ich frage mich, ob sich rund um WebVTT in letzter Zeit etwas geändert hat
Früher wollte ich das Rendering von Untertiteln anpassen, aber das war extrem schwierig
Ich frage mich, warum das nicht als Web Component ausgeliefert wurde
Für mich wirkt das wie der perfekte Anwendungsfall — eingebaute Controls in einem semantisch sinnvollen Objekt
Am Ende haben wir das mit einem React-Shim gelöst, aber das hat wieder andere Probleme verursacht
In VJS 10 haben wir mit einer Struktur aus headless Core + Rendering-Layer einen Mittelweg gefunden
Dadurch unterstützen wir sowohl React-Komponenten als auch Web Components
media-chrome GitHub-Link
Wegen Shadow-DOM-Bugs oder der Kompatibilität zwischen Frameworks verbringt man am Ende mehr Zeit mit der Umgebungskonfiguration als mit dem Player selbst
Die meisten Nutzer kümmern sich darum nicht. Eine JS-Bibliothek + saubere API ist meiner Meinung nach viel besser
React wird allerdings verwendet, weil man dank Tree-Shaking nur den tatsächlich benötigten Code einbinden kann
In normalem HTML ist diese Art der Optimierung noch schwierig, daher fungiert die Build-Pipeline gewissermaßen als Web-Component-Generator
Ich wollte meinen Audio-Player, der bisher Plyr nutzt, auf Video.js umstellen, bin aber in der Standardkonfiguration auf einige Funktionslücken gestoßen
Keine Wiedergabegeschwindigkeit unter 1x, keine Lautstärkeregelung auf Mobilgeräten, keine Skip-Buttons, schwierige Farbanpassung, zu wenige Demos usw.
Wir streben derzeit Feature Parity mit Plyr und ähnlichen Lösungen an, mit GA ungefähr zur Jahresmitte
Ich kenne mich mit Video-Hosting nicht gut aus, habe aber schon HTML5-Videoplayer verwendet
Ich frage mich, ob man serverseitig einen Endpoint bereitstellen muss, der Videostücke direkt ausliefert
Wenn ich mit ffmpeg in 2-MB-Stücke aufteile, wo lege ich die am besten ab? CDN? Eigener Server?
Welche Konfiguration ist am besten, damit Video.js möglichst reibungslos funktioniert?
Das passt gut zu Video.js, und sogar auf LG-TVs ist tag-basierte Wiedergabe möglich
Solange der Server Range Requests unterstützt, übernimmt der Browser den Rest
Ich nutze eine Kombination aus Object Storage + CDN wie DO Spaces, und das funktioniert gut
Encoding und Segmentierung sollten in einem Schritt erfolgen (z. B. mit dem dash-Formatter von ffmpeg)
Um die Segmentlängen von Audio und Video aufeinander abzustimmen, ist der GOP-Rechner nützlich
Üblicherweise encodiert man aus einer hochwertigen Quelle mehrere Auflösungen und lädt sie zusammen mit einem HLS/DASH-Manifest an einen Ort wie S3 hoch
Der Player findet dann über eine einzige Manifest-URL alle benötigten Ressourcen
Der Blogpost war wirklich sehr gut geschrieben
Beeindruckend war vor allem die Art der Erklärung, die den Leser als Fachperson ernst nimmt. Es wäre schön, wenn es mehr Produktankündigungen in diesem Stil gäbe
Glückwunsch, Steve!
Als ich früher bei JW Player gearbeitet habe, war ich von der Einfachheit und dem Theme-System von Video.js beeindruckt
Ich hoffe, diese Version wird ebenfalls ein großer Erfolg
Es hat immer Spaß gemacht, auf FOMS und anderen Konferenzen mit dem JW-Team zu sprechen
Videotechnik ist nach wie vor ein heißes Feld, also komm jederzeit gern wieder zurück
Die Zahl von 88 % ist beeindruckend
Mich würde interessieren, wo der größte Verbesserungshebel lag — vermutlich beim Plugin-System
Ich würde auch gern wissen, ob beim Rewrite wichtige Integrationen kaputtgegangen sind
Mich würden die Architekturänderungen während des Rewrites interessieren und welche Trade-offs es im Vergleich zum früheren Video.js-Design gab