D3 im Detail

• D3 in Depth ist ein Lernmaterial auf Basis von D3 6 und 7, das zeigt, wie man mit D3.js individuelle Datenvisualisierungen erstellt
• Der Fokus liegt weniger auf der Nutzung einfacher Diagramme, sondern auf der Erstellung individueller Visualisierungen; zugleich lernt man die Bausteine von Web-Visualisierungen kennen
• Grundlagen von HTML, SVG, CSS und JavaScript werden mit der Arbeit in D3 verknüpft und helfen so beim Verständnis webbasierter Datendarstellung
• In Verbindung mit Materialien zu Dashboards und Data Storys mit React, Chart.js und Leaflet lässt sich daraus ein Lernpfad für JavaScript-Visualisierung aufbauen
• Für Leser, die D3 vertieft lernen möchten, eignet es sich als Einsteiger- und Vertiefungsmaterial, das Konzeptverständnis und Praxis verbindet

---

Was D3 in Depth abdeckt

• D3 in Depth richtet sich an D3 Version 6 und 7
• Man lernt, wie man mit D3.js individuelle Datenvisualisierungen erstellt
• Als grundlegende Elemente für die Erstellung webbasierter Visualisierungen werden HTML, SVG, CSS und JavaScript gemeinsam behandelt

Weitere JavaScript-Visualisierungsmaterialien

• Data Dashboards with JavaScript behandelt, wie man mit React, Chart.js und Leaflet Daten-Dashboards erstellt
• Visualising Data with JavaScript behandelt, wie man mit Chart.js, Leaflet, D3 und React Diagramme und Data Storys erstellt
• Eine Leserbewertung stuft dieses Material unter den D3-Büchern hoch ein und beschreibt die Inhalte als klar, leicht nachvollziehbar und konzeptionell solide

[GN⁺]

Hacker-News-Kommentare

• Die Idee, Datenvisualisierung mit D3 zu machen, ist gut, aber wenn man ein etwas höherstufiges Werkzeug möchte, lohnt sich ein Blick auf Observable Plot[1], das vom D3-Team entwickelt wurde
  Es ist eine Bibliothek, die auf D3 aufsetzt und viele Konventionen und Komfortfunktionen zum Erstellen von Graphen, Charts und Plots hinzufügt
  Darüber hinaus gibt es auch noch Observable Framework[2], einen Static-Site-Generator für Visualisierungs-Dashboards, der Plot, D3 und verschiedene andere Bibliotheken unterstützt
  1: https://observablehq.com/plot/
  2: https://observablehq.com/framework/
  • In letzter Zeit reizt mich eher das Gegenteil. Die meisten wissen bereits genau, wie das Ergebnis aussehen soll, aber Frameworks bringen von Natur aus viele vorgegebene Einstellungen mit, und sobald man nur ein wenig davon abweichen will, wird es schmerzhaft
    Bei vielen Arten von Plots ist es tatsächlich oft einfacher, die SVG-Daten direkt zu manipulieren, und so schwer ist das auch nicht
    Ich wünschte, es gäbe Bibliotheken oder Frameworks, die die Manipulation von SVG- oder Canvas-Ausgabe einfacher machen. Kleine Anpassungen sollten sehr leicht sein, aber je höher das Abstraktionsniveau des Frameworks ist, desto schwerer wird es, den vorgegebenen Pfad zu verlassen
  • Observable Plot ist hervorragend. Es ist sehr flexibel und intuitiv nutzbar, weshalb ich es inzwischen dem früher von mir verwendeten Plotly.js vorziehe
    Die Dokumentation ist auch ziemlich gut, aber es fehlt ein brauchbarer API-Referenzabschnitt, daher ist es nicht einfach, Funktionen zu entdecken
  • Ich frage mich, ob es für Web-Visualisierung eine Drag-and-Drop-Oberfläche wie bei Matlab gibt
    Ich versuche das Erstellen von Graphen mit HTML5-Canvas möglichst zu vermeiden, daher wäre ein neuer Ansatz beim Design interessant
  • Plot und Framework sind an das Observable-Ökosystem gebunden und haben ihre eigene Lernkurve. D3 zu lernen ist im Hinblick auf Flexibilität und Kontrolle trotzdem am besten
  • Ich frage mich, ob diese Website auch bei anderen ruckelig wirkt. Bei Webseiten mit viel Inhalt habe ich oft Ruckeln wahrgenommen
    Edit: Mit aktivierter Hardwarebeschleunigung läuft es flüssiger, aber selbst auf einem Ryzen 9 ruckelt es immer noch mehr als erwartet
