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

[arnaud]

Worked, thanks!

Beautiful

[whitphx]

@arnaud

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.

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.

[arnaud]

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.

[whitphx]

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.

[whitphx]

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).

[whitphx]

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.

[LukeF]

This is genuinely awesome! Well done!

[aghasemi]

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.

[whitphx]

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,

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

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

---

Thank you for trying it out!

[arnaud]

@whitphx

Native File System API

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

[aghasemi]

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

[whitphx]

@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)
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

---

@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.

[whitphx]

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

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.

[whitphx]

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:

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 .

[aghasemi]

I can confirm that calling HTTP works with js.XMLHTTPRequest, but not with pyodide.http.pyfetch, due to being async.

By the way, do you have any idea why I cannot see js.document or JavaScript window object from within stlite?

[whitphx]

do you have any idea why I cannot see js.document or JavaScript window object from within stlite?

I think it’s because in the case of stlite, Pyodide is running on a WebWorker which is separated from the main thread and has a different global context where, for example, window is not available.

[aghasemi]

Oh I see. Thanks. Is there no way to get it to work then?

If not, getting streamlit.components.v1, to work will unlock many of the potential benefits, and ability to run a basic, only-html component such as the one in Code snippet: create Components without any frontend tooling (no React, Babel, Webpack, etc) will do the rest.

But I have a feeling that accessing the underlying DOM and communicating objects with JS is a more native approach here. No?

Shuny by the way has apparently this tags UI elements that can run custom JS code (see their Wordle example). So it might be technically doable.

[whitphx]

Thanks,

getting streamlit.components.v1 , to work will unlock many of the potential benefits

streamlit.components.v1 is already supported (with some exceptions).
Supporting custom components is meaning it.

The technique introduced in that topic is currently not possible on stlite, but it’s not due to the lack of streamlit.components.v1, but of the way to mount multiple files.
If you want to do something like that, please wait for Multiple scripts · Issue #4 · whitphx/stlite · GitHub.

But I have a feeling that accessing the underlying DOM and communicating objects with JS is a more native approach here. No?

No, for this case ^[1].

As I have written, Pyodide is running on a web worker, so it’s not possible anyway.

And even if possible, Streamlit of course does not have such Pyodide-native APIs, so we should not use such APIs on stlite apps too.
stlite is a “transparent” layer that bridges Streamlit to Wasm/Pyodide, so I don’t have a plan to provide its original API including the way to manipulate DOM that will probably conflict or break the original Streamlit design.

For example, especially about this topic, directly manipulating DOM breaks the Streamlit frontend because it is well-managed by its React app and must not be controlled from outside.
As Streamlit already provides a way for devs to do it safely, which is called as “custom components”, where the third-party code is sandboxed in an iframe and guaranteed not to break the other parts of the frontend, so we should follow that way.

Shuny by the way has apparently this tags UI elements that can run custom JS code (see their Wordle example). So it might be technically doable.

From my understanding, Shiny’s ability to inject JS code into the frontend is not such a “native” API.
Shiny being possible to inject frontend code is at the same level to Streamlit being able to load any code into the frontend as a custom component.
Of course the Python versions of both do not have the “native” way to control the frontend JS from the Python code, and both have some APIs to “bridge” them which are tags$script for Shiny and custom components for Streamlit.
The situation does not change even when they are ported to Pyodide environment; stlite for Streamlit and Shinylive for Shiny.
Both stlite and Shinylive simply run Streamlit or Shiny on the web worker with no (or little) modifications and try to keep the original APIs available. Then, they still do not provide the Pyodide-native way to control DOM from Python.

---

1. Maybe, PyScript have a similar philosophy. From my understanding, PyScript is a wrapper of the Pyodide DOM APIs (with some utils). ↩︎

[aghasemi]

I understand your point and it is of course a very strong defence in favour of staying with custom components.

On the other hand, however, I can argue that, Isn’t avoiding such a big work of providing seamless interoperability between JS and Python, where you can even run JS methods as Python functions and just have the output without even noticing it’s a different language, a waste of resources? Custom components can of cour still be there and be preferred as the “cross-platform” solution.

Take this code for example: Isn’t it nice? Why should we need two (or at least one) files in two/three programming languages, just to know the width of the screen?

P.S. This Shiny issue is also interesting. Apparently, you can switch between webworker and main thread with a URL parameter. Is it difficult for STLite to provide the same config parameter?

[whitphx]

Can you create a new GitHub issue for this topic separately and move the discussion there?