Launch HN: Evidence (YC S21) – Web framework for data analysts

Thanks for answering. The approach about adding the date on the where clause may not work. I may receive/ingest more data from that point in time after I made the report. Of course, the report wouldn't be updated, but I'd prefer to have an updated report that says "We did it witht he data available at this time" and not one that says one thing but shows a different thing.

Kudos on the launching anyway!

Good point. Late arriving data is such a challenging problem. Perhaps if you have the load date, you could condition on that. We will think about the 'snapshot the outputs' approach as well.

Absolutely no need to apologize, thanks for taking the time to check out our project.

I have written a lot of R Markdown over the years, and I agree wholeheartedly with most of what you're saying. The R ecosystem is phenomenal. Anyone who is excited about our project, might be 10x more excited about learning R and writing a report with R markdown.

A big part of why we are building Evidence is that my co-founder Sean and I felt like we lost a lot on the presentation side when we graduated from notebooks to primarily working with data warehouses, dbt & BI tools.

The thing is, we gained so much from that transition to 'the modern data stack' that we would never go back. So we're setting out to fix the presentation layer in a way that would have worked for us.

Undoubtably, anything that you could accomplish in Evidence is going to be do-able within the R Markdown or jupyter ecosystems, so I won't try to claim any truly unique features. It's maybe more of a vibe: what's easy in Evidence vs. what's tricky in a notebook?

If you're writing an ML paper, R markdown is definitely the move. If you're trying to build a common, internally consistent understanding across hundreds (thousands) of people about how your business is doing, and what they might do about it, Evidence is going to be a better fit.

Here's a comment from awhile ago discussing the comparison with Jupyter: https://news.ycombinator.com/item?id=27363349

It only supports SQL and Markdown:

That constraint is part of the point.

In a large organization, a fair number of people are going to contribute to your reporting apparatus, and you want to keep it in a state where you can re-factor useful abstractions up into your data warehouse. This gets a lot harder if your reporting is a swirl of R scripts and python snippets and whatever else.

Some order of magnitude more people know SQL and markdown than R or Python. Every business I have been involved in has someone there who is cranking out analysis and data pulls using SQL. Very rarely would that person be comfortable working in R markdown.

You can't in-line an ML model into your reports:

Again, we think this constraint is basically a good thing. If you have a model that is profitable to your business, it should be governed and executed in a purpose built environment and, where feasible, you should be storing the relevant outputs for posterity in your data warehouse.

We will add instructions on setting the port! :)

Thanks for the kind words!

1. Yes, if you have specific DBs, please feel free to create an issue on Github. We're also working on opening up the DB connector ecosystem so that people can add their own. I've also opened an issue for CSVs, I think we could support them pretty seamlessly.

2. Evidence is actually pretty slick in this regard. This is one of the benefits from starting from a web framework and working backwards towards the data analyst, rather than starting from Jupyter and trying to work forwards (if that makes sense).

The markdown documents compile to svelte components, so you can just add tag, and/or a tag right into your .md file. d3 works pretty seamlessly in svelte, so you can go nuts. The other neat thing is the styles scope themselves to the

We haven't written the docs for this portion yet, but you can also add global svelte components to your project, so if you wanted to write something re-usable you can write it that way, and then just import it into your reports to use it as a component. In either case, you could call out to other APIs if you didn't want to retrieve data via a SQL query.

As an example, an add-on component library we'd like to build is an interface to FRED data from the St Louis Fed. That way if you just need a quick chart of GDP, or you want to add recession shading to one of your charts, you can just drop it in without having to load that data into your database. that type of thing.

There's a discussion earlier in the thread about static vs. live data. I think there are some interesting things we could do here.

There are also some other great products doing data diffing, like datafold that might fit the bill here.