11 Punkte von GN⁺ 2025-04-09 | 2 Kommentare | Auf WhatsApp teilen
  • Apache ECharts ist eine Open-Source-JavaScript-Bibliothek für Visualisierungen, mit der sich Visualisierungen im Web schnell umsetzen lassen
  • Mehr als 20 Diagrammtypen und mehrere Komponenten lassen sich kombinieren, was eine flexible Gestaltung von Dashboards und Analyseansichten ermöglicht
  • Durch Umschalten zwischen Canvas und SVG, progressives Rendering und Stream-Loading unterstützt es das Echtzeit-Rendering von 10 Millionen Datenpunkten
  • Mit datensatzbasierter Verwaltung sowie Datentransformationen wie Filterung, Clustering und Regression lässt es sich für mehrdimensionale Analyseabläufe nutzen
  • Automatisch erzeugte Diagrammbeschreibungen und Decal-Patterns erleichtern auch Nutzern mit Anforderungen an Barrierefreiheit das Verständnis von Inhalt und Kontext der Diagramme

Überblick über Apache ECharts

  • Apache ECharts ist eine Open-Source-JavaScript-Bibliothek für Visualisierungen
  • Die offizielle Website ist unter https://echarts.apache.org zu finden
  • Auf der Homepage wird auf die Veröffentlichung von Apache ECharts 6.1 sowie auf den Changelog hingewiesen
  • Einstiegsmaterialien und Beispiele werden über Get Started und Demo bereitgestellt

Funktionsumfang

  • Diagramme und Komponenten

    • Es gibt mehr als 20 integrierte Diagrammtypen
    • Rund 12 Komponenten werden mitgeliefert; die einzelnen Elemente können frei kombiniert und verwendet werden
  • Rendering und große Datenmengen

    • Zwischen Canvas- und SVG-Rendering kann einfach gewechselt werden
    • Durch progressives Rendering und Stream-Loading können 10 Millionen Datenpunkte in Echtzeit gerendert werden
  • Datenanalyse

    • Daten werden über Datasets verwaltet
    • Datentransformationen wie Filterung, Clustering und Regression werden unterstützt, sodass dieselben Daten mehrdimensional analysiert werden können
  • Visuelles Design

    • Das Standarddesign folgt Visualisierungsprinzipien
    • Responsives Design wird unterstützt und lässt sich über flexible Einstellungen anpassen
  • Community und Erweiterungen

    • Eine aktive Open-Source-Community treibt die Entwicklung des Projekts weiter voran
    • Zudem sind verschiedene Erweiterungen von Drittanbietern verfügbar
  • Barrierefreiheit

    • Automatisch erzeugte Diagrammbeschreibungen werden bereitgestellt
    • Decal-Patterns helfen Nutzern mit Behinderungen, Inhalt und Kontext der Diagramme zu verstehen

Zitiermaterial und Community-Kanäle

  • Nutzer von ECharts können die zugehörige wissenschaftliche Arbeit bei Aktivitäten wie R&D-Projekten, Produkten, Forschungsarbeiten, technischen Berichten, Nachrichten, Büchern, Vorträgen, Schulungen und Patenten zitieren
  • Die zu zitierende Arbeit ist als Visual Informatics, 2018 PDF verfügbar
  • Als Update-Kanäle werden GitHub, WeChat, Weibo und ein X-Konto genannt

2 Kommentare

 
jhk0530 2025-04-09

