Apache ECharts 6.1.0: zrender-Unterbau, Build im dist-Verzeichnis und die Erweiterungslandschaft
Apache ECharts ist eine leistungsstarke, interaktive Diagramm- und Datenvisualisierungsbibliothek für Browser.
Auf einen Blick
- Was ist das?
- Was das README von apache/echarts über Bezugswege, Build-Befehle, Erweiterungen und Lizenz aussagt, und welche Angaben dort bewusst fehlen.
- Für wen ist es gedacht?
- Passend ist ECharts für Teams, die im Browser fertige, interaktive Diagramme über ein deklaratives Konfigurationsobjekt brauchen und mit dem npm-Paket oder dem jsDelivr-CDN im dist-Pfad arbeiten wollen. Weniger passend ist es, wenn jede Grafik pixelgenau eigenen Renderregeln folgen soll; dort ist D3 die offenere Wahl, weil es Primitive statt fertiger Diagrammtypen liefert.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Aufgabe ECharts im Browser übernimmt
Das README beschreibt Apache ECharts als kostenlose Bibliothek für Diagramme und Visualisierung im Browser, die interaktive und stark anpassbare Grafiken in kommerzielle Produkte bringen soll. Der Ansatz ist deklarativ: Statt einzelne Zeichenoperationen zu programmieren, beschreibt man, was dargestellt werden soll, und die Bibliothek erzeugt daraus die Grafik. Genau diesen Ansatz greift auch der im README zitierte Fachaufsatz auf, der 2018 in Visual Informatics erschien und den Titel ECharts: A Declarative Framework for Rapid Construction of Web-based Visualization trägt.
Die Repository-Metadaten nennen TypeScript als Hauptsprache, während das README von reinem JavaScript spricht. Beides lässt sich vereinbaren, wenn man davon ausgeht, dass die Quellen typisiert sind und das ausgelieferte Paket als JavaScript vorliegt; das README erläutert diesen Punkt jedoch nicht. Zum Abrufzeitpunkt weist das Repository rund 67.000 Sterne, knapp 20.000 Forks und über 1.500 offene Issues auf, Standardbranch ist master, letzte Aktivität Mai 2026.
Was das README nicht liefert, sind Vergleichszahlen. Es gibt weder Angaben zur Darstellungsgeschwindigkeit noch zur Menge der Datenpunkte, ab denen die Bibliothek an Grenzen stößt. Wer solche Werte braucht, findet sie nicht im Repository, sondern muss sie selbst ermitteln.
npm install echarts --save, jsDelivr-Pfad dist und die Download-Seite
Drei Bezugswege listet das README auf. Der erste führt über die Download-Seite unter echarts.apache.org/download.html, der zweite über den wörtlich angegebenen Befehl npm install echarts --save, der dritte über das jsDelivr-CDN, wobei der Paketpfad dist lautet.
Der npm-Befehl ist die Variante, die in ein Build-System passt, und er zieht das Paket ohne Versionsangabe in die jeweilige Abhängigkeitsdatei. Für wiederholbare Builds ist das zu wenig; das README nennt keine konkrete Version und zeigt auch kein Beispiel mit festgeschriebener Nummer, obwohl mit 6.1.0 ein aktuelles Release vorliegt. Der CDN-Pfad dist deutet auf vorkompilierte Dateien hin, ein fertiges script-Tag steht jedoch nicht im README. Welche Dateiformate auf der Download-Seite angeboten werden und wie sich eine heruntergeladene Datei auf Integrität prüfen lässt, bleibt offen.
Für die Konfiguration verweist das README auf das Option Manual unter echarts.apache.org/option.html sowie auf die API-Referenz unter /api.html. Ein Konfigurationsbeispiel druckt das README selbst nicht ab; wer die Struktur des Options-Objekts kennenlernen will, wird an diese beiden Seiten und an die Beispielsammlung unter /examples weitergereicht.
zrender als Canvas-Unterbau von ECharts
Eine technische Angabe im README verdient Aufmerksamkeit: ECharts basiert auf zrender, einer nach eigenen Worten leichtgewichtigen Canvas-Bibliothek, die in einem eigenen Repository unter ecomfe/zrender liegt. Das ist mehr als eine Fußnote, denn es bestimmt, wie die Grafik am Ende im Dokument landet. Canvas-Rendering bedeutet, dass die Grafik als Pixelbild entsteht und nicht als Struktur aus SVG-Elementen.
Daraus folgen praktische Eigenschaften, die das README nicht ausspricht. Einzelne Elemente einer Canvas-Grafik lassen sich nicht über den DOM-Inspektor untersuchen, und Bedienhilfen für Screenreader müssen über die Bibliothek bereitgestellt werden. Das README erwähnt keine Aussage zur Barrierefreiheit und keine Beschreibung, wie Beschriftungen für assistierende Technologien ausgegeben werden. Für Vorhaben mit verbindlichen Zugänglichkeitsanforderungen ist das eine Lücke, die vor der Wahl der Bibliothek geklärt werden sollte.
Ebenso fehlt ein Hinweis auf das Verhalten sehr großer Datenmengen, also darauf, ob und ab welcher Größe die Bibliothek Daten vor der Darstellung reduziert. Das README setzt hier keine Zahlen, weshalb sich Aussagen zur Obergrenze an dieser Stelle nicht belegen lassen.
npm run dev, checktype und release: der Weg in das dist-Verzeichnis
Wer nicht das fertige Paket, sondern den Quellstand nutzt, findet im README eine kurze Befehlsliste. Vorausgesetzt wird Node.js, ausgeführt werden die Befehle im Wurzelverzeichnis des Repositories. Nach npm install startet npm run dev einen Neuaufbau im Watch-Modus, öffnet das Verzeichnis ./test und verweist auf eine Datei mit der Endung -cases.html, die alle Testfälle auflistet. Wer selbst einen Testfall anlegen will, findet Hilfe über npm run mktest:help.
Zwei weitere Befehle ergänzen den Ablauf: npm run checktype prüft die Korrektheit des TypeScript-Codes, npm run release erzeugt die Produktionsdateien im Verzeichnis dist. Damit ist der Weg von den typisierten Quellen zum auslieferbaren Paket nachvollziehbar beschrieben.
Was fehlt, sind die Rahmenbedingungen. Das README nennt keine Mindestversion von Node.js, kein Betriebssystem und keine zusätzlichen Schritte für Windows oder macOS. Auch das Testframework hinter den Falldateien wird nicht benannt. Wer den Build in eine automatisierte Umstellung einbinden will, muss die Node-Version also selbst bestimmen und den Ablauf einmal von Hand durchspielen, bevor er in eine Pipeline wandert.
ECharts GL, vue-echarts und extension-src/bmap im README
Der Abschnitt zu Erweiterungen ist kurz gehalten und besteht aus Links mit je einem Satz Beschreibung. ECharts GL liefert 3D-Diagramme, Globusdarstellung und WebGL-Beschleunigung, echarts-liquidfill zeichnet Füllstandsdiagramme, echarts-wordcloud erzeugt Wortwolken. Für die Einbindung in Vue.js wird vue-echarts genannt, für statistische Auswertungen echarts-stat. Hinzu kommt eine Liste unter dem Titel Awesome ECharts, die weitere Ressourcen sammelt.
Eine Besonderheit ist die Baidu-Karten-Erweiterung. Sie liegt nicht in einem eigenen Repository, sondern im Projekt selbst unter dem Pfad extension-src/bmap und umschließt das Karten-SDK des Anbieters. Das README erklärt nicht, wie diese Erweiterung kompiliert oder eingebunden wird, und nennt auch keine Bedingungen für die Nutzung des Kartendienstes. Wer Karten braucht, trägt hier also zwei Abhängigkeiten: die Bibliothek und einen externen Kartendienst.
Für keine der Erweiterungen nennt das README eine Version, eine Kompatibilitätsaussage zum Hauptpaket oder einen Wartungsstand. vue-echarts etwa wird als Vue.js-Komponente beschrieben, ohne dass eine passende ECharts-Version angegeben wird. Diese Angaben müssen in den jeweiligen Zusatzprojekten nachgelesen werden.
ECharts 6.1.0 gegen D3: wo die deklarative Kürze zur Grenze wird
Der Releaseverlauf ist überschaubar und aussagekräftig: 6.1.0 erschien am 19. Mai 2026, vorausgegangen waren die beiden Vorabversionen 6.1.0-rc.1 und 6.1.0-rc.2 im selben Monat. Das README selbst führt keine Liste der Änderungen, weshalb sich der Umfang dieses Releases aus dem Repository allein nicht bestimmen lässt.
Als Alternative zu ECharts bietet sich D3 an, und der Unterschied liegt im Abstraktionsgrad. D3 gibt Bausteine für Skalen, Achsen und Datenbindung aus der Hand, die Darstellung wird im eigenen Code zusammengesetzt. ECharts kehrt das Verhältnis um und liefert fertige Diagrammtypen, die über Konfiguration angepasst werden. Für Standarddiagramme ist der ECharts-Weg kürzer, für Darstellungen, die keinem vorhandenen Typ entsprechen, wird die Konfiguration schnell umständlicher als eigener Code.
Rechtlich ist die Lage klar umrissen. ECharts steht unter der Apache-Lizenz 2.0, die auch die Nutzung in kommerziellen Produkten und angepassten Varianten erlaubt, solange die Lizenz- und Hinweispflichten beachtet werden. Das README verweist zusätzlich auf den Verhaltenskodex der Apache-Stiftung und auf CONTRIBUTING.md für eigene Beiträge. Fragen richten sich laut README an dev@echarts.apache.org oder an die Mailingliste, Fehlermeldungen an die GitHub-Issues; Angaben zu erwarteten Antwortzeiten fehlen.
Redaktionelles Fazit
Passend ist ECharts für Teams, die im Browser fertige, interaktive Diagramme über ein deklaratives Konfigurationsobjekt brauchen und mit dem npm-Paket oder dem jsDelivr-CDN im dist-Pfad arbeiten wollen. Weniger passend ist es, wenn jede Grafik pixelgenau eigenen Renderregeln folgen soll; dort ist D3 die offenere Wahl, weil es Primitive statt fertiger Diagrammtypen liefert. Vor dem Einstieg sollte man klären, ob die benötigte Darstellung ohne Erweiterung auskommt, und bei Erweiterungen wie echarts-gl oder extension-src/bmap den Wartungsstand des jeweiligen Zusatzpakets gesondert prüfen.
Community-Notizen