We’re excited to share our roadmap for 2023 and beyond with the community! Our most recent blog post outlines the many areas our team is working on and shares the new features you can expect to see in the coming months.
As always, we want to hear from you! What areas have we missed? What new features are you dying to see? We’d love for you to share your thoughts in this thread.
Would love to hear any feedback big and small!
When I think of reasons I might not recommend Streamlit to people (I love Streamlit, by the way), there are two main problems.
First, the main problem for me, is performance. A PyQT GUI will pretty much always run faster and be more customizable than a Streamlit app. Streamlit beats out PyQT is almost every other way (easier to write, active community/forum, pythonic, cloud deployment, modern look), but without the speed, Streamlit is limited to being categorized as a prototyping tool. I truly have no idea how this problem could be solved, maybe the Streamlit team could trailblaze translating Python to C++/Rust but obviously this would be a long and challenging endeavor, especially considering the many libraries that would need to be supported.
The second, smaller problem for me is the flow of Streamlit code. It feels like most of the bugs I encounter and most of the reasons my Streamlit code becomes messy is that I’m limited by the run-from-the-top paradigm of Streamlit. An analogy is that I want to water my crops on a farm with a high level of control, but instead I just have to dig out one path for a stream to take through my farm. Again, I have no solution to this problem, although the idea proposed here to allow specification of whether or not each element gets reloaded seems pretty good.
Here’s my little feedback / suggestions:
1.Do away with the unnecessary page rerun on widget change. Screens with a large widget count, each having their own logic, have severe performance issues; additionally, you have to try and compensate with session state & caching.
2. Give us more native widgets to describe our data and application output. Cards, toggle buttons, and so many others we see in professional applications, are still awaited. Yes, I know people can write their own components, but how many of your target audience are programmers, who will do so? Wouldn’t it make better sense to use something like svelte then?
Recordset views need to be easier. To easily view a dataset, I need to pull it from a database into a data frame, then have limited manipulation ability with aggrid (which needs JS for anything fancy) for most normal use cases. It’s a pain to identify only user-changed fields in long aggrid row and then only write that changed data back to the database.
3. Give me complete design flexibility (with CSS, or some custom Streamlit-created CSS). How to I (easily) colour-code mandatory fields of Streamlit data entry screen without custom CSS?
4. Position Streamlit as the front-end tool for any python application, rather than a easy-to-use tool for ML/AI. Who wants to use flask, Django, flet, if Streamlit gives me all I need, easily?
Nevertheless, Streamlit is still awesome to create with.
Cheers
This is amazing feedback @Shawn_Pereira and @kevinlinxc and I’m writing all this down! Would love any more details on the types of apps you’re building (what you’re connecting to, what other libraries you’re using, how you expect them to be used). Also anyone else reading this thread please also share how you’re using Streamlit to also expand our ideas 
Hi,
Sharing some more feedback hoping it’s helpful 
:
What in the roadmap am I most excited about and why:
st.dataframe: Being able to sort and filter dataframes, as well as edit specific cells, will be a gamechanger. For now the community has been over-relying on the great streamlit-aggrid custom component.
Custom components v2: Custom components built on the current template (v1) experience a few issues (e.g., this one when deploying Streamlit apps on Google Cloud Run), and their performance isn’t all that great, so an improved custom components template will be appreciated. Right now, I always try to find a way with native widgets before even considering custom components.
What else do I think is important:
Improved performance: When apps are small and/or when they have only a few simultaneous users, Streamlit works fine. But the performance for larger apps (and/or apps with more than a handful of users) could really use some improvement.
Official API to interact with server and access websockets: More than a few of us are doing this with the unsupported, internal API, but an official solution (viz. easy to understand and supported) would be great. A common use case is access/concurrency control (e.g., if user opens another session of the app with the same ID, previous session is expired, to avoid concurrency issues).
Ability to add metatags and get app indexed by Google search… including when deploying outside Streamlit community cloud and Snowflake. I think this is something already WIP, but didn’t want to leave it out because it is important.
Compatibility with Python 3.11: Python 3.11 will be released next week, so it would be good to see compatibility issues solved - if there are any. Maybe the performance improvements in 3.11 end up trickling down to Streamlit too? 
Capacity to deal with backlog of bugs and enhancement requests: I am definitely looking forward to the “roadmap for 2023 and beyond” materializing. That being said, the challenges being tackled in it seem quite ambitious, so I hope there will still be enough bandwidth for the backlog of bugs and enhancement requests.
Ok, time for a coffee now. Thanks again for Streamlit and for sharing the roadmap, loving it!!!
I love Streamlit and am using it whenever I need to quickly build a data viz. However, there are some issues that keep me from using Streamlit when I need to build a production-level app. I’ve listed them below, along with suggestions.
1. Performance:
It would be great if we could control when code blocks re-run, and when widgets re-render in Streamlit, based on the user’s interaction with widgets.
For example, a lot of the content in streamlit apps is static (such as text) and just needs to be rendered once. Other content can be re-rendered only if users interact with input widgets.
I understand that Streamlit is built on top of React. In React apps, there’s a method called useEffect that lets us re-render widgets and re-run code blocks only when variables stored in a dependency array are changed:
useEffect({codeBlock}, [dependencyArray]);
Could we bring that method to Streamlit? Here are a couple of use cases:
with st.conditional_render([var1, var2]):
# This code block always runs on the first DOM render,
# and only re-runs if var1 or var2 change.
processed_data = user_defined_function(var1)
st.chart(processed_data)
st.dataframe(var2)
with st.static_render():
# This code block runs on the first render, and remains
# static until the end of the browser session.
st.write(‘some text...’)
static_data = pd.read_csv(...)
chart_data = another_function(static_data)
st.chart(chart_data)
In both cases, only visualization widgets such as text, charts or dataframes would be allowed in the code blocks (no input widgets).
2. Limited layout/widget options:
I noticed that you’re planning to add custom CSS integration while also making it easier to build/use React components. These features will be extremely helpful =D
In addition, it would be great if we could directly edit the Streamlit app’s static index.html file. Also, it would be helpful if we could have an option in the config.toml file to remove Streamlit’s hamburger menu from the UI.
Cheers,
Bada
Coming from the design side of things I’d like to +1 the request for more design flexibility, maybe incorporate something like MUI for more granular control of widget styling, etc. But here are a few items from my design wishlist (already had this list in a sticky note I’ve been compiling over time)
In the big picture context, I see one critical issue for Streamlit: the top-to-bottom, rerun-on-every-interaction paradigm. Forms, session state and caching provide some flow control, but once an app is exposed to users who ask for more interactions, maintaining state becomes really difficult, especially if there are multiple rounds of I/O between the user and the app. So having some form of routing would be really nice.
So far I have been using Streamlit to allow people to search / explore / visualize data and it’s been great. But I now want to write something that lets the users upload files and edit data in a database, and I am wondering whether Streamlit is still the right tool or if it’s the time to bite the bullet, learn some rudimentary frontend skills and switch to a more established web dev framework.
So to me what could make Streamlit the essential UI layer for Python would be drastic improvements in flow control, with a secondary focus on testing and debugging ease.
I would love to use Streamlit cloud but it’s a little too aggressive with GitHub permissions imo… needs access to all private and public repos.
I know this might be a limitation of the GitHub Api but it’s still a bummer
I love streamlit but I have some features I would like to see:
Maintaining state and the linear top down page re-run model works upto a point but doesn’t scale. In the application I was building state management became to complex and I abandoned the project and returned back to coding in a Python web framework directly.
Streamlit has SO much going for it though, and getting a UI connected to data up and running in a few lines of Python is terrific.
What seems to be missing to me is the more “boring” CRUD layer to allow for data driven apps to be able to collect, execute business logic and store data. Extracting data for visualisation is a strong point for Streamlit for sure - but full blown apps no so much.
I know what I want is out of band at the moment for Streamlit, but Ideally a less hacky way of having multipage, state and data driven navigation would be excellent.
Anyway - keep up the good work and thank you!
Here’s a super simple idea to help improve performance:
Instead of always re-running from the top, why not allow users to define checkpoints?
The idea would be that whenever an app (or a page, for MPAs) reaches a checkpoint, it only re-runs from there (instead of re-running from the top). It could be as simple as calling something like st.checkpoint(). This paradigm is a lot simpler to use than conditional re-rendering (which could still be useful for more advanced use cases). It’s the same paradigm as re-running from the top, except you’re only re-running a smaller portion of the app (from a “lower top”).
The best example would probably be something like a wizard: after each step, st.checkpoint() is called, and only the next step is rendered.
Or it could be used to define a header for the app, and effectively disabling re-rendering of the header.
Alternatively, it could also be used as a form caching, by calling st.checkpoint() after fetching some data. The rest of the app could then operate on this data without having to re-fetch it constantly.
A series of checkpoints would effectively split the app into portions (almost like “sub-apps”, or cells in a notebook). For example, two checkpoints would split the app in three:
Also, checkpoints could be given a name (possibly mandatory), which would allow them to be re-defined in conditional logic; for example: st.checkpoint('header'). I don’t quite have a specific use case for this, but why not. If anything, it could be useful to name checkpoints simply as a form of documentation.
In the app, each checkpoint could be rendered as a div (or some other “invisible” container), containing everything “above” it (up to the previous checkpoint, if any).
When interacting with a component, the trick would be to detect in which portion of the app that component is (i.e. which div/container), and re-run the app not from the latest checkpoint, but from that component’s checkpoint.
For example, in this setup, interacting with component 2 does not cause a re-fetching of the data, or a re-rendering of component 1, but does cause a re-rendering of component 2 & 3:
st.checkpoint('header')st.checkpoint('filters')If necessary, a “refresh” button could be added to the header portion, which would force a re-rendering of the entire app (or added to any portion, forcing a re-rendering of that portion onward).
Alternatively, the api could be defined as st.portion_start('name') & st.portion_end('name'), which may be more intuitive for some users (rather than naming a portion at the end of it). But st.checkpoint('name') feels more “streamlitic” to me.
For what I am doing with Streamlit currently, the limitations of the table (not even getting a selected row back, let alone editing) and of the charts (again, not getting selections back) are the biggest blockers.
Therefore, I’m very, very happy to see “interactive everything” in the roadmap.
Visual customisation is also high on my list. Generally I feel that Streamlit apps waste way too much whitespace (compared to, say, Shiny dashboards). Visual customisation is cool, a fully automatic tight / dense layout option would be even better.
Custom components is probably not high on my wish list but I’m quite curious to see how it turns out.
I have less pain than other with the reloading and state management. To be honest, I could easily do without return values at all, just working with session state. Something like an elm-architecture for Streamlit would be cool.
would be great to customize css using Tailwind
or be able to create custom components using stencil or daisyUI
A bit late with replying to this thread but I’ve upvoted other people their ideas the past few months.
As someone that’s been around here since May '21 and that’s using Streamlit more to build out web app ideas(both quick sketches and some apps in production) than building dashboards for data science I’m super happy with the roadmap. 
I agree with a lot of the points mentioned above that “partial/lazy hydration” or an option to choose to use this instead of the full top-down refresh would massively improve performance.
Taking a look at the road map, my wishlist of improvements are:
So a big wishlist 
In addition I’d love it if there’s more developer control over all the widgets, like an extra argument to show/hide the fullscreen button when hovering over an image or an argument to show/hide the URL linking icon (
) of a widget.
I build a lot of small Streamlit apps to make life easier for friends/family/acquaintances/students and it would make using those apps a lot more straightforward without the floating icons on mouse-over which can be kind of confusing for non-technical users(for example: someone accidentally clicks on the show fullscreen image button and wonders where the page has gone, it’s not clear to a lot of users that the exit fullscreen button to close it again is top-right).
So having the option to hide these when necessary would help, just like the hamburger menu!
Really looking forward to the upcoming Streamlit releases!!
Thanks for all the hard work
Love the roadmap 2023. I have used other Python UI such as Panel and Dash.
I love Streamlit from the coding simplicity but these 2 main items need to be addressed ASAP:
1- Performance when you have a real web app. The above threads called out the issues
2- CSS for styling support
@Fhireman FYI I’ve been using Streamlit with 3.11 for a few weeks now. The only issue at first was with missing PyArrow wheels but that works now.
For large image, video and audio ML apps, it would be useful to have a queue and make sure only one item is processed at a time. Even though Pytorch et al already are thread-safe, reading the input and storing the output alone can put high pressure on memory. Having some sort of task queue would be great.
This may already be possible today, but it’s not completely clear how to implement that. Should a lock or sempahore be cached as a singleton?
Having documentation for this usecase would be fantastic.
Hey Thomas!
It’s a bit of a dry take and a complex solution, but we did play a bit with asyncio’s queue in Best (fastest) practice to display live 2D data - #4 by andfanilo and Issue with asyncio run in streamlit - #7 by andfanilo to process images from a queue, hope it can at least help you quick start
Fanilo
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.