In Plotly Dash, how does the callback model differ from Streamlit's script rerun?

## Two answers to the same problem Both frameworks let a Python author ship an interactive web app without writing JavaScript. They solve the "what happens when the user clicks something" problem in opposite ways. ## Streamlit: rerun the script A Streamlit script executes top to bottom. `st.selectbox(...)` both renders a widget and returns its current value, so downstream code is ordinary Python using that value. When the user changes the widget, Streamlit re-runs **the entire script** in that user's session, and the widget call now returns the new value. There is no event handler, no wiring, no ids. The consequences follow directly: - **Everything recomputes** unless you stop it. That is why caching is central: `st.cache_data` for serialisable results such as a DataFrame, `st.cache_resource` for shared objects such as a database connection. - **State must be parked deliberately.** Local variables die with each run, so anything that must persist across reruns lives in `st.session_state`, a per-session dictionary. - **The server is stateful and session-bound.** Each browser session holds server-side state over a websocket, which means scaling out needs sticky routing and per-session memory. ## Dash: run the affected callbacks A Dash app declares a layout of id'd components and a set of callbacks. Each callback names the component properties it reads (`Input`, `State`) and writes (`Output`). Dash ships that dependency graph to the browser. When a property changes, the front end computes exactly which callbacks are affected, POSTs their inputs to the server, and patches the returned outputs into the DOM. Chains resolve automatically: if callback A's output is callback B's input, B runs after A. The consequences here: - **Only the touched subgraph recomputes.** A change to one filter does not re-run the four unrelated panels, and you can see the whole graph in the callback-graph dev tool. - **The server is stateless.** A callback is a pure request handler. There is no per-user memory between requests, so global variables are not per-user state — with multiple workers, consecutive requests from one user may land on different processes. - **State goes somewhere explicit.** `dcc.Store` keeps JSON in the browser (`memory`, `session` or `local` storage); shared caches go to Redis or a Flask-Caching layer; large data stays in the warehouse. - **Layout is arbitrary.** You compose an HTML tree yourself and can drop in CSS or a component library, whereas Streamlit's layout is a constrained set of containers. ## Choosing between them Use Streamlit when the app is essentially a script with knobs — an exploratory tool, a model demo, an internal one-pager — and speed of authoring dominates. It is very hard to beat on time-to-first-working-app. Use Dash when the interaction graph is genuinely a graph: many controls that affect different panels, expensive queries you must not re-run needlessly, a layout that has to look like a product, or a deployment that needs plain horizontal scaling behind a WSGI server. Dash is a Flask app, so authentication middleware, blueprint mounting and existing infrastructure fit. Do not oversell either. Both are Python app frameworks, and neither is a governed BI platform: there is no semantic layer, no row-level security you did not write, no scheduled-refresh subsystem, and no self-service authoring for non-engineers. Every app is code someone has to own, test and upgrade. The honest positioning is that these frameworks win when the interaction is *analytical logic* — a model, a simulation, a bespoke workflow — rather than a slice-and-dice over a star schema, which a BI tool does better and cheaper. ## The performance conversation In Streamlit, the performance question is "what am I re-running that I should be caching?" In Dash, it is "which callbacks fire on this change, and does one of them hit the database when it did not have to?" Both frameworks let you make a chart interaction issue a fresh warehouse query per keystroke; the difference is where you look to find it. A final asymmetry worth naming: Streamlit's rerun makes control flow trivially readable but makes "do this only when that changed" awkward. Dash's graph makes that trivially expressible but makes control flow something you assemble from decorators rather than read down the page. That trade is the answer to the interview question.