Flint - Un lenguaje de visualización para la era de la IA

• Flint es un lenguaje de visualización que permite crear y modificar gráficos sin configuración de bajo nivel, ya que decide automáticamente el parsing, los ejes, el formato y los colores según el significado de los campos de datos
• Infiera la configuración detallada necesaria para la codificación visual mediante tipos semánticos como Rank, YearMonth, Delta y Temperature
• Ajusta tamaño, espaciado y disposición con un modelo de layout elástico y el principio de banking; cuando el gráfico crece, expande el canvas y reduce el ancho de banda para adaptarse a composiciones densas
• Soporta 50 tipos de gráficos en Vega-Lite, ECharts, Chart.js y Plotly, y también genera gráficos nativos de Excel editables mediante Office.js
• Permite cambiar de backend desde una sola interfaz y aprovechar las fortalezas de cada herramienta, como el sunburst jerárquico de ECharts, los traces estadísticos y analíticos de Plotly y la edición dentro del libro de Excel

---

Especificación basada en significado y optimización automática

• Flint infiere parsing, escalas, ejes, formato y esquemas de color usando tipos semánticos que representan el significado de los campos de datos, como Rank, YearMonth, Delta y Temperature
  • En un mapa de calor que muestra el cambio en nuevos usuarios netos por juego y por mes, game se define como Category, period como YearMonth y newUsers como Profit
  • Según el significado especificado, determina automáticamente el parser de valores temporales, el formato del eje, el esquema de color divergente y el punto medio
• La optimización automática del layout aplica un modelo de layout elástico y el principio de banking para gestionar dinámicamente tamaño, espaciado y disposición según el canvas
  • Si un gráfico de barras agrupadas pasa de una configuración dispersa de 5 × 3 a una más densa de 22 × 3, expande el canvas y reduce el ancho de banda
  • Funciona de manera similar a cómo un resorte encuentra su lugar dentro de un contenedor expandible
• Se puede cambiar el diseño solo con cambiar el tipo de gráfico y reconectar la codificación visual, sin tocar directamente parámetros frágiles de bajo nivel
  • Un gráfico de barras facetado que muestra la distribución de población por sexo y edad del censo de EE. UU. del año 2000 puede convertirse en un gráfico piramidal solo cambiando el tipo de gráfico, mientras el compilador se encarga del resto de la configuración de bajo nivel

Soporte de backends y lanzamientos recientes

• Soporta 50 tipos de gráficos en Vega-Lite, ECharts, Chart.js y Plotly, y la galería incluye 121 ejemplos por backend
  • La interfaz unificada oculta las diferencias de API y modelos de programación entre backends
  • ECharts puede usarse para sunburst jerárquico y Plotly para traces estadísticos y analíticos
  • Genera gráficos nativos de Excel que pueden insertarse y editarse dentro del libro mediante Office.js
• v0.4.0 agregó el 24 de julio de 2026 38 tipos de gráficos de Plotly y 18 plantillas editables de gráficos nativos de Excel
• v0.3.0 agregó el 19 de julio de 2026 un widget dinámico de gráficos para cambiar el tipo de gráfico y modificar propiedades en el lugar
• v0.2.2 agregó el 15 de julio de 2026 el modo compact dodge y el layout grouped violin

[GN⁺]

Opiniones de Hacker News

• Incluso en la era de la IA, creo que la API de ggplot es la mejor API para gráficos. “Grammar of Graphics” no era solo una frase de marketing, sino un intento real de crear una gramática capaz de expresar todos los gráficos cualitativos posibles.
  Ese proceso está documentado en https://link.springer.com/book/10.1007/0-387-28695-0. Encontré este libro mientras investigaba gráficos antiguos hechos con papel y lápiz; los gráficos de los reportes anuales del Banco de la Reserva de Australia de las décadas de 1960 a 1980 tenían personalidad, mientras que a principios de los 2000 se convirtieron en gráficos planos de Excel.
  Aunque ggplot no reproduce por completo el encanto de esos gráficos antiguos, parece haber tomado muchas referencias de su forma de transmitir información. En la sección 20.1 se recrea el gráfico de Minard sobre la campaña rusa de Napoleón, y se puede ver un ejemplo similar en https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
  Los resultados se ven mejor que pyplot y las API construidas sobre este, y pyplot parece tener muchas limitaciones en el renderizado basado en ráster y el manejo de texto. Como ggplot pertenece al ecosistema de R, es menos conocido entre ingenieros de software, pero me gustaría que los ecosistemas de Node.js y Python tomaran más referencias de esta API.

  • Grammar of Graphics de Wilkinson fue la inspiración de ggplot, y ggplot ni siquiera aparece en ese libro de texto.
    También publiqué Algraf, un DSL inspirado en la misma filosofía: https://williamcotton.github.io/algraf/demos. La demo también incluye el gráfico de Minard.
  • También vale la pena revisar plotnine para Python: https://raw.githubusercontent.com/rstudio/cheatsheets/main/p...
    Fue desarrollado dentro del entorno de RStudio, donde trabajó Hadley Wickham, creador de ggplot, y actualmente cuenta con el apoyo de Posit, donde él trabaja.
  • La especificación JSON del backend de Vega-Lite también sigue en general las ideas de Grammar of Graphics. Me gusta más ggsql, que apareció recientemente en HN: https://ggsql.org/
  • La semántica de Grammar of Graphics ya es ideal tanto para personas como para agentes. ggsql la implementa como funciones definidas por el usuario en SQL, lo que facilita aún más su uso por parte de agentes, así que no sé qué aporta Flint.
  • Si quieres un encanto de dibujo a mano y estás dispuesto a usar METAPOST, existe fiziko: https://github.com/jemmybutton/fiziko

