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.
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.
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.
Interesting, TanStack Charts was also released a couple days ago with a similar design.
https://tanstack.com/charts/latest
Yeah I was going to share it too. I watched a yt video yesterday where Tanner talks about how (in contrast to trad component-based libs) it takes a very different approach to composition, letting D3 do the heavy lifting and using its visual grammar, and staying grounded in putting the data (not the component tree) first.
I wish they would provide an ECharts backend, it's probably one of the most performant and featureful charting libraries you can find.