Flint – Eine Visualisierungssprache für das KI-Zeitalter

• Flint ist eine Visualisierungssprache, die anhand der Bedeutung von Datenfeldern automatisch Parsing, Achsen, Formatierung und Farben festlegt, sodass sich Diagramme ohne Low-Level-Konfiguration erstellen und anpassen lassen
• Aus semantischen Typen wie Rank, YearMonth, Delta und Temperature leitet sie die für visuelles Encoding nötigen Detailkonfigurationen ab
• Mit einem elastischen Layoutmodell und dem Banking-Prinzip passt sie Größe, Abstände und Anordnung an; wenn ein Diagramm wächst, erweitert sie die Canvas und verringert die Bandbreite, um dichte Layouts zu bewältigen
• Unterstützt 50 Diagrammtypen in Vega-Lite, ECharts, Chart.js und Plotly und erzeugt über Office.js auch editierbare native Excel-Diagramme
• Über eine einheitliche Schnittstelle lässt sich das Backend wechseln und so die Stärken der einzelnen Tools nutzen, etwa hierarchische Sunburst-Diagramme in ECharts, statistische und analytische Traces in Plotly oder die Bearbeitung innerhalb von Excel-Arbeitsmappen

---

Bedeutungsbasierte Spezifikation und automatische Optimierung

• Flint leitet anhand semantischer Typen, die die Bedeutung von Datenfeldern beschreiben, etwa Rank, YearMonth, Delta und Temperature, Parsing, Skalen, Achsen, Formatierung und Farbschemata ab
  • In einer Heatmap, die die Nettoveränderung neuer Nutzer nach Spiel und Monat zeigt, wird game als Category, period als YearMonth und newUsers als Profit festgelegt
  • Entsprechend der angegebenen Semantik werden Parser für Zeitwerte, Achsenformatierung, ein divergierendes Farbschema und der Mittelpunkt automatisch bestimmt
• Für die automatische Layoutoptimierung nutzt Flint ein elastisches Layoutmodell und das Banking-Prinzip, um Größe, Abstände und Anordnung dynamisch an die Canvas anzupassen
  • Wenn ein gruppiertes Balkendiagramm von einer spärlichen 5 × 3-Konfiguration auf eine dichte 22 × 3-Konfiguration anwächst, wird die Canvas erweitert und die Bandbreite verringert
  • Das ähnelt der Art, wie Federn innerhalb eines erweiterbaren Containers ihre Position einnehmen
• Statt fragile Low-Level-Parameter direkt zu bearbeiten, kann das Design allein durch Wechsel des Diagrammtyps und erneutes Verbinden visueller Encodings geändert werden
  • Ein facettiertes Balkendiagramm zur Geschlechts- und Altersverteilung der US-Volkszählung 2000 wird allein durch Ändern des Diagrammtyps in ein Pyramidendiagramm umgewandelt; die übrigen Low-Level-Einstellungen übernimmt der Compiler

Backend-Unterstützung und aktuelle Releases

• Unterstützt 50 Diagrammtypen über Vega-Lite, ECharts, Chart.js und Plotly hinweg; die Galerie enthält 121 Beispiele nach Backend
  • Die einheitliche Schnittstelle verbirgt die unterschiedlichen APIs und Programmiermodelle der einzelnen Backends
  • ECharts kann für hierarchische Sunburst-Diagramme genutzt werden, Plotly für statistische und analytische Traces
  • Über Office.js gibt Flint native Excel-Diagramme aus, die in Arbeitsmappen eingefügt und dort bearbeitet werden können
• v0.4.0 fügte am 24. Juli 2026 38 Plotly-Diagrammtypen sowie 18 Vorlagen für editierbare native Excel-Diagramme hinzu
• v0.3.0 fügte am 19. Juli 2026 ein dynamisches Diagramm-Widget hinzu, mit dem sich Diagrammtypen wechseln und Eigenschaften direkt an Ort und Stelle bearbeiten lassen
• v0.2.2 fügte am 15. Juli 2026 den compact dodge mode und ein Layout für gruppierte Violinplots hinzu

[GN⁺]

Hacker-News-Kommentare

• Selbst im AI-Zeitalter ist die ggplot-API meiner Meinung nach die beste Chart-API. „Grammar of Graphics“ war nicht bloß ein Marketing-Slogan, sondern der Versuch, tatsächlich eine Grammatik zu schaffen, mit der sich alle möglichen qualitativen Grafiken ausdrücken lassen.
  Dieser Prozess ist in https://link.springer.com/book/10.1007/0-387-28695-0 dokumentiert. Ich habe das Buch entdeckt, als ich alte, mit Papier und Stift gezeichnete Diagramme untersucht habe; in den Jahresberichten der Reserve Bank of Australia aus den 1960er bis 1980er Jahren hatten die Charts noch Charakter, während sie Anfang der 2000er zu faden Excel-Diagrammen wurden.
  ggplot reproduziert den Reiz alter Charts zwar nicht vollständig, scheint sich aber bei der Art der Informationsvermittlung stark daran orientiert zu haben. In Abschnitt 20.1 wird die Minard-Grafik zu Napoleons Russlandfeldzug nachgebaut; ein ähnliches Beispiel gibt es unter https://www.andrewheiss.com/blog/2017/08/10/exploring-minard....
  Die Ergebnisse sehen besser aus als bei pyplot und den darauf aufbauenden APIs, und pyplot scheint bei rasterbasierter Darstellung und Textverarbeitung deutlich eingeschränkt zu sein. ggplot ist im R-Ökosystem angesiedelt und deshalb Software Engineers weniger bekannt, aber ich wünschte, die Node.js- und Python-Ökosysteme würden sich stärker an dieser API orientieren

  • Wilkinsons Grammar of Graphics hat ggplot inspiriert; ggplot selbst kommt in dem Lehrbuch gar nicht vor.
    Ich habe auch Algraf veröffentlicht, ein von derselben Philosophie inspiriertes DSL: https://williamcotton.github.io/algraf/demos. In den Demos ist auch die Minard-Grafik enthalten
  • Für Python ist plotnine ebenfalls einen Blick wert: https://raw.githubusercontent.com/rstudio/cheatsheets/main/p...
    Es wurde im Umfeld von RStudio entwickelt, wo ggplot-Erfinder Hadley Wickham gearbeitet hat, und wird derzeit von Posit unterstützt, wo er heute arbeitet
  • Auch die JSON-Spezifikation des Vega-Lite-Backends folgt im Großen und Ganzen den Ideen der Grammar of Graphics. Das kürzlich auf HN vorgestellte ggsql gefällt mir noch besser: https://ggsql.org/
  • Die Semantik der Grammar of Graphics ist bereits ideal für Menschen und Agenten. ggsql implementiert sie als benutzerdefinierte SQL-Funktionen, sodass Agenten leichter damit arbeiten können; daher ist mir unklar, was Flint zusätzlich bietet
  • Wenn du einen handgezeichneten Charme willst und bereit bist, METAPOST zu verwenden, gibt es fiziko: https://github.com/jemmybutton/fiziko

