New library: stlite, a port of Streamlit to Wasm, powered by Pyodide

There will likely also soon be a way for this “stlite” to also access the local filesystem:

And, what’s amazing, is it would be the client user’s deployed filesystem, not the server filesystem. Which, in many cases makes much more sense.

…I really think with time this stlite approach could and should be the default and preferred way to deploy and share streamlit applications :slight_smile:

That’s interesting!
I’m not so familiar with this technology (now I just know it is called as Native File System API), but just thought how it allows apps to access the local file systems without security concerns - if it is possible to access local Streamlit *.py files from browsers without any UX flaws, that’s great for stlite and it could be a very new and useful way to run Streamlit apps as you said :open_mouth:.

2 Likes

great work

1 Like

Update:

I added DataFrame support so the components using DataFrame such as st.dataframe() and st.line_chart() are now working on stlite.

1 Like

Such an exciting project @whitphx.

Can’t make st.dataframe() work though on Stlite Playground, here’s my code:

import pandas as pd 
import streamlit as st 

df = pd.DataFrame(["hello", "world"])
st.dataframe(df)

And I get:

StreamlitAPIException: stlite is not supporting this method.

Maybe the playground wasn’t updated yet!

By the way, I’m not familiar with those pyodide frameworks, but how feasible would it be to share a specific state of your playground? Think jsfiddle but for Streamlit.

Try force-reloading to ignore the cache.
As the playground app is built as a PWA, it caches the old code on the client-side.

1 Like

Worked, thanks!

Beautiful :balloon:

1 Like

I think it’s possible.
Precisely, you can boot up stlite with any initial code.

Even with the current releases, you can do it although you have to host it on your own infrastructure and stlite is not stable yet. For that, please see the README, or 1littlecoder’s great video.

So I think if we create a code sharing service on top of stlite, it would be something like jsfiddle, and I would like to actually do that.

1 Like

Makes sense. Yes I think it would be a great use-case for stlite! Another naive question: would that be safe against code injection btw? Meaning can one run malicious code? My guess is there’s very little risk considering things are running locally + on the browser.

I can’t find additional risks on stlie now but I can’t either say it is safe as I’m not a security professional.

What kind of injection do you consider?
stlite itself is a purely client-side library. The attacker may be able to inject malicious code into the user scripts hosted on the server that will be loaded into the stlite runtime if there are server-side vulnerabilities, but it’s not stlite’s responsibility of course. Similarly, the stlite main script loads some remote resources including Python packages from PyPI or CDN (e.g. cdn.jsdelivr.net), so the attacker may inject these resources on server-side too.
I think knowing these attackable points is important to consider the potential risks, but I also think these are same as other normal web services and not special things for stlite.

My guess is there’s very little risk considering things are running locally + on the browser.

I think so. As far as I know, the runtime environment on a web browser is sandboxed.

2 Likes

stlite has been updated to support uploading files, so we can now use st.file_uploader().
I think it got closer to practical use cases, for example, where users upload CSV files and get some results.

import streamlit as st
import pandas as pd

import warnings
warnings.filterwarnings('ignore')  # https://discuss.streamlit.io/t/keyerror-warnings/2474/14?u=whitphx

uploaded_file = st.file_uploader("file")
if uploaded_file:
    df = pd.read_csv(uploaded_file)
    st.write(df)

(If you get some errors in the playground app, try force-reloading the page. See this comment.)

st.camera_input() is also supported now but st.image() is still not working with in-memory data, so it may be less practical right now (supporting st.image is planned, of course).

Hi, I made a huge progress; now the following components are unlocked!

  • Media components: st.image, st.video, st.audio
  • matplotlib: st.pyplot
  • File upload/download: st.file_uploader, st.download_button
  • Camera input: st.camera_input

And a new option requirements has been added to install external packages as below (though it’s not available on the playground app yet).

stlite.mount({
  requirements: ["matplotlib"],  // Install matplotlib!
  mainScriptData: `
import streamlit as st
import matplotlib.pyplot as plt
import numpy as np

arr = np.random.normal(1, 1, size=100)
fig, ax = plt.subplots()
ax.hist(arr, bins=20)

st.pyplot(fig)
  `
})

Moreover, Pyodide 0.21.0 has been released a couple days ago which added 34 new C-extensions including opencv-python and xgboost for client-side!

So I created this demo app: Serverless Image Processing App (Source code is stlite-image-processing-app/index.html at main · whitphx/stlite-image-processing-app · GitHub)
that demonstrates using OpenCV and various Streamlit components on stlite, Serverless Streamlit.

demo

7 Likes

This is genuinely awesome! Well done!

1 Like

Many thanks for the great work. I tried to open a “local” csv file using Pandas and it could not find it. Is there some specific protocol I need to follow? Here is the code:

import io
import streamlit as st
import numpy as np
import pyodide.http
import pandas as pd
import plotly.express as px

df = pd.read_csv('./sg-words.csv')

st.table(df)

, and the csf file is in the same folder as index.html.

Agian, thanks for the work.

That is not supported now.

In stlite, the Streamlit server is running inside the browser environment from which it cannot access the local file system. The browser runtime is sandboxed.
It is a reasonable restriction for the security sake.

When you use the file accessing methods such as open() on stlite, it accesses another file system, Emscripten File System, which acts like a normal file system but is a virtual one isolated from the file system on your host environment.
Imagine something like a docker container, which has its own directory structure and it is isolated from the host system and cannot be accessed from the host and vice versa.

FYI,

is a related topic, though it’s not a solution.


Thank you for trying it out! :slight_smile:

Oh that’s an interesting one. Would notably unlock multi-page apps in stlite by scanning pages/ directory!

@aghasemi I think you’re left with at least these two workarounds:

  1. Host the .csv somewhere and use its URL in pd.read_csv("https://whatever.url/to/file.csv"). Kinda cumbersome but you probably want to memoize this using st.experimental_memo to avoid loading the file after every rerun!
  2. Use a st.file_uploader() to let the app visitor input the .csv
1 Like

Thanks. The first option doesn’t work either :rofl: That was indeed my next question to Yuichiro.
I haven’t tried pyodide.http yet. Hope that one works.

@arnaud Thank you!

multi-page apps

This may be included in Multiple scripts · Issue #4 · whitphx/stlite · GitHub (and maybe some additional adjustments specifically for mutli-page apps) :+1:
Technically, the current version of stlite writes the Python script specified via mainScriptData option into the Emscripten File System so that the Streamlit server can read it as if it is a local file. So I plan to simply extend this mechanism to transmit multiple files :slight_smile:


@aghasemi

You are correct.
pd.read_csv() does not work when an external URL is given because it tries to establish HTTP connection to the external server but it is not permitted in the Pyodide environment. See Roadmap — Version 0.24.1 for the details.

So pyodide.httpis the solution although I’m not sure if it works well in a Streamlit script, which I think does not support async code well. If so, this ticket might help in the future.

Or wait for Multiple scripts · Issue #4 · whitphx/stlite · GitHub as described above.


FYI,
https://pyodide.org/en/stable/usage/faq.html#how-can-i-load-external-files-in-pyodide
is also a related topic although this cannot be used within the current stlite API.

Custom components (experimental) support finally came out! I think one of the biggest advantage of Streamlit is the custom components maintained by the community, so they must be available on stlite too :slight_smile:

Along with it, I added the “requirements” button on the playground app so that users can install additional packages.

Now the initial sample code of the playground app has been updated where a custom component, hi-plot is installed and used for demonstration (and Matplotlib too)!

Please note that this is still experimental and not all the custom components are working, for example because

  • The custom component package has C-extension. Such non-pure Python packages must be specially built for Wasm/Pyodide runtime. This is not stlite’s but Pyodide/Wasm restriction. In this case, installing the package fails (see the devtool for now).
    • For example, stmol, streamlit-echarts, or streamlit-webrtc cannot be installed due to this reason.
  • The custom component frontend loads local resources dynamically after initialization.
    • For example, streamlit-ace can run and it works, but its syntax highlight does not, probably, though I haven’t investigated this issue so much.
1 Like

I remember that I had created a Wasm-based real-time video processing custom component, streamlit-fesion in the past as a prototype,
so I tried it on stlite as now the custom component can be installed:

demo
It amazingly worked without any modifications!
It’s completely running on the web browser with a local camera input.

What I did was just

  • On the playground app,
  • Install streamlit-fesion package,
  • Then copy and paste this app.py to the code pane.

Disclaimer:
streamlit-fesion was just a kind of PoC package that I made in a Streamlit hackathon and is not well maintained.
There are many things to improve, for example, its image processing blocks the main thread which leads to bad UX.

I feel that it’s time to come back to this library, as a replacement of streamlit-webrtc for stlite :slight_smile: .