Jupyter Notebooks to Web App | Hacker News Reader

Jupyter Notebooks to Web App

github.com

91 pointschristianjung18 comments

A mature implementation exists, called voilà, see https://github.com/voila-dashboards/voila, which is developed by members of the Quantstack.

Thanks for letting me know about streamlit:

https://www.streamlit.io/

seconded. i have seen and heard the name but thought it was yet another python web framework -- like, you know, we be getting a lot of them lately.

i will definitely check it out because i always wondered that jupyter is fun and game, but how do you productionize your work after?

Here is a link to their forum: https://discuss.streamlit.io/

Jupyter notebooks are a bitter reminder that worse is better.

I'm a data scientist and I hate them.

Can you elaborate why, I've heard mostly love for them.

My main gripe with them is that the dependencies between the cells are implicit and the results of each cell are resident in memory instead of a more durable form (like artifacts on disk).

The best way to understand why I hate notebooks is to contrast them with my workflow: when I do data science, each step in the process is represented by a Makefile target which lists its products and its dependencies explicitly. All products are represented as concrete objects on disk (json, csv, figures, or serialized representations in some form).

If I need to do reporting, its typical for various targets to generate fragments of latex and for the report (a pdf) to explicitly document which fragments of latex and which figures belong in the report.

Them a simple `make report.pdf` is enough to generate the final result. If I change something I can explicitly see which pieces need to be rebuilt and how.

I also believe that the structure of a notebook, which mixes code and reporting, encourages bad software design practices like copy-pasting - it doesn't naturally encourage refactoring of shared code into libraries or anything like that. Most jupyter notebooks are just a pile of shit, basically. The big problem is that all the cells in a notebook share one, big, mutable, global state. This is wrong.

They also don't work well with git, which I view to be the absolute crux of any successful technical project.

This is the big difference between 'data scientist' and 'software engineer'. Your workflow is almost certainly repeatable and verifiable, which is just better science.

The crux is is that Jupyter was not made for people with your skills, or more accurately, pattern. What you do is not inherently hard or complicated. Certainly not more than actual data science. It's a cultural thing mostly.

I'm prepared to argue that a data scientist who doesn't apply this level of rigor to their work is almost certainly doing a bad job, though they may deliver results that are good from moment to moment.

The key differences is how traceable and repeatable the process is.

Agreed, my personal gripe has always been that notebooks encourage people to write code with _no_ functions or abstraction, often leading to 400 lines of gobbledygook with bad variable names that somehow gives you F1 scores and graphs at the end. You can write functions in notebooks (and I do when I write mine), but there is not a culture of this in place, and arguably the notebook interface itself encourages you _not_ to write functions.

My personal opinion is just that I don't like jupyter notebooks... If your thinking of deploying the code as an app you really shouldn't be using notebooks in the first place. In fact for anything even modestly complex you shouldn't be using notebooks... Your never going to get the habit of writing good code... But different things work for different people I guess

There was another cool streamlit introduction posted on hn some time ago: https://towardsdatascience.com/coding-ml-tools-like-you-code...

Streamlit doesn't natively work with Jupyter however.

Streamlit's docs talk about magic, and their contributions guide mentions protobufs for Python and JS. Nowhere can I find info on how this actually works under the hood. Is it possible to extend without writing JavaScript?

Hey, Streamlit co-founder here! (I'm otherwise not related to this article, btw. Just saw it on HN. Super cool!)

If I understand correctly you're trying to extend Streamlit in some way? If so, we have some features coming out in a few months you will probably like. More news on what exactly in a few weeks. Stay tuned :)

If you have any other questions, check out our forums at https://discuss.streamlit.io

Cheers

hey tvst, op here. Love your work!

That for the info! More than I was hoping to see a page with a 30sec architecture overview of how your magic works so I'd know what's even possible.

Great work! Would you know if this can be used to deploy interactive ML models?

Reply on news.ycombinator.com