The Streamlit Ceiling
Streamlit is not a framework; it is a prototype compiler that compiles your business logic into a fragile dependency graph. The appeal of Streamlit is undeniable. It allows a data scientist to write a linear script that renders a dashboard in minutes. The execution model is simple: the entire script runs from top to bottom on every interaction. This simplicity is the source of its power and the origin of its failure. When the application is small, the rerun model feels like magic. The state is implicit. The UI updates automatically. But this model imposes a hard ceiling on complexity. Once the application requires state that persists across reruns without re-executing expensive computations, or interactions that happen faster than the server can respond, the architecture begins to fracture. The rerun model treats the frontend as a dumb terminal. Every click, slider move, or text input sends a signal to the server. The server invalidates the session state, re-executes the Python script, and sends the new UI description back to the browser. This creates a fundamental latency floor. If your data processing takes two seconds, the user waits two seconds. There is no way to optimise this within the Streamlit paradigm because the UI is not separate from the logic. They are coupled by the script execution order. As applications grow, developers begin to fight this coupling. The first sign of trouble is state gymnastics. You start using session state to cache variables that should be local. You write complex logic to prevent re-execution of heavy functions. You use callbacks to manage side effects. The script becomes a tangle of conditional checks and state mutations. The linear flow is broken. The code becomes difficult to read and test because the state is global and mutable. The second sign is CSS escape hatches. Streamlit provides a limited set of layout options. When you need precise control over spacing, alignment, or responsiveness, you resort to injecting custom CSS. This is fragile. The internal class names of Streamlit components change between versions. Your custom styles break without warning. You spend more time maintaining CSS hacks than building features. The UI becomes inconsistent. The design system is non-existent. The third sign is component fights. You try to use native HTML components or third-party widgets. They do not play well with the rerun model. Events from these components may not trigger reruns correctly. State may not sync. You write custom components in React or Vue, only to find that the communication channel between the frontend and the Python backend is slow and limited. The abstraction leaks. You are writing frontend code in a backend framework. The fourth sign is latency you cannot control. The user clicks a button. The screen freezes. The browser shows a loading spinner. The user waits. This is unacceptable for interactive applications. Streamlit is not designed for real-time interactions. It is designed for batch processing with a UI. When the user expects instant feedback, Streamlit fails. The rerun model introduces a delay that is proportional to the complexity of the script. There is no way to parallelise the execution. The script runs sequentially. To recognise the ceiling before you hit it, use this checklist. If you have more than three session state variables that depend on each other, you are in trouble. If you have custom CSS that targets internal Streamlit classes, you are in trouble. If you have callbacks that modify state in complex ways, you are in trouble. If the user complains about slowness, you are in trouble. If you find yourself writing code to prevent re-execution, you are in trouble. These are not minor issues. They are structural failures. The architecture cannot support the requirements. The cost of ignoring these signs is high. The codebase becomes unmaintainable. The performance degrades. The user experience suffers. The team becomes frustrated. The project risks failure. The solution is not to patch Streamlit. The solution is to move to a real frontend. This requires a shift in mindset. The UI must be separate from the logic. The state must be managed explicitly. The interactions must be handled on the client side. The server must provide data, not UI. This transition is not trivial. It requires learning new tools. It requires rethinking the architecture. It requires building a bridge between the Python backend and the JavaScript frontend. But it is necessary. The Streamlit ceiling is real. It is hard. It is low. Once you hit it, you cannot go higher. You must move sideways. You must adopt a proper frontend framework. You must build a real application. The pipeline you have built so far is solid. The data processing is correct. The models are accurate. The loop is tight. But the interface is fragile. It will break under pressure. It will not scale. It will not satisfy users who expect modern interactions. The pack needs a new skin. The loop needs a new rhythm. The interface needs to be decoupled from the execution model. The next step is to choose the right tools. There are many options. Each has tradeoffs. Some are easier to learn. Some are more powerful. Some are better suited for certain types of applications. The choice depends on the requirements. The choice depends on the team. The choice depends on the timeline. But the choice must be made. The ceiling is here. You cannot ignore it. You must plan the exit. The decision is not just about technology. It is about architecture. It is about separation of concerns. It is about maintainability. It is about performance. It is about user experience. It is about the future of the project. The Streamlit era is over. The real frontend era begins now. The transition is abrupt. The learning curve is steep. But the payoff is substantial. The application becomes robust. The code becomes clean. The users become happy. The team becomes productive. The project becomes sustainable. The next lesson, titled “The Decision Table: Streamlit, Gradio, NiceGUI, Reflex, FastAPI, Tauri, Electron”, will help you navigate this choice. It will compare the options. It will highlight the tradeoffs. It will guide you to the right path. The ceiling is not the end. It is the beginning. The real work starts now.