• Ich mag D3 und habe viel damit gebaut, aber jedes Mal, wenn ich nach ein paar Jahren Pause zurückkomme, erinnere ich mich an fast nichts mehr, die Dokumentation verwirrt mich noch mehr, und es fühlt sich an, als wäre ich wieder ganz am Anfang
  Wenn man mich bitten würde, eine partielle Differentialgleichung zu lösen, die ich seit zehn Jahren nicht gesehen habe, käme ich vermutlich schneller wieder rein
  Ich halte auch die D3-Referenzdokumentation für wirklich furchtbar
  • Ich habe D3 von Version 2 bis 7 intensiv verwendet, und durch all das Refactoring waren Online-Beispiele ohnehin schon schwer zu verstehen und noch schwerer zu aktualisieren
    Inzwischen scheint es aber stabiler zu sein. Statt nur D3 zu verwenden, habe ich angefangen, mit Svelte+D3 in einem stärker imperativen Stil zu schreiben, und damit wurde es greifbarer
    So konnte ich die erzeugten Elemente leichter verstehen, statt sie erst hinterher in den Developer Tools zu untersuchen
    Diese Website hilft beim gemeinsamen Einsatz von D3 und Svelte: https://svelte.recipes/
  • Ich habe das Gefühl, dass dieses Problem dort viel geringer ist als bei anderen Plotting-Bibliotheken
    80 % meiner Arbeit sind eher Anwendung, 10 % System und 10 % Datenanalyse, und manchmal baue ich zwei Wochen lang ein Jupyter-Notebook und schaue es dann zwei Monate lang nicht mehr an
    Die meisten Plotting-Bibliotheken haben viele willkürliche Regeln, die man auswendig lernen muss, und meist mehrere kleine domänenspezifische Sprachen. Ein einfacher String wird dann deutlich komplizierter interpretiert als bei atoi
    Außerdem gibt es in vielen Bereichen aus meiner Sicht Dinge, die falsch laufen, etwa bei der Bestimmung von Achsenbereichen oder beim Umgang mit sehr vielen Punkten
    D3 zwingt einen dazu, vieles selbst zu machen, aber die Schnittstellen dafür sind konzeptionell intuitiv. Statt fremden, aufgeblähten und fehleranfälligen Allzweckcode mit einer API zu verwenden, die sich anfühlt, als würde man ein Schiff in einer Flasche zusammenbauen, baue ich es lieber ordentlich mit D3.js
  • Ich habe D3 viel benutzt und sogar Integrationen für AngularJS und Angular gebaut. Es ist mächtig, aber ich fand es immer alles andere als intuitiv
    Es ist leicht, es falsch zu verwenden, schwer zu debuggen und schwer zu verstehen
    Das heißt nicht, dass sich dieses Problem leicht lösen lässt. Wenn ich sehr spezifische datengesteuerte Grafiken erstellen müsste, würde ich mich wahrscheinlich trotzdem wieder für D3 entscheiden
  • Die menschliche Rechenschnittstelle für die Infinitesimalrechnung wurde über viele Generationen hinweg sorgfältig verfeinert
    Wenn man ein wenig im Original von Newton liest, merkt man sofort, dass das nicht schon immer so war
    APIs an so einem Maßstab zu messen, scheint eigentlich unfair zu sein
  • Ich hatte dieselbe Erfahrung. Als Tech Lead heute fordere ich ziemlich nachdrücklich, keine Bibliotheken zu verwenden, die ein hohes Maß an Domänenwissen voraussetzen
    Code, den selbst der Autor nur schwer versteht, sollte man möglichst vermeiden, und D3 ist ein Paradebeispiel für so eine Bibliothek
• Auch wenn man D3 in der Praxis am Ende nicht nutzt, halte ich es für lernenswert. Der Kern dieser Bibliothek ist, dass die Dimensionen des Ziels der Projektion und die des Datensatzes selbst nicht immer gleich sind
  Wenn man zum Beispiel Daten im Bereich von 0 bis 100 auf einem 1080p-Bildschirm mit 1920x1080 darstellt, muss man irgendwann entscheiden, wie man die Daten für die Bildschirmprojektion skaliert
  Man kann die Mathematik selbst rechnen oder die Berechnung einer Bibliothek wie D3 überlassen
  Auch wenn man Daten nicht im Web zeichnet, wird man sie irgendwann irgendwo visualisieren müssen, und dann ist es nützlich, in diesem Ökosystem Werkzeuge mit derselben Rolle zu finden
  • Eines der ersten PHP-Programme, die ich selbst geschrieben habe, war ein PNG-Generator für einen Binomialverteilungs-Graphen
    Soweit ich mich erinnere, musste ich die Rechtecke für den Graphen passend auf die Größe des gerade erzeugten PNG skalieren
    Natürlich war das sehr trivial und überhaupt nicht mit den erstaunlichen Dingen vergleichbar, die D3 kann, aber es war eine großartige erste Erfahrung damit, selbst Bilder auf dem Computer zu erzeugen
  • Das ist eine gute Erklärung, um das Kernkonzept zu verstehen
    Ich persönlich habe D3 nie als intuitiv empfunden. Das Problem könnte sein, dass es auf zu vielen Abstraktionsebenen zu viele Dinge gleichzeitig machen will
    Wenn es nur um die Projektion von Daten ginge, wäre es leicht zu verstehen, aber die Projektion ist eng mit Achsen und anderen Elementen verknüpft, daher wirkt es wohl so
• Das eigentliche Problem von D3 ist, dass es als Bibliothek nicht wirklich die Visualisierung übernimmt. Es liefert nur Funktionen und Beispiele, mit denen man eine Visualisierung selbst zusammensetzt, und die zentrale Voraussetzung dafür ist ein Expertenverständnis von JavaScript, insbesondere von Closures und funktionaler Programmierung

Ich würde sagen, dass das von mbostock als zentrale Abstraktion von D3 bezeichnete select und die Diff-Berechnung von select eher Komfortfunktionen sind, um ein wiederbetretbares paint() zu schreiben.
Im Grunde ist es nur so, dass paint-Anweisungen als Builder-Anweisungen ausgedrückt werden, selbst in den select-Gültigkeitsbereich gebunden sind und zur Erzielung verschiedener Effekte aufgeteilt werden können.
Gerade im Animationsbeispiel ist erstaunlich wenig von dem, was D3 übernimmt, und man muss die äußere Schleife sowie die Verfolgung des Zustands über die Zeit selbst implementieren.
D3 bietet auch keine Abstraktion, um Visualisierungen als Funktion oder in anderer Form zu kapseln; dieser Teil bleibt als Übung dem Leser überlassen.
Für neue D3-Nutzer ist all das eine große Überraschung oder sogar ein Schock. Es ist ein bisschen so, als würde man eine neue Datenbank einführen und bekäme nur Bibliotheken für Datei-I/O, B-Baum-Indizes und Query-Optimierer, müsste aber alles selbst verdrahten.

• visx ist einen Blick wert. Eigentlich sollte es wohl D4 heißen, also Declarative Data Driven Documents.
  Es ersetzt d3-select, das DOM-Manipulationsmodul von D3, durch React. Dass das möglich ist und gut funktioniert, ist ein Beleg dafür, wie gut D3 entworfen ist.
• D3 ist kein Chart-Toolkit wie matplotlib oder ggplot, sondern eine Low-Level-Bibliothek, um Datenvisualisierungen von Grund auf zu erstellen.
  Je nach Ziel kann es das richtige Werkzeug sein oder auch nicht.