• Ich habe sowohl Flint als auch den Ansatz ausprobiert, AI direkt Vega-Lite-Spezifikationen erzeugen zu lassen, und Flint war nicht die bessere Lösung.
  Flint ist okay, wenn man vordefinierte Chart-Typen auf niedriger Ebene anpassen will, aber wenn Agenten oder Subagenten Vega-Spezifikationen direkt erstellen, sind viel flexiblere und qualitativ bessere Visualisierungen möglich, etwa Markierungen für Minimum und Maximum in Zeitreihen oder annotierte Marker für bestimmte Ereignisdaten.
  Vega-Lite braucht allerdings Spezifikationsvalidierung und konkrete Anweisungen, und man muss ständig Bugs und merkwürdiges Verhalten abfangen. Wenn man schnell starten will, ohne die Diagrammerstellung als eigenen Stack aufzubauen, ist Flint stabiler

• Es scheint darum zu gehen, mehrere Chart-Backends über eine einzige Schnittstelle zu bedienen. Wenn AI Flint schreiben kann, könnte man sie aber auch gleich den Backend-Code schreiben lassen. Warum Backends austauschbar sein müssen, ist unklar.
  Wenn es aber um eine einfache API für LLMs geht, könnte das tokeneffizienter sein

  • Jedes Chart-Backend unterstützt andere Typen. Wenn man wie im Projektbeispiel einfach zwischen einem ECharts-Sunburst und einem facettierten Balkendiagramm in Vega-Lite wechseln könnte, wäre das sehr nützlich

• Microsoft/Flint-Chart wurde auch schon am 2. Juli 2026 vorgestellt: https://github.com/microsoft/flint-chart, https://news.ycombinator.com/item?id=48756577
  Am 8. Juli wurde es dann erneut als „Show HN: Microsoft releases Flint, a visualization language for AI agents“ gepostet: https://microsoft.github.io/flint-chart/#/, https://news.ycombinator.com/item?id=48834924

• Was ist eigentlich das Problem damit, einfach zu sagen: „Erstelle mir mit plotly ein XYZ-Diagramm“?

  • Bei automatisierter Datenvisualisierung braucht dieser Ansatz eine Sandbox, in der der generierte JavaScript- oder Python-Code ausgeführt werden kann. Eine Spezifikation wie Flint kann man validieren und dann direkt rendern; wenn LLMs Flint besser erzeugen als Vega-Lite, könnte das nützlich sein

• Schon vor 22 Tagen gab es eine größere Diskussion dazu: https://news.ycombinator.com/item?id=48834924

• Ein DSL für AI wirkt nicht besonders sinnvoll. Die Modelle wurden auf bestehenden Grafikbibliotheken trainiert und kommen damit bereits ziemlich gut zurecht.
  Langfristig könnte man nach der Veröffentlichung von Flint zwar „Grafik-Benchmarks“ bauen, damit Forschungslabore auf dieses DSL überfitten, aber das erscheint mir als zu viel Arbeit

• Ich weiß nicht, ab welchem Punkt Abstraktion zu viel wird. Reichen Plotly oder Plotly Express nicht aus, und wie soll noch eine weitere JSON-Spezifikation eine neue Ära einläuten?

• Interessant, aber ich weiß nicht, ob es wirklich nötig ist. Es gibt bereits viele ausgereifte Chart-Bibliotheken, darunter Apache ECharts, und am Ende wirkt es wie ein weiteres Neuerfinden des Rads.
  Immer wieder kommt ein neues Tool heraus, bekommt fortlaufend mehr Funktionen, und dann ersetzt ein anderes Tool mit leicht anderer Architektur und Syntax das ursprüngliche.
  Man kann auch die backend-spezifischen Stärken nutzen, etwa ECharts für hierarchische Sunbursts, Plotly für Statistik- und Analyse-Trendlinien oder Excel für Diagramme, die direkt in Arbeitsmappen bearbeitet werden sollen. Oder man wählt einfach eine Chart-Bibliothek, die einem gefällt, und lernt ihre Funktionen richtig, statt nur Voreinstellungen verschiedener Bibliotheken zu mischen und die Feinabstimmung wegzulassen