If you are interested in this, but would prefer to define reports with a markup language (and SQL), I work on an open source code-based BI tool called Evidence, which might be of interest to you.
It's effectively a static site generator aimed at building automated reports and analysis.
Evidence looks incredible! I would start using it right away except I don't see it having any sort of date range picker / filter capability. Is the concept of being able to let our end users filter / drill into graphs with customized queries at odds with how Evidence works? Or are these things just not built yet?
Big fan of evidence, really elegant design. There is also space for both declarative and imperative approaches when it comes to dashboarding / reporting etc.
Vizro looks nice, as does Evidence (mentioned below). I think it's good to remember that these types of apps often don't exist in a silo. It would be excellent to be able to integrate them into a larger platform (Django app, etc) to create a less disjointed experience for consumers.
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.
I am happy to see more libraries in this space. I do not like R, but the Shiny workflow is so much faster and easier for novices to bang out some value. Streamlit is really heavy in comparison.
Minor annoyance: new project and it chose YAML over TOML.
This is interesting. I've built reports in Dash before. As I remember it was kind of tricky to hook up the filters etc, and "callbacks" confused me for a while.
Is that the kind of thing Vizro addresses?
Do you have a "why Vizro" kind of explanation somewhere? Would be really helpful early in the docs, or on the GH readme.
Thank you very much for your feedback! I am one of the engineers on the team. Indeed, what you describe is certainly one of the issues we wanted to address.
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
Thank you for your feedback! I am one of the engineers on team :)
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.
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