Rendered at 09:29:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
akst 5 hours ago [-]
Even in the Era AI, GGPlot's API is still the best charting API. The name "Grammar of Graphics" isn't just marketing, they literally sought to write a god damn grammar to was capable of expressing all possible qualitative graphics.
I actually stumbled upon this book when I was trying to look up how draftsmen (with pens and pencils on paper) did qualitative graphics as I found they had a lot of charm as opposed to modern charting libraries. It's something I noticed when looking through a bunch of historical RBA (Reserve bank of Australia) annual reports, the 1960-1980 charts had a lot of character, but then you go into the early 2000s and its a stale chart from excel.
Anyways ggplot doesn't really recapture the magic of those older charts, but it seems use quite a few of those as a baseline for how to communicate information. Like in figure 20.1 they talk about efforts to replicate older inforgraphics that showed Napoleon’s March on Russia, this graphic here (I think the example in the book is a bit nicer than the one in this blogpost IMO)
On top of the charts just look nicer than anything you could produce with pyplot (and any API built on top of it) as pyplot seems to be have some really limited raster based rendering or something and the text handling is incredibly limited, I've never had this issue in ggplot.
I feel like most software engineers aren't exposed to because it exists in the R ecosystem which is more so data scientist, econometricians, statisticians and other quantitative data professions, but it definitely one of the nicer APIs and I wish more people in the node and python ecosystem copied their homework. I see vega's full name is something to do with grammars, but idk it's for the same reason.
williamcotton 3 hours ago [-]
> They even wrote a book about how they went about it (not that it speaks to the quality of the API)
Wilkinson’s Grammar of Graphics inspired ggplot. The textbook doesn’t even mention ggplot.
Shameless plug for my own GoG inspired DSL, Algraf:
How would you quantify the magic of these older charts? What is it that makes them have charm and character?
zem 23 minutes ago [-]
not the parent, but one thing i find charming is that a lot of them have a really good feel for line weight and inking style, and vary it interestingly in various parts of the plot. computer generated charts tend to have a much more uniform line weight.
nialse 3 hours ago [-]
Note that if you are affiliated with a University you probably can download a pdf of the book in the link for free.
akst 3 hours ago [-]
Yeah that's how I got a copy, found it on my unis digital library.
data-ottawa 33 minutes ago [-]
I have tried using Flint vs asking the AI to generate a Vega lite spec directly, and in my opinion Flint was not as nice of a solution.
Flint is fine for doing predetermined chat types, with very low customization. But I found using an agent or sub agent to create the Vega spec directly allowed for a lot more flexibility, and ultimately that means higher quality visualizations (stuff like adding points for min and max on a timeseries, or adding a callout marker for a date where some event happened).
That being said, with Vega lite you have to validate your chart specs, provide specific guidance, and play whack a mole with Vega bugs/idiosyncrasies. So Flint is more reliable if you don’t want to dedicate a whole skill to making charts and want to get running quickly.
shepherdjerred 4 hours ago [-]
So this is one interface that can render to multiple charting backends?
If AI is writing the "Flint", why not just have it write the backend code instead? I'm not sure why I would want pluggable charting backends.
I can see an argument for providing simpler APIs for LLMs, though, so that it can be more token efficient for example.
awestroke 2 hours ago [-]
Different charting backends support different kinds of charts. Being able to easily switch between "ECharts Sunburst" and "Vega-Lite faceted bar" - one of the examples on the project website - seems like a super useful ability.
scary-size 20 minutes ago [-]
Fair. How is this specific to the marketed AI integration? This could just be a unifying abstraction layer for a bunch of, in my opinion, verbose chart APIs. And then the LLM could just be the abstraction layer.
HawtAds 2 hours ago [-]
Interesting, TanStack Charts was also released a couple days ago with a similar design.
What is wrong with "please make plot XYZ in plotly?"
refactor_master 5 hours ago [-]
When does it get too abstract? What’s wrong with plotly? Or plotly express? How is yet another JSON spec era-anything?
woah 5 hours ago [-]
Why is this "for the AI era"? Isn't it kind of not for the AI era since an LLM can create a gnarly python or js chart of whatever you want in seconds?
orbital-decay 3 hours ago [-]
It can write anything, but that's not a guarantee it can easily read and comprehend it later
croes 4 hours ago [-]
Nowadays you either create something with or for AI.
Like you created you own framework for wen apps before.
"For the AI era" is the necessary buzzword
barryhennessy 3 hours ago [-]
Maybe they’re not selling this well. Maybe they’re so close to the AI research that this seems like an obviously good idea.
But there’s not one word of why this is good for LLMs, or how they tested/measured that.
My gut would tell me that a new solution put up against all the vega lite specs it’s already be trained on would be a hard thing to win.
2 hours ago [-]
anigbrowl 5 hours ago [-]
It's cool...but is it needed? I'm thinking of Apache echarts and any of many other mature charting libraries. Kinda seems like reinventing the wheel; thing gets released, thing gets more and more new features bolted onto it, eventually someone offers another thing that's basically the original thing with some slightly different design and syntax opinions...
Switch backends to use their native strengths: ECharts for hierarchical sunbursts, Plotly for statistical and analytical traces, or Excel for editable charts embedded in a workbook.
Or just find a charting library that you like and actually get to know what it can do, vs mixing and matching presets from different libraries but never tweaking them.
yoz-y 2 hours ago [-]
Every time I needed to do charts at work I had a conundrum. Libraries are aplenty but basically only plotly does everything, but it’s not the prettiest. I’d much rather developers contributed new features into existing libraries.
xyzsparetimexyz 4 hours ago [-]
This is just json right? One issue with llms right now it's that if you give them a json specification, they're not always amazing at following it. I think it makes sense to have an agent tool that takes llm json, a file name and a spec path and only writes out the file if it conforms.
mirashii 3 hours ago [-]
> give them a json specification, they're not always amazing at following it
I trust my setup a lot more than whatever this is.
zurfer 2 hours ago [-]
If it's made for LLMs, the spec should be yaml not json. Way more token efficient
2 hours ago [-]
Garlef 29 minutes ago [-]
idk ~ it's either a bit thin or i'd expect something more substantial "for the AI era"
... as the kids would say: "weak sauce"
... and it's just a tool to create charts not a "visualization language"
you could probably vibeslop a pipeline from some ad-hoc DSL to excel or pandas or R and get a better integration with your business context
williamcotton 2 hours ago [-]
So a stringly typed JSON-based DSL without a linter or LSP?
2 hours ago [-]
block_dagger 3 hours ago [-]
Does it do flowcharts and arch diagrams? Doesn’t seem like it.
slicendice 3 hours ago [-]
Can it respond to my several open github tickets?
Culonavirus 4 hours ago [-]
Yeah this is not needed and every single day it is needed even less.
est 4 hours ago [-]
unfortunately JSON is doomed to fail in "the AI era"
LLMs are surprisingly bad at generating JSON.
steve_adams_86 3 hours ago [-]
You can use skills or harnesses to have them validate their json (using plain old JSON validation or schemas) and they seem to have a very high success rate with that gate in place. It's slightly more tokens, but it's reliable
afro88 3 hours ago [-]
Are they in 2026? I haven't had an issue with json and LLMs in a long while
kamikazeturtles 4 hours ago [-]
Why is that?
kburman 6 hours ago [-]
[deleted]
teruakohatu 6 hours ago [-]
Literally the first backend they mention is Vega-Lite.
They even wrote a book about how they went about it (not that it speaks to the quality of the API) https://link.springer.com/book/10.1007/0-387-28695-0
I actually stumbled upon this book when I was trying to look up how draftsmen (with pens and pencils on paper) did qualitative graphics as I found they had a lot of charm as opposed to modern charting libraries. It's something I noticed when looking through a bunch of historical RBA (Reserve bank of Australia) annual reports, the 1960-1980 charts had a lot of character, but then you go into the early 2000s and its a stale chart from excel.
Anyways ggplot doesn't really recapture the magic of those older charts, but it seems use quite a few of those as a baseline for how to communicate information. Like in figure 20.1 they talk about efforts to replicate older inforgraphics that showed Napoleon’s March on Russia, this graphic here (I think the example in the book is a bit nicer than the one in this blogpost IMO)
https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
On top of the charts just look nicer than anything you could produce with pyplot (and any API built on top of it) as pyplot seems to be have some really limited raster based rendering or something and the text handling is incredibly limited, I've never had this issue in ggplot.
I feel like most software engineers aren't exposed to because it exists in the R ecosystem which is more so data scientist, econometricians, statisticians and other quantitative data professions, but it definitely one of the nicer APIs and I wish more people in the node and python ecosystem copied their homework. I see vega's full name is something to do with grammars, but idk it's for the same reason.
Wilkinson’s Grammar of Graphics inspired ggplot. The textbook doesn’t even mention ggplot.
Shameless plug for my own GoG inspired DSL, Algraf:
https://williamcotton.github.io/algraf/demos
There’s a Minard plot in the demos!
In this vein, I think I prefer ggsql that made it to HN recently [0].
[0]: https://ggsql.org/
Flint is fine for doing predetermined chat types, with very low customization. But I found using an agent or sub agent to create the Vega spec directly allowed for a lot more flexibility, and ultimately that means higher quality visualizations (stuff like adding points for min and max on a timeseries, or adding a callout marker for a date where some event happened).
That being said, with Vega lite you have to validate your chart specs, provide specific guidance, and play whack a mole with Vega bugs/idiosyncrasies. So Flint is more reliable if you don’t want to dedicate a whole skill to making charts and want to get running quickly.
If AI is writing the "Flint", why not just have it write the backend code instead? I'm not sure why I would want pluggable charting backends.
I can see an argument for providing simpler APIs for LLMs, though, so that it can be more token efficient for example.
https://tanstack.com/charts/latest
Like you created you own framework for wen apps before.
"For the AI era" is the necessary buzzword
But there’s not one word of why this is good for LLMs, or how they tested/measured that.
My gut would tell me that a new solution put up against all the vega lite specs it’s already be trained on would be a hard thing to win.
Switch backends to use their native strengths: ECharts for hierarchical sunbursts, Plotly for statistical and analytical traces, or Excel for editable charts embedded in a workbook.
Or just find a charting library that you like and actually get to know what it can do, vs mixing and matching presets from different libraries but never tweaking them.
Used correctly, this hasn't been true for a quite a while. Most inference engines have a form of grammar constrained decoding. See, for example: https://vllm.ai/blog/2025-01-14-struct-decode-intro
... as the kids would say: "weak sauce"
... and it's just a tool to create charts not a "visualization language"
you could probably vibeslop a pipeline from some ad-hoc DSL to excel or pandas or R and get a better integration with your business context
LLMs are surprisingly bad at generating JSON.