Yep, Evidence is doing good work. We were most directly inspired by VitePress; we spent months rewriting both D3’s docs (https://d3js.org) and Observable Plot’s docs (https://observablehq.com/plot) in VitePress, and absolutely loved the experience. But we wanted a tool focused on data apps, dashboards, reports — observability and business intelligence use cases rather than documentation. Compared to Evidence, I’d say we’re trying to target data app developers more than data analysts; we offer a lot of power and expressiveness, and emphasize custom visualizations and interaction (leaning on Observable Plot or D3), as well as polyglot programming with data loaders written in any language (Python, R, not just SQL).
One of the founders of Evidence here. Thanks the kind words Mike - that means a lot coming from you.
I think that distinction is right -- we are focused on making a framework that is easy to use with a data analyst skill set, which generally means as little javascript as possible.
As an example, the way you program client-side interactions in Evidence is by templating SQL which we run in duckDB web assembly, rather than by writing javascript.
Evidence is also open source, for anyone who's interested.
This looks very interesting to me, I'm building a BI reporting tool in my company at the moment, but browsing the docs I felt what I was missing was a clear overview of the architecture.
e.g. you say above that Evidence takes templated SQL and runs it in DuckDB WASM
I guess I am wondering where and when the queries are happening
If I set up a Snowflake data source is it doing a build-time import (like in the new Observable, from this thread) into DuckDB? or DuckDB is connecting to the sources via extensions?
Where does the data live?
My question is really just "how does it work?" and the "What is Evidence? > How does Evidence work?" section on the docs homepage doesn't really answer that at all, it's just a list of things that it does.
That’s good feedback on the docs. The tool has evolved pretty dramatically from where it started and we should revisit those diagrams.
Evidence is a static site generator.
Queries against your sources happen at build time and save to parquet.
Queries against the built in DuckDB web assembly instance happen at runtime.
Sources (snowflake, Postgres, csv files etc.) run at build time.
Pages in evidence are defined as markdown files. You write markdown, components, and code fences.
SQL code fences in pages run in the built in duck db wasm instance which can query across the results from all of your sources. These queries run in the client. We call this feature universal SQL, and it’s quite new.
How fast exactly is DuckDB-Wasm for filtering for interactive coordinated views? Could the inputs be a brush selector range (x0, x1) from a time-series chart and then when you brush it the other components would re-render within… milliseconds? There used to be a cool JS library for this called crossfilter. Not sure if this could be a replacement for it?