• Probé tanto Flint como hacer que la IA generara directamente especificaciones de Vega-Lite, y Flint no fue la mejor solución.
  Flint está bien para personalizar a bajo nivel tipos de gráficos predefinidos, pero si un agente o subagente crea directamente especificaciones de Vega, se pueden lograr visualizaciones mucho más flexibles y de mayor calidad, como mostrar mínimos y máximos en series de tiempo o marcadores explicativos para fechas de eventos específicos.
  Eso sí, Vega-Lite requiere validación de la especificación e instrucciones concretas, además de tener que lidiar continuamente con bugs y comportamientos particulares. Si quieres empezar rápido sin construir la creación de gráficos como una habilidad aparte, Flint es más estable.

• Parece que busca manejar varios backends de gráficos con una sola interfaz, pero si la IA puede escribir Flint, me parece que podría escribir directamente el código del backend. No queda claro por qué habría que hacer que el backend sea intercambiable.
  Dicho eso, como API simple para LLM, sí tiene la ventaja de mejorar la eficiencia en tokens.

  • Cada backend de gráficos admite tipos distintos. Si, como en el ejemplo del proyecto, se puede cambiar fácilmente entre un sunburst de ECharts y un gráfico de barras facetado de Vega-Lite, sería muy útil.

• Microsoft/Flint-Chart también fue presentado el 2 de julio de 2026: https://github.com/microsoft/flint-chart, https://news.ycombinator.com/item?id=48756577
  El 8 de julio volvió a aparecer como “Show HN: Microsoft releases Flint, a visualization language for AI agents”: https://microsoft.github.io/flint-chart/#/, https://news.ycombinator.com/item?id=48834924

• ¿Qué tiene de malo simplemente pedir “hazme un gráfico XYZ con plotly”?

  • En visualización de datos automatizada, ese enfoque requiere un sandbox para ejecutar el código JavaScript o Python generado. Con una especificación como Flint, se puede validar y dibujar directamente, y si el LLM genera Flint mejor que Vega-Lite, podría ser útil.

• Hace 22 días también hubo una discusión más grande: https://news.ycombinator.com/item?id=48834924

• Un DSL para IA no tiene mucho sentido. Los modelos fueron entrenados con bibliotecas gráficas existentes y ya las manejan bastante bien.
  A largo plazo, después de publicar Flint, los laboratorios podrían crear “benchmarks gráficos” para sobreajustar los modelos a este DSL, pero parece requerir demasiado trabajo.

• No sé a partir de qué nivel la abstracción se vuelve excesiva. Me pregunto si Plotly o Plotly Express no son suficientes, y cómo otra especificación JSON abriría una nueva era.

• Es interesante, pero no sé si realmente es necesario. Ya existen muchas bibliotecas de gráficos maduras, incluido Apache ECharts, y al final parece otro proceso de reinventar la rueda.
  Se lanza una herramienta nueva, se le van agregando funciones y luego otra herramienta con un diseño y una sintaxis ligeramente distintos reemplaza a la original; el ciclo se repite.
  También se podrían aprovechar las fortalezas propias de cada backend: ECharts para sunburst jerárquicos, Plotly para líneas de seguimiento estadísticas y analíticas, Excel para gráficos editables dentro de un libro. O bien elegir una biblioteca de gráficos que te guste y aprender bien sus funciones, en vez de mezclar presets de varias bibliotecas sin ajustar los detalles.