Rebrand: "stlite" -> "StLite", "Serverless Streamlit" -> "In-browser Streamlit"?
whitphx opened this issue · 7 comments
StLite
- all lower-case letters "stlite" is hard to recognize as a proper noun.
In-browser Streamlit
- "serverless" is ambiguous as it also means something like AWS Lambda.
For all visitors to this issue: Feel free to leave comments about your thoughts. I'm not an English native speaker so not confident about such wording decisions.
When I search for something like Streamlit with WASM, Streamlit without a server, etc., it often points to stlite. It’s already well-ranked by search engines and LLMs.
So, I vote for StLite because it can leverage the existing ranking in search engines. Additionally, it won’t confuse users if they find some old materials with the old name.
Also, his naming style is in line with similar projects like JupyterLite and Gradio-Lite, users with Pyodide experiences can guess what StLite is on the first sight.
By the way, a subtitle may help newcomers understand what StLite is about. Refer to others like:
- Gradio-Lite: Serverless Gradio Running Entirely in Your Browser
- JupyterLite: A JupyterLab Distribution That Runs Entirely in the Browser
I like StLite :)
+1 for the subtitle idea. The current first phrase on ReadMe is a bit technical:
A standard streamlit user would look for StLite when trying to "Run a Streamlit Application Entirely in the Browser", without needing to know about the underlying technology (WebAssembly, Pyodide ..).
For further targeting of users with only knowledge of Python/streamlit, I'd suggest extending stlite sharing to expose all stlite features in a GUI style. It'd be much simpler if you don't have to edit the raw html source file yourself while still having all the convenience and flexibility features (stlite.mount options, file attachement, app with folders etc ...). Minimizing the effort / learning curve to switch from streamlit to StLite (Drag & Drop, minor configuration and you're ready to go)
Thank you all!
subtitle
That's a nice point! Yes it should be improved as well.
I'd suggest extending stlite sharing to expose all stlite features in a GUI style.
@Abdelgha-4 Thank you! Can you explain it a bit more? StLite Sharing now allows users to write only Python code and share it in several ways. What kind of features do you think should be added?
FYI, these are existing feature proposals to make it easier to use StLite in different ways. Do they cover the use cases you think of somehow?
#875
#901
Btw what about "Stlite" instead of "StLite"? It's easier to type and looks slim?
The CLI is definitely a step in the right direction!
An ideal design IMHO would allow to convert any arbitrary Streamlit application into an Stlite app with a single command:
cd any_streamlit_app_project
stlite build my_app_entrypoint.py "my_stlite_app.html"The HTML generator on stlite sharing allows that partially with some missing features that forces you to to edit the resulting HTML manually to enable them, what I can think of is:
- You can't upload folders on stlite sharing (you can upload multiple files, but if they are inside a folder you'd have to specify it manually after the upload, the more the nesting on your project the worse it is).
- you can't configure streamlitConfig (I think it'd be more convient if stlite sharing or stlite CLI could parse a config.toml directly)
I think a great feature that solves all of this it to be able to upload the whole streamlit project folder and let stlite sharing figure out the rest for you and generate the html.
This could be done in two phases:
- Parse the streamlit project and create the html with the right structure, files and configuration.
- Ultimately if faisable, parse the streamlit app code to automatically "patch" the parts that may need to change due to stlite limitaions.
For example automatically converttime.sleepintoawait asyncio.sleep, and addawait asyncio.sleep(0.1)after everyst.spinner...