It's effectively a static site generator aimed at building automated reports and analysis.
https://github.com/evidence-dev/evidence
Previous discussions on HN:
https://news.ycombinator.com/item?id=28304781 - 91 comments
https://news.ycombinator.com/item?id=35645464 - 97 comments
If you want to read about / play around with the version of the product that supports that type of thing, it's in a pre-release here:
I'm a heavy user of data vis, and this looks worth trying.
Looks like McKinsey is doing and open sourcing some interesting things - I've also tried Kedro and while it feels a bit 'heavy' to use, I like a lot the emphasis on structuring the data and steps.
Minor annoyance: new project and it chose YAML over TOML.
Do you have a "why Vizro" kind of explanation somewhere? Would be really helpful early in the docs, or on the GH readme.
Regarding "why Vizro": As we all know it is hard to compare tools like for like, but we see Vizro as a great combination of benefits offered by existing tools (given that some have been mentioned on this thread); it leverages a simplicity and low-code solution approach, but it still enables users the flexibility to customize advanced solutions. It keeps configurations simple even if you create more sophisticated actions/callbacks. It comes with an out-of-the box sophisticated look and feel.
The approach of using a configuration layer to enforce standardisation in the way that components and code is assembled utilises a grammar which is largely tech agnostic, and while it is currently optimised to leverage Plotly and Dash, it could theoretically utilise components from other packages such as StreamLit in future
1) Removal of the need for complex glue code (filters, callbacks, etc.). This is nice so less sophisticated users can develop dashboards.
2) Easy hosting / deployment. I don't want that in the same system (I use dash in my own apps, and it's nice I'm not tied to much of anything else)
That's me extrapolating from a little bit of poking. I could be wrong.
So we introduced this layer to serve as a configuration driven assembly system which implements built-in visual styling and an opinionated approach in terms of both application architecture and UX, in order to enable standardisation in code and user journeys for multi-screen applications and complex interactions between components.
- Spending about 5-10 minutes on your page, I also couldn't figure out why or what you were trying to do. The copy you wrote above is perhaps clearer, but not clear.
- You have less than 5-10 minutes to sell me on what you're doing.
- I began to get it when I clicked on the screenshot, and saw controls with vm.Filter(column=...
- To use this myself, I'd want to be able to add it incrementally to dash / plot.ly apps. You don't want to force yourself to be "the framework." You want to be able to slot into diverse places. The different pieces should be modular enough to do that.
- In one of your other posts, you wrote: "while it is currently optimised to leverage Plotly and Dash, it could theoretically utilise components from other packages such as StreamLit in future." This seems like a very bad idea. Plotly and dash are well-architected and expandable (it's trivial to integrate components from other sources with React). You don't want to reinvent the wheels plotly/dash invented. If you want to slot in other components, please use their architecture.
In other words, clearly communicate your value-add, and focus on that value-add. Don't try to do / be everything. Things outside of that value-add should be PRs back into dash / plot.ly, or independent, modular pieces in their own repos.
We are definitely taking these points into consideration.