There are quite a few libraries for charts and visualization, there are not as many for actually combining many of them with layouts, different components and including the actual implementation of the backend. Dac aims to provide all that as a standard and an implementation.
I mean that's what the Vega team is doing no? They are building the standard grammar (Vega-Lite), along with an implementation (Vega). And they are already quite established with rich ecosystem, and supports a ton of components[0]. The only thing missing is that it expects a CSV or inline data source. But it's probably not too hard to build an extension that connects to a data warehouse with an SQL query.
I am not sure we are on the same page, as far as I am aware Vega doesn't do layout, does it? E.g DAC could use Vega for the charts and still take care of everything else around it.
Observable Framework[0] attempted to fill this niche for a while as well, and we'll likely see some of the implementation details in the new Observable Notebook 2.0 format too.
Well done on the launch! We’ve doubled down on the apps as YAML paradigm a few years ago and its pay great dividends on all fronts, esp now with code gen spinning out apps faster than ever for us (generated yaml). Our largest app is well over 500k lines of yaml - for those complaining about 1000 lines lol. With the right tool stack and conventions its so much easier to read, write. review and maintain.
Shameless plug, we’ve built Lowdefy (open source) and 100s of dashboards using it. Have a look and keen to unpack if you’re interested in sharing experiences. Specially have a look at what we did with operators for dynamic needs.
https://github.com/lowdefy/lowdefy
Love the idea. The ability to PR a dashboard would've helped us in multiple companies.
The two big areas that could use some docs/work:
- Auth (one company was healthtech, so we needed auth even on VPN. The other didn't have a VPN so we needed auth)
- Hosting: If it just needs to be run in a container and it doesn't need to be restarted that's fine. Though if there isn't a hosting document it's often a sign of a service that will need someone to keep it running all the time
What I’ve heard often is that the customer might want to build a dashboard using AI on the fly.
Like imagine you have a site and there’s blank canvas. It has access to some data in the background. The user might be like “build a dashboard showing YoY performance of X and break down the shipments in a table by Y and Z”. Then the agent builds it and persists it such that when they log out and log back in they can see their custom dashboard they assembled themselves.
Have you thought about how these dashboards could be built for an eink screen?
For a while, I was thinking about starting a side project of selling E-ink screens with easily configured dashboards. The project would support hobbies who want to build dashboards powered by a raspberry pi or something. I never pursued it, but it seems like you are now halfway there.
You have trouble with them when you are modifying them by hand or using an LLM to do it? The purpose of this project is having LLMs do it. I found they are about as good at writing yaml as they are writing anything else.
Why do ppl think building something through yaml is ever a good idea??
(I know why: for a platform it’s simpler to parse a yaml than to run code, but it’s almost never a good idea for anything that needs to scale in complexity)
The comments are why I prefer YAML for config over JSON. Of course, JSON is great for many purposes, especially machine to machine. For human to machine, I prefer YAML.
The "agents as primary user" framing is what makes this stand out from other dashboard-as-code tools. Having agents generate dashboards is one thing, but making those dashboards reviewable and standardized is the actual hard part. Curious about the semantic layer — when an agent modifies a metric definition in semantic/, how does validation work? Does DAC flag downstream widgets that would break, or is it more of a "trust but verify" model where you catch issues at render time?
Thanks! DAC does that kind of validation partially, although doesn't validate the usage of the downstream dashboards. That's a very nice idea though.
In terms of validation it will validate queries, metric definitions, chart definitions and all ahead of time, before render. That way agents tend to validate their work much quicker.
The project has been under development for over 6 months. We just open sourced it with a clean history. I am not sure what you expect here, should a project exist for months before it is worthy of a show post?
Might want to add how this compares to other products in the space.
Some that come to mind that are potentially tangentially related/similar:
https://github.com/evidence-dev/evidence
Why not use Vega-Lite[0]? It’s my go-to data viz DSL with Claude.
[0] https://vega.github.io/vega-lite/
There are quite a few libraries for charts and visualization, there are not as many for actually combining many of them with layouts, different components and including the actual implementation of the backend. Dac aims to provide all that as a standard and an implementation.
I mean that's what the Vega team is doing no? They are building the standard grammar (Vega-Lite), along with an implementation (Vega). And they are already quite established with rich ecosystem, and supports a ton of components[0]. The only thing missing is that it expects a CSV or inline data source. But it's probably not too hard to build an extension that connects to a data warehouse with an SQL query.
[0] https://vega.github.io/vega-lite/examples
I am not sure we are on the same page, as far as I am aware Vega doesn't do layout, does it? E.g DAC could use Vega for the charts and still take care of everything else around it.
Observable Framework[0] attempted to fill this niche for a while as well, and we'll likely see some of the implementation details in the new Observable Notebook 2.0 format too.
[0]: https://github.com/observablehq/framework
DaC might be more distinguishable from DAC, although the context obviously also helps readers telling them apart.
Yours sincerely, came here for another DAC
Point taken, thanks! Out of curiosity, which DAC did you come here for?
Most probably: https://en.wikipedia.org/wiki/Digital-to-analog_converter
yup yup I also came here for electronics/digital audio without finishing reading the title. DAC is super standard to read in those spaces.
Consider adding that snazzy gif in the README to the docs landing page. I went straight to the docs and then hunted for a screenshot to no avail.
That's a great idea, will do very quickly, thanks!
Well done on the launch! We’ve doubled down on the apps as YAML paradigm a few years ago and its pay great dividends on all fronts, esp now with code gen spinning out apps faster than ever for us (generated yaml). Our largest app is well over 500k lines of yaml - for those complaining about 1000 lines lol. With the right tool stack and conventions its so much easier to read, write. review and maintain. Shameless plug, we’ve built Lowdefy (open source) and 100s of dashboards using it. Have a look and keen to unpack if you’re interested in sharing experiences. Specially have a look at what we did with operators for dynamic needs. https://github.com/lowdefy/lowdefy
Love the idea. The ability to PR a dashboard would've helped us in multiple companies.
The two big areas that could use some docs/work: - Auth (one company was healthtech, so we needed auth even on VPN. The other didn't have a VPN so we needed auth) - Hosting: If it just needs to be run in a container and it doesn't need to be restarted that's fine. Though if there isn't a hosting document it's often a sign of a service that will need someone to keep it running all the time
What I’ve heard often is that the customer might want to build a dashboard using AI on the fly.
Like imagine you have a site and there’s blank canvas. It has access to some data in the background. The user might be like “build a dashboard showing YoY performance of X and break down the shipments in a table by Y and Z”. Then the agent builds it and persists it such that when they log out and log back in they can see their custom dashboard they assembled themselves.
I reckon this is a simplification of existing BIAC tools (eg, https://github.com/lightdash/lightdash)
Partly, yes. It is a simplification with the perspective that the agents would be the primary builders.
Have you thought about how these dashboards could be built for an eink screen?
For a while, I was thinking about starting a side project of selling E-ink screens with easily configured dashboards. The project would support hobbies who want to build dashboards powered by a raspberry pi or something. I never pursued it, but it seems like you are now halfway there.
I would really hesitate to use a 1000 lines of yaml and modify them. I never found YAML easy to modify after a certain size.
You have trouble with them when you are modifying them by hand or using an LLM to do it? The purpose of this project is having LLMs do it. I found they are about as good at writing yaml as they are writing anything else.
I do it by hand.
Why do ppl think building something through yaml is ever a good idea??
(I know why: for a platform it’s simpler to parse a yaml than to run code, but it’s almost never a good idea for anything that needs to scale in complexity)
What is a better format that allows inline comments, is human readable, and can be easily converted to other formats (json, xml, et al)
The comments are why I prefer YAML for config over JSON. Of course, JSON is great for many purposes, especially machine to machine. For human to machine, I prefer YAML.
DAC currently supports YAML and JSX, what else would be a good alternative?
The "agents as primary user" framing is what makes this stand out from other dashboard-as-code tools. Having agents generate dashboards is one thing, but making those dashboards reviewable and standardized is the actual hard part. Curious about the semantic layer — when an agent modifies a metric definition in semantic/, how does validation work? Does DAC flag downstream widgets that would break, or is it more of a "trust but verify" model where you catch issues at render time?
Thanks! DAC does that kind of validation partially, although doesn't validate the usage of the downstream dashboards. That's a very nice idea though.
In terms of validation it will validate queries, metric definitions, chart definitions and all ahead of time, before render. That way agents tend to validate their work much quicker.
Is this an AI generated comment? The format follows almost exactly the format of your other comments, down to the location of the em-dash.
Semantic layer + validation is the interesting part imo, everything else is table stakes. would lead with that
That's a good point, thanks!
The blurb about this is repeated several times but it is unclear to me what it actually does.
You write a few lines of YAML or JSX and you get a dynamic, interactive dashboard out of it. Do you have any suggestions on how to make it simpler?
Yet another "Show HN" that has existed for less than a week. I wish the rules against AI generated content were applied to all these too.
The project has been under development for over 6 months. We just open sourced it with a clean history. I am not sure what you expect here, should a project exist for months before it is worthy of a show post?
Yes.