Charts built for Chat

Posted by thingsilearned 13 hours ago

225 points | 70 commentspage 3

helloitsmet00 9 hours ago|

How is this distinct from something like Mosaic (https://idl.uw.edu/mosaic/spec/)?

verdverm 4 hours ago||

Man, I didn't think anyone would out yaml helm, but here we are not just templating invisibly scoped files (yaml), but also SQL within them?

Looking forward to the yaml confusion when helm/dbt both see their default "charts/" directory in the same repo, or the dbt chart is set as a config map so it can be updated without rolling a new version of the full app... helm_argo is already a nightmare

rant aside, this does look super useful, and I do have CUE to help with the yamhell, but I may still prefer js/ts options so I can dynamically change the chart (like user clicking a dropdown for a different set of data). Sounds cool until the "dynamic" part of the chart shows it's limitations in crafting your ideal UX

I'll definitely be taking this for a spin, gets at that unbundling and "I need a quick chart" situations

theodorewiles 9 hours ago||

how does this compare w/ evidence (https://evidence.dev/)?

kantselovich 4 hours ago|

All docs for evidence.dev are AI-hallucinated …YMMV

mollifier14 12 hours ago||

A beacon of hope between all the vibe coded JS slop charts and dashboards! I love that this creates artifacts that are readable, maintainable and reproduce the same dashboard consistently (deterministically!), just with fresh data.

thingsilearned 12 hours ago|

Yup, that's exactly the idea.

fletchrichman 12 hours ago||

This looks great can’t wait to try it out

ramesh31 11 hours ago||

Everyone wants to come up with a clever One Spec to Rule Them All for generative UI. My bet is that the bitter lesson still bites. Models will continue getting faster and more error free at single-shot writing things from scratch with primitive libraries, and the flexibility that allows will make all of this for naught.

thingsilearned 11 hours ago|

So this is a fairly domain specific (dashboards) spec and we intentionally avoid getting too generic.

The raw HTML/SVG or base libraries approach may well win out, but it does make it quite hard or impossible for humans to follow along and verify for instance where the numbers on a chart came from.

I think in a future where AI's doing all that verifying (or we just trust it), the AI might still prefer to use a DSL like ours because the abstraction maintains consistency, lowers maintenance, and saves a lot of tokens.

But the most helpful bits of a structured DSL are for sure still for humans. The structured format ensures things are readable and testable. Ours also enables a generative UI, which for now at least is still a much faster way to make visual edits while working with an AI, vs always through it.

mollifier14 10 hours ago||

I think we're still ways out until companies will blindly trust AI that the data they pulled is correct. If a data team member sees a dashboard or chart, their first questions is "Is the SQL below this chart correct?". The easier it is to see the SQL that pulled the data, the better.

thingsilearned 8 hours ago||

Exactly and that's why dbt Charts is a spec in YAML vs a python library. It ensures that the logic stays in SQL where its easy to test and trace.

mirelahmd 10 hours ago||

thats intresting

kelvo_ran 1 hour ago||

[dead]

utopiah 1 hour ago|

I'm an idiot really... based on the title I though it was a chart solution to establish a discussion, with... actual people. I was starting to imagine a shared pointer, a way to interact with a notebook, a la Observable, with the data and a staging environment for each participant, etc. Nope, it's about agents.

Gosh I'm so "behind" it's painful. /s