• Ich mochte D3.js und habe es als Kerntechnologie in Dutzenden Datenvisualisierungsprojekten eingesetzt, sowohl kommerziell als auch privat. Trotzdem wirkt die Rendering-Syntax inzwischen so veraltet, dass sie an die jQuery-Ära erinnert.
  Verschiedene Hilfsfunktionen wie Easing oder Skalierung nutze ich weiterhin, aber die eigentlichen Komponenten baue ich heute mit modernen Frameworks. In meinem Fall sind das Vue 3 und TypeScript.
  Trotzdem bin ich D3.js dankbar für die großartige Zeit und dafür, dass es mir viele gute Praktiken der Datenvisualisierung beigebracht hat.
  Mike Bostocks Defaults und Demos waren inspirierend und Beispiele für hohe Standards und passten auch gut zu Tuftes Minimalismus.
  • Wenn es ein Beispiel für Vue 3 und TypeScript zusammen mit D3-Hilfsfunktionen gibt, würde ich es gern sehen.
• Nachdem man D3 gelernt hat, ist es meiner Meinung nach besser, für alles, was unter die Annahme „etwas Diagrammähnliches bauen“ fällt, zu gleichwertigen Werkzeugen statt zu VisX oder React zu wechseln und nicht zurückzuschauen.
  D3 und jQuery sind sich in gewisser Weise ähnlich, und beide neigen dazu, zu Spaghetti-Code zu werden. Werkzeuge wie VisX fügen über dem verwendeten D3 viel Struktur hinzu und halten alles auf vernünftige Weise beherrschbar.
  • Ich nutze D3 schon seit ziemlich langer Zeit gelegentlich und fange jetzt gerade mit React und visx an; es scheint die Lücke zwischen beiden gut zu schließen und wirkt vielversprechend.
    Ich frage mich nur, ob es sich eingeschränkt anfühlt, in dem Sinn, dass man mit dem Werkzeug kämpfen muss, sobald man etwas stärker Angepasstes bauen will, verglichen mit reinem D3.
• D3 wurde von Wilkinsons Grammar of Graphics inspiriert.
  Ein weiteres von GG inspiriertes Werkzeug ist das passend benannte ggplot2 für die Sprache R.
  Es bietet eine deutlich knappere, stärker funktionale Schnittstelle und passt auch gut zu einem seltenen Werkzeug namens Rush, also R-Einzeilern für die Shell, mit denen man CSV per Pipe übergeben und schnell Grafiken erzeugen kann.
• Ich suche weiterhin nach einer Lösung für Diagramme und Charts, die nicht vollständig webbasiert ist. Sie sollte sich über CLI oder als Bibliothek steuern lassen und SVG oder PNG ausgeben können.
  Solche Werkzeuge hängen meist von Browser-Funktionen ab oder verwenden unbeholfene Server-Side-Rendering-Lösungen mit Headless-Browsern für die serverseitige Erzeugung.
  Besonders schön wäre es, Venn-Diagramme programmatisch erzeugen zu können. Merkwürdigerweise gibt es in diesem Bereich fast nichts.
  Einige JavaScript-Chartbibliotheken unterstützen das zwar, aber insgesamt scheint es kaum Unterstützung zu geben.
  gnuplot sieht gut aus, unterstützt aber keine Venn-Diagramme.
• Nur dieses Material hat mir geholfen, D3 zu verstehen. Der Autor reagiert auch schnell und hilft gut.
• Ich habe viel Gutes über Vega[1] gehört, ein Werkzeug, das auf D3 aufbaut.
  Es ist auch eine Abhängigkeit von OpenSearch Dashboards und ermöglicht es Nutzern, benutzerdefinierte Dashboards auf Basis von Log- und Observability-Daten zu erstellen[2].
  Die Vega-Bibliothek könnte das von anderen angesprochene Problem der steilen Lernkurve von D3 zumindest teilweise entschärfen.
  [1] https://vega.github.io/vega/docs/
  [2] https://opensearch.org/docs/latest/dashboards/visualize/vega...