ECharts ist hübsch und wirklich okay. Ich persönlich fand es einfacher zu benutzen als Highcharts.

 
GN⁺ 2025-04-09
Meinungen auf Hacker News
  • Beim Bau von Briefer (https://briefer.cloud) haben wir so gut wie jede Visualisierungsbibliothek ausprobiert, und ich kann mit Überzeugung sagen, dass Apache ECharts die beste ist.
    Andere Bibliotheken waren meist hässlich, schwer zu benutzen, weil man sie imperativ steuern musste, oder zu wenig flexibel.
    ECharts hat ein schönes Standarddesign, man kann im Backend deklarative Graph-Spezifikationen berechnen und dem Frontend nur noch die zu rendernde Spezifikation schicken, und es ist flexibel genug, um fast alles zu unterstützen, was klassische BI-Tools leisten.
    Wir mussten die Bibliothek nie für neue Features erweitern; alles, was wir brauchten, war bereits enthalten.

    • Darüber hinaus war ECharts unter den Projektabhängigkeiten fast die einzige Bibliothek, bei der man sich beim Upgrade keine Sorgen machen musste, dass etwas kaputtgeht.
      Selbst beim Upgrade von 3.x auf 5.x lief alles allein mit npm update weiter problemlos; das schafft heutzutage selten so viel Vertrauen.
      Es passt gut sowohl zu SSR als auch zu SPAs, und da es größtenteils reines JavaScript ist, funktioniert es nicht nur mit React/Vue/Alpine, sondern auch in klassischen serverseitig gerenderten Apps wie Rails/ASP.NET/PHP reibungslos.
      In einer typischen SSR-App wie https://www.jitbit.com/ kann man mit LINQ-Abfragen auf dem Server Chart-JSON-Objekte erzeugen und an ECharts übergeben; genauso gut funktioniert es, wenn man reaktive Objekte aus einer Vue-basierten SPA übergibt.
      Selbst wenn man Workarounds braucht, etwa um in Tooltips eines Kreisdiagramms fette Prozentwerte anzuzeigen, muss man kaum je in den Quellcode abtauchen; für das meiste gibt es bereits Lösungen, die man leicht per Suche oder LLM findet.
    • Ich glaube, ich hatte mir das vor ein paar Jahren angesehen, habe mich am Ende aber für Chart.js entschieden, und bisher gab es kaum etwas, das damit selbst bei seltsamen einmaligen Custom-Anpassungen nicht möglich gewesen wäre.
      Für Business-Analytics hosten wir selbst einen Metabase-Server.
      Ich wünschte, Metabase hätte mehr Visualisierungsoptionen, aber Modelle und Query-Setup sind dort so einfach, dass Anfragen, die einen Custom-Chart rechtfertigen würden, nicht oft kommen.
    • Kürzlich brauchte ich ein Gradienten-Liniendiagramm, bei dem jede Stufe der Y-Achse eine Farbe darstellt und mit benachbarten Farben verschmelzen muss; nach einigen Tests ergab nur ECharts Sinn.
      Anfangs zögerte ich wegen der fehlenden klaren React-Integration, aber letztlich ließ es sich wie andere JavaScript-Bibliotheken problemlos nutzen und war besser als erwartet.
    • Dieser Einschätzung kann ich schwer zustimmen; https://plotly.com/javascript/ ist ebenfalls sehr gut.
      https://observablehq.com/plot/ beobachte ich auch weiter; das scheint wirklich in eine hervorragende Richtung zu gehen.
    • Die Implementierungsweise sieht sehr ähnlich aus; mich würde interessieren, worin es Chart.js überlegen ist.
  • go-echarts https://github.com/go-echarts/go-echarts ist ebenfalls empfehlenswert.
    Wenn man Charts mit Go-Typen deklariert, bindet der JSON-Marshaller von Go sie automatisch an JSON; ich habe es in mehreren Projekten genutzt, und wenn Issues oder PRs eingereicht wurden, reagierte der Maintainer schnell.
    Die Art, JavaScript-Funktionen und SQL-Queries in Go einzubetten, ist interessant; Daten, SQL, Go und JavaScript vermischen sich auf eigenartige Weise.
    Ein Go-Beispiel, das Daten aus DuckDB holt und eine Candlestick-Chart-Datei mit JavaScript-Tooltips erzeugt, findet sich hier: https://github.com/NimbleMarkets/dbn-duckduck-goose/blob/mai...

    • Ich nutze viel Go und DuckDB, habe für Charts bisher aber eine grobe Kombination aus JavaScript/html/template verwendet.
      Das sieht gut aus, um damit herumzuspielen.
  • Ich halte ECharts für das derzeit Beste.
    Seltsamerweise taucht es in Listen von Chart-Bibliotheken oder Suchergebnissen nicht oft auf, aber nachdem ich chart.js, Google Charts, amCharts, Highcharts und ApexCharts alle ausprobiert hatte, nutzen wir es in unserem Tool/unserer Bibliothek https://docs.chartsql.com/.

    • Vermutlich, weil es ein chinesisches Projekt ist.
      Ant Design Components sind auch wirklich hervorragend, aber nicht annähernd so bekannt, wie sie sein sollten.
    • Ich frage mich, wie es mit D3.js wäre.
      Ich weiß, dass D3.js Low-Level ist, aber mit KI wird es ziemlich einfach.
    • Ich mag VisX, weil es ein hohes Maß an Kontrolle bietet.
    • Ich mag Plotly.
  • Nach dem Test mehrerer Bibliotheken hat sich unser Team letztes Jahr für Apache ECharts entschieden, und wir bereuen es nicht.
    Die Dokumentation ist hervorragend, die Performance gut, es ist stark konfigurierbar und trotzdem leicht zu benutzen, und es unterstützt alle Chart-Typen, die wir brauchen: Balken, gestapelte Balken, Karten, zoombare/scrollbare Zeitreihen, Scatterplots und mehr.

    • Mich würde interessieren, wie es im Vergleich zu ag-grid Charts abschneidet.
  • Line Race sieht wirklich cool aus.
    https://echarts.apache.org/examples/en/editor.html?c=line-ra...
    Wenn man den Schalter aktiviert, startet das Rennen.
    Nebenbei: Norwegen hat sich gut geschlagen.

    • Es sieht zwar sauber aus, aber anders als bei dem von jemand anderem erwähnten Hans-Rosling-Beispiel liefert diese Animation keine zusätzlichen Informationen.
      Man könnte einfach den letzten Frame zeigen und dieselbe Botschaft viel schneller und barriereärmer vermitteln; es ist eine Art Chartjunk.
      https://en.wikipedia.org/wiki/Chartjunk
    • Man sollte Hans Rosling Anerkennung geben: https://www.youtube.com/watch?v=hVimVzgtD6w (2003)
    • Da stimmt etwas nicht.
      Die Daten scheinen life-expectancy-table.json zu sein, aber der Titel verweist auf Income.
      Ich weiß nicht, wo der Fehler passiert ist.
    • Ich frage mich, wie stark „Norwegen hat sich gut geschlagen“ mit dem Ölpreis korreliert.
  • Wenn du eine Chart-Bibliothek für Web-Clients suchst, empfehle ich auch charts.css.
    Ehrlich gesagt wirkt sie wie ein Retter in der Not; das Konzept ist viel einfacher als bei den meisten Chart-Bibliotheken, und trotzdem kann man dasselbe bauen.
    Sie lässt sich sehr leicht an klassisches serverseitiges Rendering, htmx usw. anbinden.
    https://chartscss.org/

    • In eine ähnliche Richtung geht https://pancake-charts.surge.sh/, erweitert mit JavaScript; das mochte ich schon lange.
      Es wurde vom Grafikteam der NYT entwickelt und für Corona-Charts verwendet.
    • Chart.css ist eher eine von unzähligen Bibliotheken, mit denen man Liniendiagramme zeichnen kann, und spielt in einer völlig anderen Liga als ECharts.
    • Bei der Aussage „man kann dasselbe bauen“ frage ich mich, ob damit die ECharts-Demos oder die Demos des kostenpflichtigen amCharts https://www.amcharts.com/demos gemeint sind.
      Ich habe nichts gegen charts.css an sich, aber das fühlt sich an, als würde man ein Plastikspielzeug für Kinder mit einem echten Space Shuttle vergleichen.
      Den Großteil meiner Arbeitszeit verbringe ich mit der Entwicklung schwergewichtiger Business-Analytics-Apps wie Apache Superset; mit etwas wie chart.css lässt sich das nicht umsetzen.
    • Wie die anderen Antworten stimme ich zu, dass ECharts deutlich mehr Funktionen bietet, aber der Ansatz, aussagekräftige Datentabellen in Charts umzuwandeln, wirkt ziemlich gut.
      Ich nutze ECharts zufrieden, aber an Stellen, an denen jede Zeile einer Datentabelle eine Sparkline braucht, müsste ich viel zu viele ECharts-Instanzen erzeugen.
      Für solche Zwecke scheint diese Bibliothek gut zu passen.
    • Die Animationsbeispiele von chartscss sind nervig und wirken auch funktional nicht besonders gut.
  • Es wäre besser, Apache im Namen zu belassen.
    „ECharts, JS-Chart-Paket“ klingt so, als würde die Wartung innerhalb eines Jahres eingestellt; „Apache ECharts, JS-Chart-Paket“ klingt so, als würde es auch nächstes Jahr noch gepflegt.

    • Interessanterweise empfinde ich genau das Gegenteil.
      Wenn Apache davorsteht, nehme ich eher an, dass die Entwicklung zum Stillstand gekommen ist und es sich um ein Legacy- oder nur noch gewartetes Projekt handelt.
      Es gibt auch den Spruch: „Apache ist der Ort, an den Projekte zum Sterben gehen.“
  • Es freut mich, dass ECharts die verdiente Anerkennung bekommt.
    Es ist kaum übertrieben, sie als derzeit beste Open-Source-Visualisierungsbibliothek zu bezeichnen.
    Standardmäßig nutzt sie Canvas, ist schneller als jede andere Bibliothek, die ich ausprobiert habe, und flexibel genug, um eigene Widgets wie Custom Tooltips direkt über den Graphen zu legen.
    Sie stellt außerdem viele Metadaten bereit, etwa die Position bestimmter Punkte im gerenderten Chart, was sich gut im Code nutzen lässt; sie eignet sich sehr gut für den Einsatz in Legacy-Webapps und bietet auf der Website auch die Option, Custom Builds herunterzuladen.
    Auch Streaming-Daten verarbeitet sie hervorragend, mit sehr flüssigen Animationen zwischen Datenänderungen.
    Ich nutze sie seit fast sieben Jahren in mehreren Produktions- und privaten Projekten; sie ist weiterhin meine erste Wahl, und die Dokumentation ist in dieser Zeit deutlich besser geworden.
    Alte Bugs wie der Umgang mit 0 auf logarithmischen Skalen können nervig sein, aber es gibt Workarounds, und Bugs, die typische Use Cases blockieren, habe ich kaum gesehen.

    • Ich weiß nicht, warum sie in Vergleichen von Chart-Bibliotheken so selten auftaucht.
      Sie steht nicht einmal auf der Wikipedia-Seite zu JavaScript-Chart-Bibliotheken; ich bin eher zufällig über Apache Superset darauf gestoßen.
  • In einer schnellen Web-Demo konnte nur diese Bibliothek mit der GraphGL-Komponente sehr große Graphen interaktiv anzeigen und bearbeiten.
    Sie scheint keine besonders bekannte Visualisierungsbibliothek zu sein, ist aber ziemlich interessant.

  • Ich habe mir gerade Chart-Bibliotheken für React/React Native angesehen, und Apache ECharts wirkt als Kandidat für plattformübergreifende Datenvisualisierung vielversprechend.
    Sowohl react-echarts (https://github.com/hugocxl/react-echarts) als auch react-native-echarts (https://github.com/wuba/react-native-echarts), die ich gefunden habe, scheinen aktiv entwickelt zu werden; dass sie unter dem Dach von Apache stehen, ist zudem ein großer Vorteil für die künftige Entwicklungsperspektive und Wartung.