[amcaskill]

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.

Repo: 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

[anentropic]

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

and then in the docs there's various https://docs.evidence.dev/core-concepts/data-sources/#suppor... like Snowflake, MySQL etc

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.

[amcaskill]

Thanks for the kind words.

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.

You can read about universal SQL here if it’s of interest. https://evidence.dev/blog/why-we-built-usql/

You can template those SQL queries to accept input from input components. This enables you to build extremely performant client side interactions.

Under the hood, Evidence is built on svelte and compiles to a svelte kit application, and you can extend your project with custom svelte components.

Hope that’s helpful — we’re very active in our slack if you ever want to say hi!

[laurels-marts]

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?