This looks really slick, can't wait to try it out!<p>If anyone is curious about other tools in the same space, our data scientists use Dash[1] and plotly to build interactive exploration and visualization apps. We set up a Git repo that deploys their apps internally with every merge to master, so they're actually building and updating tools that our operations, marketing, etc teams use every day.<p>[1] <a href="https://plot.ly/dash/" rel="nofollow">https://plot.ly/dash/</a>
Interesting project, but why does an open source developer tool needs browser telemetry?<p>You should ask for telemetry permissions _before_ the process starts up (as you do for email address), and keep the default as "No", instead of start to send the data transparently unless non user friendly steps are taken by the user.
This is a declarative programming model similar to React. I'm surprised the analogy isn't drawn in the article.<p>"Streamlit assigns each variable an up-to-date value given widget states."<p>This line is interesting because it implies distributed state in each component (widget). Alternatively this could be framed in centralized state manager terminology.<p>"Each widget is provided with the current state of the application, and that state is also available to your script."<p>If you adopt this mindset you can separate the concerns of state and presentation. At first glance it appears that you need to extract state from widgets at the same point as they are added to the page.<p>(Please correct me if I'm wrong.)<p>I might not want to have a widget added to a page until much later in the script, but I want to have access to its state at the top of the script.<p>The value of the top level `props` parameter to a react component is it gives you access to all state wherever you need it, and disentangles this state from the arrangement of the page.
I'm impressed.<p>Installing on my Mac to test this out was very straight-forward:<p><pre><code> cd /tmp
mkdir streamlit
cd streamlit
pipenv shell
pip install streamlit
</code></pre>
Then I could play with the built-in demos by running:<p><pre><code> streamlit hello
</code></pre>
So that was a slick intro - next step was I followed this tutorial: <a href="https://streamlit.io/docs/tutorial/create_a_data_explorer_app.html" rel="nofollow">https://streamlit.io/docs/tutorial/create_a_data_explorer_ap...</a><p>And a few minutes later I had an interactive notebook-style interface for playing with Uber pickup data in New York.<p>This is a really interesting product.
I gave it a try on Windows and ran into an issue, but found a workaround.<p>I'm using WinPython 3.6 on Windows 7. I did "pip install streamlit" and then "streamlit hello", and had to allow it through the firewall, then got a 404 page.<p>The workaround is very simple, just use the provided http address and add "index.html":<p><pre><code> http://localhost:8501/index.html
</code></pre>
This link has more info: <a href="https://github.com/streamlit/streamlit/issues/244" rel="nofollow">https://github.com/streamlit/streamlit/issues/244</a>
Whats the easiest way to make public on the internet a small streamlit powered analysis?<p>I saw there is a Streamlit for teams in the future (sounds expensive) and on the forums they recommended to make a docker container and host it anywhere, which is doable, but I'd love a way to be able to just put something up on the internet for a short period of time, sort of how now.sh[1] works.<p>[1]: <a href="https://zeit.co/home" rel="nofollow">https://zeit.co/home</a>
I am not sure "rerunning the script from top to bottom" is a necessary condition but for the code layout to reflect the expected behavior.<p>How would people compare this to Observable [1]?
1. Javascript vs. Python
2. Client-only vs. server-required?<p>Does the market already give advantage to Python and server-required because the data sets are too large and live on the server, and the users (data scientists) prefer Python and the existing libraries there?<p>[1]: <a href="https://observablehq.com/" rel="nofollow">https://observablehq.com/</a>
It's like embedding Shiny apps into RMarkdown<p><a href="https://bookdown.org/yihui/rmarkdown/shiny-embedded.html" rel="nofollow">https://bookdown.org/yihui/rmarkdown/shiny-embedded.html</a>
I agree on the premise: yes eventually every analysis needs to become an app. Also let me add: no, dashboards are not going to cut it, they don't offer enough interactivity. I also love that the app here is a script and hence can be version controlled with git. However, there is no description anywhere of what happens when you need to scale with this. If you have to go from a couple of testers to 100 internal users like it very often happens in analytics, how does this react?<p>Also caching is a great idea but I would expect a lot of this logic to be managed on the server side, or I am missing something and ML is different here? I would expect to pipe as little data as possible back to the application because I want the user to wait max 3-4 seconds for the app to load at start.
Apart from ML, this could be very useful for creating dashboards in the healthcare setting. Dashboards are surprisingly had to make, deploy, and maintain in the hospital. I've created many one-off webapps for different research groups and have been dreaming of a tool that consolidates all the front end work allowing me to concentrate how to process the data. Streamlit looks incredible for this!
This is awesome! Is there a way to generate a standalone binary, e.g. as an electron app? I'm looking for ways to ship small custom python/pandas data analysis apps including data to non-technical users - but as a local application.
This is spectacular. I have written about this many times on HN itself .<p>Jupyter -> internal tool/API is pretty much the holy grail of bridging data scientists, business teams and engineering.<p>I hope this project doesn't die out. A lot of people would pay for this.
This is pretty neat! As this is an offshoot of some autonomous car project, what would the support be for 3D data. If I wanted to see some LIDAR or Pointcloud data in browser? Esp if its a tf-output.
This looks really promising! I recently wanted to make an interactive GUI to control the inputs to a GAN in order to generate images and visualize how different inputs affect certain properties of the output images.<p>I ended up converting my Python models to TensorFlow.js and creating an ad-hoc Vue.js app [0], but Streamlit could have been very beneficial here, especially if you can just put nginx in front of it and serve it to the masses.<p>[0] <a href="https://thispicturedoesnotexist.com" rel="nofollow">https://thispicturedoesnotexist.com</a>
I use Jupyter notebooks all the time for acquiring, cleaning, and exploring datasets. Occasionally these notebooks mutated into tools for more than just one off exploring. It's always felt a little awkward to use them for more day to day data tasks. Steamlit looks amazing for these cases!
This is truly lovely. I went from ‘pip install’ to reproducing one of our internal dashboards in ~1 hour. One issue: Auth and ACLs seem to be part of the paid/hosted version so it needs extra work to become viable for most people
This looks excellent. I'm an avid RShiny user and can't wait to try this and Dash. Is there an example for how to host (e.g. on aws or google cloud) and make an app available online?
This looks super interesting. I relate to the motivation of building something like this- the endless cycle of creating a Jupyter notebook which becomes a Flask app. I really liked the quick feedback loop for the visual components and the fact that it is all in Python.<p>I haven't checked yet but a question that comes to mind is how extensible is this framework. I can easily see how I'd want to make custom widgets.
This is cool but it's already been on the top page twice this week...<p><a href="https://news.ycombinator.com/item?id=21127528" rel="nofollow">https://news.ycombinator.com/item?id=21127528</a>
<a href="https://news.ycombinator.com/item?id=21126477" rel="nofollow">https://news.ycombinator.com/item?id=21126477</a>
Looks great! Thanks for the hard work Streamlit team. Our team started using Dash recently for an ML project and quickly got lost in callback hell and switched back to a notebook. This approach is so pythonic and elegant. Looks like it would handle our use case with much less code and callback related head aches. I’m excited to share it with our team!
The demo is broken on Macos:
"Streamlit failed to hash an object of type <class 'code'>.,<p>More information: to prevent unexpected behavior, Streamlit tries to detect mutations in cached objects so it can alert the user if needed. However, something went wrong while performing this check.<p>Please file a bug...
"
Cool!<p>requests_cache caches HTML requests into one SQLite database. [1] pandas-datareader can cache external data requests with requests-cache. [2]<p>dask.cache can do opportunistic caching (of 2GB of data). [3]<p>How does streamlit compare to jupyter voila dashboards (with widgets and callbacks)? They just launched a new separate github org for the project. [4] There's a gallery of voila dashboard examples. [5]<p>> <i>Voila serves live Jupyter notebooks including Jupyter interactive widgets.</i><p>> <i>Unlike the usual HTML-converted notebooks, each user connecting to the Voila tornado application gets a dedicated Jupyter kernel which can execute the callbacks to changes in Jupyter interactive widgets.</i><p>> <i>- By default, voila disallows execute requests from the front-end, preventing execution of arbitrary code.</i><p>[1] <a href="https://github.com/reclosedev/requests-cache" rel="nofollow">https://github.com/reclosedev/requests-cache</a><p>[2] <a href="https://pandas-datareader.readthedocs.io/en/latest/cache.html" rel="nofollow">https://pandas-datareader.readthedocs.io/en/latest/cache.htm...</a><p>[3] <a href="https://docs.dask.org/en/latest/caching.html" rel="nofollow">https://docs.dask.org/en/latest/caching.html</a><p>[4] <a href="https://github.com/voila-dashboards/voila" rel="nofollow">https://github.com/voila-dashboards/voila</a><p>[5] <a href="https://blog.jupyter.org/a-gallery-of-voil%C3%A0-examples-a2ce7ef99130" rel="nofollow">https://blog.jupyter.org/a-gallery-of-voil%C3%A0-examples-a2...</a><p>Acess control and resource exhaustion are challenges with building any {Flask, framework_x,} app [from Jupyter notebooks]. First it's "HTTP Digest authentication should be enough for now"; then it's "let's use SSO and LDAP" (and review every release); then it's "why is it so sloww?". JupyterHub has authentication backends, spawners, and per-user-container/vm resource limits.<p>> <i>Each user on your JupyterHub gets a slice of memory and CPU to use. There are two ways to specify how much users get to use: resource guarantees and resource limits.</i> [6]<p>[6] <a href="https://zero-to-jupyterhub.readthedocs.io/en/latest/user-resources.html" rel="nofollow">https://zero-to-jupyterhub.readthedocs.io/en/latest/user-res...</a><p>Some notes re: voila and JupyterHub:<p>> <i>The reason for having a single instance running voila only is to allow non JupyterHub users to have access to the dashboards. So without going through the Hub auth flow.</i><p>> <i>What are the requirements in your case? Voila can be installed in the single user Docker image, so that each user can also use it on their own server (as a server extension for example).</i> [7]<p>[7] <a href="https://github.com/voila-dashboards/voila/issues/112" rel="nofollow">https://github.com/voila-dashboards/voila/issues/112</a>
This looks excellent. Thank you.<p>Can we use asyncio to update multiple charts simultaneously / at arbitrary intervals?<p>Wouldn't it be better if Jupyter absorbed this API for its dashboards?