Streamlit Is a Mess: The Framework That Forgot Architecture

Introduction #

I’ve been working with Streamlit for a while now, primarily collaborating with non-technical teams. After all, that’s what Streamlit was built for, right? Today, I want to share my frustrations and thoughts about this tool that promises so much but might be setting up teams for future challenges.

The Promise vs. Reality #

Streamlit markets itself as “A faster way to build and share data apps” and claims you can “Turn your data scripts into shareable web apps in minutes. All in pure Python. No front‑end experience required.”

It sounds fantastic on paper. And truthfully, it is - until your application grows beyond a few hundred lines of code. That’s when the trouble begins, and the architectural decisions (or lack thereof) start to show their true colors.

The Custom Components Conundrum #

While Streamlit enables rapid development in pure Python, any non-trivial application will eventually require custom components. Here’s where it gets interesting: like many others in the industry, Streamlit uses React for these custom components.

Now imagine this cocktail: Pure Python and React components, mixed with the power of Generative AI, all in the hands of non-technical teams. The result? Well, let’s just say it’s not exactly a recipe for maintainable code.

The Missing Architecture #

The most critical issue with Streamlit isn’t what it includes, but what it omits: a clean, enforced architecture. While Streamlit proudly calls itself “an open-source app framework that is a breeze to get started with,” it misses the fundamental purpose of a framework - providing structure and guardrails for developers.

Yes, it’s incredibly easy to get started. But it’s equally easy to create an unmaintainable mess because it lacks the architectural patterns that experienced developers have come to rely on in mature frameworks.

The React Component Complexity #

The situation becomes even more complicated when we look at custom components. These are built with React, which, remember, is just a library (they’re honest about that, at least). Without proper architectural guidance, what you often end up with is:

• Nested Python functions that grow increasingly complex
• Monolithic React components that should have been broken down
• A confusing mix of Python and JavaScript/TypeScript paradigms

The Execution Model Problem #

Adding to these architectural challenges is Streamlit’s unique execution model. Instead of following the time-tested client-server pattern that has served the web well for decades, Streamlit re-executes the entire Python file on each interaction. While this approach might simplify some aspects of development, it can lead to performance issues and confusion about state management.

The Target Audience Paradox #

Here’s what I find most puzzling: Streamlit primarily targets non-technical and scientific users, yet it provides them with a tool that requires significant technical expertise to use properly. It’s like giving someone a powerful sports car without first teaching them how to drive - sure, they might figure out how to make it move, but they’re likely to crash at the first sharp turn.

Conclusion #

Don’t get me wrong - Streamlit is an impressive tool for what it is. It’s perfect for quick prototypes and simple data apps. But by marketing itself as a framework while eschewing the responsibility of providing proper architectural guidance, especially to its target audience of non-technical users, it’s setting up many teams for future maintenance nightmares.

The solution isn’t necessarily to abandon Streamlit, but rather to approach it with eyes wide open. If you’re going to use it in a professional context:

1. Establish clear architectural patterns upfront
2. Set boundaries for component complexity
3. Consider carefully whether it’s the right tool for your project’s scale

Sometimes, the “fastest way to build” isn’t the best way to build, especially if you’re planning for the long term.