Hey all! To keep this short, I’m curious to hear more about the “motivation” (if that’s the right word) regarding how Streamlit works under the hood, particularly why it differs from a classic event driven framework. I’m on the fence on learning Bokeh vs. Streamlit. Since Bokeh widgets can be made into Streamlit components, it makes sense to me to pay most attention to Bokeh right now, and later learn how to integrate them into Streamlit apps if appropriate. I’m more familiar with the “event driven” framework (defining specific “onClick” callbacks, etc.), so this supports that cause. However, I’m still curious to learn more about why the Streamlit model of always re-running the entire script on events has become so popular, since it sounds so different from what I am used to.
Ultimately, I am using Streamlit/Bokeh to create a dashboard of sorts to optimize model(s) for user supplied data (from text files, probably), plot, interact with model parameters, etc.
If there are other topics discussing these thoughts please point me there!
1 Like
Hi @Bryson_Cale, welcome to the Streamlit community!
Our launch article covers some of your questions:
https://towardsdatascience.com/coding-ml-tools-like-you-code-ml-models-ddba3357eace?source=friends_link&sk=f7774c54571148b33cde3ba6c6310086
In short, the top-down model vs. the callback model of interaction really depends on the user’s background. As you mention, you’ve experienced the event-driven experience first, so it makes sense to you. In contrast, Streamlit hypothesized that “data scientists” (however defined) might be more used to the reproducible research workflow, where you run your script top to bottom each time to ensure there is no hidden state or other oddities. In that sense, understanding the code is a matter of working top to bottom and tracing how things are calculated.
Neither is necessarily better, and of course Flask and any of the other Python web technologies are great open-source projects in their own right. Streamlit resonates with a certain group of users who have either experienced event-driven programming and don’t like it, or who start with the Streamlit model after using the REPL/notebook style programming and really enjoy how fast and linear it is to get started quickly using Streamlit.
I’d love to hear from other people in the community why they like Streamlit, obviously the employees and developers of Streamlit are going to be pretty biased 
2 Likes
I have a background in Mechanical Engineering (with emphasis in scientific computing for robotics, dynamics, and machine vision) and Streamlit lets me write scientific scripts like I would write in Matlab and Jupyter Notebooks, but being fully web based, I’m just a one-click deploy from being able to side load any of my scientific scripts into a fully accessible web app!
One of the primary frustrations for me with past platforms I’ve used has been Matlab’s high cost and closed nature (preventing me from sharing any work with colleagues who lack Matlab) and Jupyter Notebook’s cell based run scheme.
The concept of callbacks can be quite foreign for many of us scientific coders and because our projects often run very linearly and branching, having the UI also run linearly helps us to more intuitively build the comparatively simple UIs needed to run our code.
There is a reason callback based systems exist. They provide a lot of power, much of which has a workaround in Streamlit that will feel strange in use to a callback expert, but for some, having their UI run just as linearly as their code is awesome and worth the workaround.
2 Likes