// the find
marimo-team/marimo
A reactive notebook for Python — run reproducible experiments, query with SQL, execute as a script, deploy as an app, and version with git. Stored as pure Python. All in a modern, AI-native editor.
marimo is a Python notebook that fixes the core Jupyter problem: notebooks are stored as plain .py files with no hidden state, and cells re-execute automatically when their dependencies change via static analysis of variable references. The same file runs as a notebook, a CLI script, or a deployed web app. It's for data scientists and ML engineers who are tired of "run all cells" being load-bearing infrastructure.
The pure Python storage is the most important design decision here — you get real diffs, real imports, and pytest works on notebooks without any plugins or hacks. The reactive DAG is built by statically analyzing variable references, not cell position, which means execution order is deterministic and deleting a cell actually removes its variables from scope. SQL cells that interpolate Python values and return dataframes are first-class, not bolted-on. The multi-role model — one .py file that's a notebook, a script with CLI args, and a Streamlit-style web app — eliminates the usual 'export to script' step that breaks every Jupyter workflow.
The no-global-mutation constraint is the biggest adoption friction: you cannot reassign a variable defined in another cell without creating a cycle error, which means porting an existing Jupyter notebook often requires restructuring, not just opening it. Lazy execution for expensive cells is opt-in configuration, not the default — so a notebook with a slow cell will still auto-run it on open until you know to configure otherwise. WASM deployment is genuinely useful but limited by Pyodide's package support, meaning anything with C extensions or outbound network calls falls back to needing a server. The molab cloud service is real but still feels early compared to Colab or Databricks for teams who need managed hosting.