Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!



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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: