Is Streamlit actually useful?

[okld]

@timforr

When it works, for simple linear read-only apps, it works well. I’m just concerned that the range of use cases is just much smaller than I had hoped for initially.

Frankly, I feel the same, especially because I’m not a data scientist and because I’m constantly trying to bend streamlit’s standard usage to fulfill particular needs.

However, the framework has so much to offer even outside the data science scope and I’m convinced it’ll be able to cover more and more use cases as time goes by. That said, Streamlit is already quite useful to me. Just as @andfanilo and @Ian_Calvert said, it’s a great replacement (and improvement) for jupyter notebooks and even cli apps to some extent.

@timforr

But I’m concerned that fundamentally the approach that Streamlit has taken is not conducive to anything more advanced than a basic read-only data viewer. The model of re-running the entire application after anything changes is just fundamentally opposed to many kinds of basic user interaction.

I am sceptical that there is a good solution to managing state in a Streamlit application which doesn’t make it more complex than a Flask app. Flask is dead simple to reason about – you hit a route and the code in the route is run.

Well, the Streamlit way of handling things is just like calling a command line tool with a bunch of parameters.

But as you said, there’s this issue of managing state. The current problem here is when an app reruns, you can’t access a widget value prior its declaration/execution. However I’m not sceptical on this matter. One approach I’m working on is to bind a widget to a state variable like so:

print(state.value)
st.text_input("Blabla.", state="value")
state.value = "Hello"  # This assignment updates the widget's value on screen

If you interact with a widget, the whole app will rerun with an up to date state directly from the beginning. Ideally you’d even be able to do something like the third line to set/update a widget value (or markdown text) without using st.empty(): a bi-directional binding.

I’m really curious to see if something like this seems simple enough to use and could be a viable solution for state management with widgets.

@timforr

Pretty much every issue I’ve run in to, just really dumb simple things, the response is “we don’t support that currently, use this hack”. Usually the hacks don’t work either – the app renders with state from the previous run, things are out of sync. God knows what’s going on under the hood.

You encountered the out of sync issue by doing something like this, right?

state.value = st.text_input("Blabla.", value=state.value)

If I’m right about what you’re refering to, I guess something like this should help. I know this is your typical “use this hack” answer , but we have no other solution than using hacks or waiting for an official implementation